WeePee SIP trunk werkt inkomend niet meer na overstap van BBOX2 naar BBOX3

Status
Niet open voor verdere reacties.
F

Fluppe

Gast
Mijn BBOX2 is vrijdag vervangen door een BBOX3 en het netto resultaat is dat mijn SIP trunk (IP telefonie dus) met WeePee inkomend niet meer werkt - uitgaand nog wel. Alles is tot dan jaren goed gegaan met de bbox2.

Weet iemand over problemen hiermee en of er iets aan kan gedaan worden ?

Na mijn ervaringen met Bcom HD verleden vrijdag zie ik ertegenop hun hierover aan te spreken - de technische kennis van hun eerste lijns medewerkers is zeer letterlijk onbestaand. Het enige wat ze kunnen, en naar eigen zeggen ook het enige wat ze willen doen, is helpen de installatie gids uitvoeren wat inhoudt dat ze je zeggen waar welke kabel ingeprikt moet worden en waar de resetknop zit. Verder doen ze niks anders dan hun lijstje aflezen of er problemen in hun netwerk gerapporteerd zijn, en als je er zelf een rapporteert telt dat niet mee. En ze "testen" je lijn door ergens op een knopje te klikken en als ze een groen vinkje krijgen is het weerom hun probleem niet. Je krijgt zero informatie over wat en hoe er "getest" wordt op je lijn. En doorschakelen naar een technisch onderlegde gesprekspartner weigeren ze ook al helemaal - ondanks de beschrijving van hun dienst op hun website, dat je daar technische vragen kan stellen.

Mijn probleem was eerst dat de DNS servers die hun DHCP server aanduidde, niet antwoordden zodat mijn browsers systematisch geen enkele server vonden. Na zowat mijn ganse installatie op hun vraag te hebben vervangen en gereduceerd te hebben tot 1 PC met 1 nieuwe kabel van hun winkel op een nieuwe BBOX, had ik nog steeds hetzelfde probleem. Met al mijn PCs. Hun aanraden was met mijn PC terug naar de winkel te gaan om die goed te laten configureren ... dat mijn PC wel goed werkte bij een familielid die ook een bcom lijn heeft, en dat ik 'm bovendien van mijn werkgever heb en elke dag zowel op kantoor als op het bezoekersnetwerk van diverse klanten gebruik, heeft duidelijk voor bcom geen waarde ...

Wat ik bij debugging zie is dat ik wel SIP Pakketten van WeePee zie aankomen op mijn SIP gateway, maar in de URI staat nu mijn publieke IP adres wat mijn gateway natuurlijk niet kent, en dus het pakket weigert. Op de netwerk laag gaat alles goed anders zou mijn gateway het IP pakket van WeePee niet eens ontvangen, maar het is in de payload waar BBOX en de rest van het internet moet afblijven, dat er dingen gewijzigd worden nu; zodat WeePee van mij op SIP niveau verkeerde info krijgt en bijgevolg naar het foute URI stuurt.

Wat ik denk dat er gebeurt, maar dit is puur speculatie, is dat er nog stukken code voor VoIP ondersteuning meespelen op de BBOX3 hoewel mijn model officieel geen VoIP ondersteunt. Ze gaan geen aparte firmware schrijven voor al hun modellen, er wordt 1 firmware geschreven die alles doet en de POST tests wijzen vervolgens uit welke hardware er aanwezig is en dus welke routines uitgeschakeld worden. Alleen denk ik dat in onderhaving geval de STUN voor SIP toch is blijven draaien en met de SIP pakketten gaat prutsen.

Ik ga morgen nog eens bij Bcom vragen of ik die BBOX3 niet terug mag omruilen voor een BBOX2 maar ik ben een beetje bang dat er meerdere redenen zijn waarom dat niet gaat lukken of gewoon geweigerd zal worden.

En terloops gezegd, de download snelheid is nu *letterlijk* gehalveerd. Uit de fora blijkt dat anderen dat ook ondervonden hebben met BBOX3. Op dit ogenblik is dit geen zorg.

Ik hoop dat iemand mij kan vertellen hoe ik SIP weer fatsoenlijk aan de praat krijg. Zoals gezegd, uitgaande oproepen werken nog wel. Maar voorlopig betaal ik gesprekskosten voor elk binnenkomend gesprek dat ik omleid naar mijn gsm ...
 
Een hele boterham hier.
Even een paar vraagjes, hoe gebruik je de VoIP aan client side? Heb je gewoon een rechtstreekse SIP client, of gebruik je een SIP trunk? (trunk als zijnde een eigen PBX).

BGC gebruikt uiteraard, evenals Telenet, VoIP (SIP) voor hun eigen telefonie. Het lijkt me dan ook meer dan waarschijnlijk om daar het probleem te gaan zoeken. Inbound calls werken dus niet meer.
- Call komt volledig niet door (geen inkomend gesprek)?
- Wel een inkomend gesprek, maar geen audio hoorbaar (enkel en/of tweezijdig)?

Een eerste gedachte wat in me opkomt, is een andere poort te gebruiken voor je SIP client, 5060 is de standaard poort. Alternatief is de 5061, 5062, ...

Gebruik je UDP als protocol? Recommended...

Een ander niet zo voor de hand liggend alternatief is een verbinding op IAX2 ipv op SIP. Maar ik ben er niet zeker van of weepee dit (nog) aanbied. En dan zou je ook best een trunk in gebruik nemen, maw een PBX opzetten. Wat niet zozeer aan de orde hier is vrees ik.


Aanvulling:
Het is trouwens ook wel een feit dat BGC al zen telefonie concurrenten niet gaat meewerken (om het nog zeer beleefd te zeggen, de realiteit is letterlijk saboteren). Het verwondert me dus eigenlijk niet dat de nieuwe bbox hier moeillijk over doet.
Komt erop neer dat je van BGC hier zeker geen hulp moet verwachten. Als je externe hulp nodig hebt, vraag aan weepee support ipv BGC support.
 
@DDragon80:

Hallo
ik gebruik UDP op een SIP trunk. Mijn IP PBX is een Cisco systems call manager express van een oudere generatie op een Cisco 2811 multiservices router met IOS 12.4. Inkomende gesprekken gebeurden gewoon NIET, zelfs niet rinkelen.

Ik ben er ondertussen moeiteloos in geslaagd mijn BBOX3 terug om te ruilen tegen een BBOX2. Na openen van het ticket bij BGC, blijft het ticket nummer 10 dagen geldig om de bbox om te ruilen, en je kan een BBOX2 vragen -zolang de voorraad strekt- wat niet eindeloos zal zijn.

Dit is wat er gebeurt, je ziet dat, op SIP niveau waar de bboxen normaal moeten afblijven, mijn provider mij toch op het publieke ip adres aanspreekt wat mijn gateway natuurlijk niet kent. Dat is omdat in de andere richting, het private adres van mijn gateway vervangen is door het publieke en Weepee dus het verkeerde leert. Denk ik. Op niveau 3 werkt NAT correct en dus is er wel uitwisseling van ip pakketten op de juiste poortnummers tussen mijn gateway en Weepee, maar het SIP adres waar het ip adres in verwerkt zit wordt verprutst door BGC.
hieronder de debug op de cisco gateway (gedeeltelijk):

met BBOX3, idle (geen calls):

Received:
OPTIONS sip:329909010574@80.200.77.162:5060 SIP/2.0
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK19d79609;rport
Max-Forwards: 70
From: "weepee" <sip:weepee@91.208.12.134>;tag=as65560c17
To: <sip:329909010574@80.200.77.162:5060>
Contact: <sip:weepee@91.208.12.134:5060>
Call-ID: 5450caa870f8bd895efe93a87ec727e4@91.208.12.134:5060
CSeq: 102 OPTIONS
User-Agent: weepee
Date: Sat, 15 Feb 2014 19:29:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent:
SIP/2.0 400 Bad Request - 'Invalid IP Address'
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK19d79609;rport
From: "weepee" <sip:weepee@91.208.12.134>;tag=as65560c17
To: <sip:329909010574@80.200.77.162:5060>;tag=EB1EC-2529
Date: Sat, 15 Feb 2014 19:29:07 GMT
Call-ID: 5450caa870f8bd895efe93a87ec727e4@91.208.12.134:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Content-Length: 0

En nu met BBOX2, idle (geen calls):
Received:
OPTIONS sip:329909010574@192.168.1.201:5060 SIP/2.0
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK15061ae5;rport
Max-Forwards: 70
From: "weepee" <sip:weepee@91.208.12.134>;tag=as76f51ba8
To: <sip:329909010574@192.168.1.201:1024>
Contact: <sip:weepee@91.208.12.134:5060>
Call-ID: 2af0a413644fc574405337225fdd6841@91.208.12.134:5060
CSeq: 102 OPTIONS
User-Agent: weepee
Date: Mon, 17 Feb 2014 13:22:40 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK15061ae5;rport
From: "weepee" <sip:weepee@91.208.12.134>;tag=as76f51ba8
To: <sip:329909010574@192.168.1.201:1024>;tag=85E47D8-1963
Date: Mon, 17 Feb 2014 13:22:40 GMT
Call-ID: 2af0a413644fc574405337225fdd6841@91.208.12.134:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Supported: 100rel,resource-priority,replaces,sdp-anat
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 172
v=0
o=CiscoSystemsSIP-GW-UserAgent 6958 2516 IN IP4 192.168.1.201
s=SIP Call
c=IN IP4 192.168.1.201
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3
c=IN IP4 192.168.1.201
Voorlopig ben ik dus weer gerust.

Dank je wel voor je commentaar overigens
 
@DDragon80:

Hallo
ik gebruik UDP op een SIP trunk. Mijn IP PBX is een Cisco systems call manager express van een oudere generatie op een Cisco 2811 multiservices router met IOS 12.4. Inkomende gesprekken gebeurden gewoon NIET, zelfs niet rinkelen.

Ik ben er ondertussen moeiteloos in geslaagd mijn BBOX3 terug om te ruilen tegen een BBOX2. Na openen van het ticket bij BGC, blijft het ticket nummer 10 dagen geldig om de bbox om te ruilen, en je kan een BBOX2 vragen -zolang de voorraad strekt- wat niet eindeloos zal zijn.

Dit is wat er gebeurt, je ziet dat, op SIP niveau waar de bboxen normaal moeten afblijven, mijn provider mij toch op het publieke ip adres aanspreekt wat mijn gateway natuurlijk niet kent. Dat is omdat in de andere richting, het private adres van mijn gateway vervangen is door het publieke en Weepee dus het verkeerde leert. Denk ik. Op niveau 3 werkt NAT correct en dus is er wel uitwisseling van ip pakketten op de juiste poortnummers tussen mijn gateway en Weepee, maar het SIP adres waar het ip adres in verwerkt zit wordt verprutst door BGC.
hieronder de debug op de cisco gateway (gedeeltelijk):

met BBOX3, idle (geen calls):

Received:
OPTIONS sip:329909010574@80.200.77.162:5060 SIP/2.0
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK19d79609;rport
Max-Forwards: 70
From: "weepee" <sip:weepee@91.208.12.134>;tag=as65560c17
To: <sip:329909010574@80.200.77.162:5060>
Contact: <sip:weepee@91.208.12.134:5060>
Call-ID: 5450caa870f8bd895efe93a87ec727e4@91.208.12.134:5060
CSeq: 102 OPTIONS
User-Agent: weepee
Date: Sat, 15 Feb 2014 19:29:07 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent:
SIP/2.0 400 Bad Request - 'Invalid IP Address'
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK19d79609;rport
From: "weepee" <sip:weepee@91.208.12.134>;tag=as65560c17
To: <sip:329909010574@80.200.77.162:5060>;tag=EB1EC-2529
Date: Sat, 15 Feb 2014 19:29:07 GMT
Call-ID: 5450caa870f8bd895efe93a87ec727e4@91.208.12.134:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Content-Length: 0

En nu met BBOX2, idle (geen calls):
Received:
OPTIONS sip:329909010574@192.168.1.201:5060 SIP/2.0
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK15061ae5;rport
Max-Forwards: 70
From: "weepee" <sip:weepee@91.208.12.134>;tag=as76f51ba8
To: <sip:329909010574@192.168.1.201:1024>
Contact: <sip:weepee@91.208.12.134:5060>
Call-ID: 2af0a413644fc574405337225fdd6841@91.208.12.134:5060
CSeq: 102 OPTIONS
User-Agent: weepee
Date: Mon, 17 Feb 2014 13:22:40 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 91.208.12.134:5060;branch=z9hG4bK15061ae5;rport
From: "weepee" <sip:weepee@91.208.12.134>;tag=as76f51ba8
To: <sip:329909010574@192.168.1.201:1024>;tag=85E47D8-1963
Date: Mon, 17 Feb 2014 13:22:40 GMT
Call-ID: 2af0a413644fc574405337225fdd6841@91.208.12.134:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Supported: 100rel,resource-priority,replaces,sdp-anat
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 172
v=0
o=CiscoSystemsSIP-GW-UserAgent 6958 2516 IN IP4 192.168.1.201
s=SIP Call
c=IN IP4 192.168.1.201
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3
c=IN IP4 192.168.1.201
Voorlopig ben ik dus weer gerust.

Dank je wel voor je commentaar overigens


PHP:
</sip:329909010574@192.168.1.201:1024></sip:weepee@91.208.12.134></sip:weepee@91.208.12.134:5060></sip:329909010574@192.168.1.201:1024></sip:weepee@91.208.12.134></sip:329909010574@80.200.77.162:5060></sip:weepee@91.208.12.134></sip:weepee@91.208.12.134:5060></sip:329909010574@80.200.77.162:5060></sip:weepee@91.208.12.134>

Ik heb moeten onderzoeken waarom een klant zijn VoIP centrale via de BBOX3 voip calls niet langer correct afhandelde.
Het probleem staat overigens ook netjes in uw SIP trace.

m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3

De BBOX3 wijzigt deze regel bij een SIP INVITE naar RTP poort 0 waardoor de RTP communicatoe foutloop. Dit gebeurt ENKEL met pakketen die Source of Destination Port UDP 5060 hebben. Zoals extern als intern! Beide endpoints aanpassen naar een andere poort en de packet mangling wordt niet toegepast. Ik vraag me sterk af wat de opzet is van Belgacom om die regel te manglen. Sabotage of een leftover van hun VoIP code?

Samengevat. SIP / RTP communicatie wordt door de Bbox3 op poort 5060 gesaboteerd.
 
PHP:
</sip:329909010574@192.168.1.201:1024></sip:weepee@91.208.12.134></sip:weepee@91.208.12.134:5060></sip:329909010574@192.168.1.201:1024></sip:weepee@91.208.12.134></sip:329909010574@80.200.77.162:5060></sip:weepee@91.208.12.134></sip:weepee@91.208.12.134:5060></sip:329909010574@80.200.77.162:5060></sip:weepee@91.208.12.134>

Ik heb moeten onderzoeken waarom een klant zijn VoIP centrale via de BBOX3 voip calls niet langer correct afhandelde.
Het probleem staat overigens ook netjes in uw SIP trace.

m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3

De BBOX3 wijzigt deze regel bij een SIP INVITE naar RTP poort 0 waardoor de RTP communicatoe foutloop. Dit gebeurt ENKEL met pakketen die Source of Destination Port UDP 5060 hebben. Zoals extern als intern! Beide endpoints aanpassen naar een andere poort en de packet mangling wordt niet toegepast. Ik vraag me sterk af wat de opzet is van Belgacom om die regel te manglen. Sabotage of een leftover van hun VoIP code?

Samengevat. SIP / RTP communicatie wordt door de Bbox3 op poort 5060 gesaboteerd.

Iets zegt me dat u een medewerker bent van Weepee? Misschien ook omdat ik locatie Brugge zie staan, waar weepee servers heeft.
Ik weet uit persoonlijke ervaring dat BGC zen route naar weepee saboteerd. Door in de routing een hele omweg rond Europa te maken om van een locatie in Belgie, naar Brussel of Brugge te gaan... Waardoor je dus een onnodige delay krijgt met alle gevolgen vandien voor RTP traffic.
 
Iets zegt me dat u een medewerker bent van Weepee? Misschien ook omdat ik locatie Brugge zie staan, waar weepee servers heeft.
Ik weet uit persoonlijke ervaring dat BGC zen route naar weepee saboteerd. Door in de routing een hele omweg rond Europa te maken om van een locatie in Belgie, naar Brussel of Brugge te gaan... Waardoor je dus een onnodige delay krijgt met alle gevolgen vandien voor RTP traffic.

Neen ik ben geen medewerker van WeePee ;-). Ik heb wel een aantal jaar ervaring bij een bedrijf die WeePee reseller is, maar werk zelfstandig.
Deze issue met de Bbox 3 heeft ook impact op alle andere VoIP providers. Ik heb dit probleem onderzocht op basis van een SIP trunk tussen 2 VoIP Centrales. In eender welke richting je een call start met als source of destination 5060, dat pakketje werd aangepast en niet op andere poorten. Als Belgacom dit echt opzettelijk doet, dan is het zeer flauw om niet simpelweg die poort te blokkeren maar inhoud van een pakket te gaan veranderen zodat een call zou falen. Dat betekend ook dat als je het al kan draaien op andere poorten (Provider en Centraleà, dan zou Belgacom nog elk pakketje op andere poorten kunnen gaan controleren en blijven vervelend doen.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan