latency jumblo

[TomVH]

Hallo,

Sinds kort zit er heel wat vertraging op de lijn als ik naar een gsm nummer bel (standaard via jumblo) met de ata SPA3102. Kies ik als uitgaande provider "WeePee" dan is er geen vertraging. Inkomende gesprekken geven ook geen probleem (WeePee).

Ik heb getest na het herstarten van de router en ATA.

Iemand een idee wat de oorzaak zou kunnen zijn?

Tom

[fryelectro]

de reden is gewoon dat je voor die prijs dat je bij Jumblo betaalt geen goede latency mag verwachten. Ik gebruik het zelf ook en met momenten is dit niet te doen. Echter vaker werkt het gewoon wel goed.

[ubremoved_15739]

Hout vasthouden. Maar tot op heden moet ik mijn eerste gesprek nog tegenkomen op Jumblo (of een ander betamax) waar de latency de gesprekskwaliteit hoorbaar negatief beïnvloedt.

Hebben jullie op je lokale netwerk enige vorm van QoS (Quality of Service)?
Wat ook mogelijk zou kunnen zijn, is dat lokaal het netwerk van je ISP volzet is ... 't Is maar een gedachte, hé.

[TomVH]

Voorlopig geen QoS. Daar werk ik aan. MAAR de "traffic meter" in OpenWRT geeft aan dat er geen traffic is buiten de 100 kbps van voip (als ik aan het bellen ben). De lijn is dus zeker niet verzadigd hoor.

Het probleem is maar opgedoken de laatste 2 weken. Ik ben ondertussen wel overgeschakeld van DD-WRT naar OpenWrt maar het zou mij verwonderen dat dit het probleem is. Zal vanavond nog eens mijn oude router plaatsen.

Zou de oorzaak niet kunnen liggen aan de "proxy"? Nu gebruik ik "ssw6.brussels.weepee.org". Als proxy. Ook voor jumblo omdat ik er maar 1 kan ingeven.

Ik begrijp het VoIP gebeuren nog niet helemaal. Ik ken het verschil niet tussen.

• Proxy
• Outbound proxy
• subscriber information
• Register

Hoewel dit er eigenlijk toch niets kan aan doen. Het geluid is toch P2P dus,.... Of misschien de DNS servers?

Ik zal eerst nog wat opzoekwerk moeten doen denk ik.

[ubremoved_15739]

Zal vanavond nog eens mijn oude router plaatsen.

Dat lijkt me een goed idee. Een nieuwe router moet zich altijd eerst nog bewijzen.

Ik had onlangs (05/09/11) op iBOOD ook enkele Netgear routers (WNDR3700) gekocht. Zogezegd nieuwe. Totdat de levering arriveerde.
Allemaal allicht "refurbished", met een tweede officiële sticker over de eerste. Geen enkele van de routers haalt wat hij zou moeten.
Eentje is zelfs ronduit bar slecht en instabiel. Ik ben eens benieuwd hoe die "dozenschuiver iBOOD" dit gaat afhandelen ...
Afin, ik wil maar zeggen dat de ene router de andere niet is ... ook al zou die op papier deftige specificaties moeten hebben.


De groene vlek verbergt de "security pin", het serie nummer en het MAC adres ...

Zou de oorzaak niet kunnen liggen aan de "proxy"? Nu gebruik ik "ssw6.brussels.weepee.org".

Nee.

Voor die andere zaken is inderdaad goed om je daar eens in te verdiepen, lijkt me.

[Ofloo]

de reden is gewoon dat je voor die prijs dat je bij Jumblo betaalt geen goede latency mag verwachten. Ik gebruik het zelf ook en met momenten is dit niet te doen. Echter vaker werkt het gewoon wel goed.

als iets niet naar behoren werkt dan maakt het niet uit hoe goedkoop het is, .. ofwel werkt het deftig en anders niet en is het in mijn ogen het geld niet waard.

[TomVH]

TomVH schreef:
Zal vanavond nog eens mijn oude router plaatsen.
Dat lijkt me een goed idee. Een nieuwe router moet zich altijd eerst nog bewijzen.

Ik heb zonet mijn oude router geplaatst. Identiek het zelfde probleem.

Zou aub iemand mijn test eens kunnen overdoen. Zo weet ik of ik de oorzaak moet gaan zoeken in mijn setup of ik de oorzaak moet gaan zoeken bij Jumblo.

• Bel met de vaste (draadloze) telefoon naar je gsm. Gebruik hiervoor 1X de provider Jumblo en 1X de provider WeePee of een andere
• Hou de speaker van je gsm tegen je oor
• Spreek iets in, in de micro van het vast toestel
• Bij jumblo komt het geluid er maar door naar 1 sec of langer denk ik. Bij WeePee is het geluid er onmiddelijk (met geluid bedoel ik spraak te horen uit je speaker van je gsm)

Alvast bedankt voor de moeite.

[Ofloo]

doe gewoon een traceroute .. dat zou normaal moeten laten zien waar het probleem zit.

[jorgo]

Moet je wel eerst weten naar waar de audio gaat, dat is dus niet naar sip.jumblo.com maar naar een server die via RTP benaderd wordt.
Ik had het eens nagekeken bij een andere Betamax clone en het ging toen naar een dedicated server die in Nederland gehost werd, al herinner ik me niet meer bij welke dat was.

[ubremoved_15739]

@ TomVH

Misschien kan je eens met Wireshark gaan kijken wat er precies gebeurt.
Wireshark heeft heel wat mogelijkheden aan boord betreffende VoIP.
Dat je met jouw, ahum, meetmethode "een verschil" hoort van meer dan een seconde lijkt me nogal straf.
Dat je een verschil waarneemt is logisch natuurlijk: de diverse servers staan geografisch op een andere plaats.
Doch dit heeft mijn inziens niet direct iets te maken met de kwaliteit van het gesprek.
Maar goed: hier een linkje naar een (oud en) beperkt artikel over het gebruik van Wireshark en VoIP. Expose VoIP Problems Using Wireshark

Ik heb eens enkele grafiekjes gemaakt met Wireshark die toch min of meer de kwaliteit van Jumblo, Poivy en WeePee in kaart zouden moeten brengen. Minstens eventuele ernstige verschillen laten zien indien deze aanwezig zouden zijn.
Nu, het gaat over live gesprekjes die mijn inziens toch wel wat illustratief zouden kunnen zijn...
Uiteraard is dit maar een kleine opname in de tijd en geen lang doorgedreven test noch worden alle aspecten belicht.

Wat heb ik gebruikt:

• Een Siemens Gigaset A580IP (IP 192.168.1.31)
• Een Siemens Gigaset S685IP (IP 192.168.1.30)
• Belgacom Favorite abonnement met BBOX2 (dus geen QoS in deze setup voor de duidelijkheid)
• Een GSM met Mobistar SIM
• Enkele Weepee accounts
• Een Jumblo account
• Een Poivy account
• Vista PC met Wireshark
• een paar tassen koffie

Gesprekjes die opgezet werden:

• Jumblo naar GSM
• Jumblo naar WeePee
• Poivy naar WeePee
• WeePee naar WeePee

Nu zou men ieder van onderstaande grafiekjes individueel kunnen gaan bespreken (en zelfs verder detailleren) doch aangezien ik geen abnormaliteiten waargenomen heb, ga ik me louter beperken tot de weergave ervan.
Verder reken ik op de scherpe en alerte ogen van de lezer.

==========================================================================================
1. Gesprek Jumblo naar GSM.

1.1 Grafische analyse van de RTP streams, forward en reversed zoals door de beller waargenomen.




1.2 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de beller waargenomen.




1.3 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de beller waargenomen.




==========================================================================================
2. Gesprek Jumblo naar WeePee.

2.1 Grafische analyse van de RTP streams, forward en reversed zoals door de beller waargenomen.




2.2 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de beller waargenomen.




2.3 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de beller waargenomen.




2.4 Grafische analyse van de RTP streams, forward en reversed zoals door de opgebelde waargenomen.




2.5 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de opgebelde waargenomen.




2.6 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de opgebelde waargenomen.




==========================================================================================
3. Gesprek Poivy naar WeePee.

3.1 Grafische analyse van de RTP streams, forward en reversed zoals door de beller waargenomen.




3.2 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de beller waargenomen.




3.3 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de beller waargenomen.




3.4 Grafische analyse van de RTP streams, forward en reversed zoals door de opgebelde waargenomen.




3.5 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de opgebelde waargenomen.




3.6 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de opgebelde waargenomen.




==========================================================================================
4. Gesprek WeePee naar WeePee.

4.1 Grafische analyse van de RTP streams, forward en reversed zoals door de beller waargenomen.




4.2 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de beller waargenomen.




4.3 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de beller waargenomen.




4.4 Grafische analyse van de RTP streams, forward en reversed zoals door de opgebelde waargenomen.




4.5 Enkele karakteristieken data van de RTP stream, forward direction, zoals door de opgebelde waargenomen.




4.6 Enkele karakteristieken data van de RTP stream, reversed direction, zoals door de opgebelde waargenomen.




Conclusie.

Op basis van deze gegevens kan ik alvast geen aanmerkelijk verschil aanduiden tussen de accounts (WeePee, Jumblo, Poivy).
En in feite is dat ook wat mijn ervaring is. Ze zijn aan elkaar gewaagd.

Belangrijker is misschien dat Userbase VoIP forum gebruikers Wireshark mogelijkerwijze als aanvullende tool kunnen gebruiken in het analyseren van hun VoIP problemen. Doch Wireshark is gewoon te uitgebreid om hier te bespreken.

Succes met:

Zo, mijn koffie is intussen weeral op.

[TomVH]

Bedankt voor de interessante post. Ik leest het eens grondig door.

Dat je met jouw, ahum, meetmethode "een verschil" hoort van meer dan een seconde lijkt me nogal straf.

Dit is effectief het probleem hier thuis. 1 sec is zeker niet overdreven. Met WeePee is alles OK maar met Jumblo niet. Het geluid komt er wel door maar véél te laat.

[Muziekbos]

Zo, mijn koffie is intussen weeral op.

"Effe Appeldoorn belle ..."

Een mooi en heel uitgebreid verslag. Knap

[ubremoved_15739]

Zou aub iemand mijn test eens kunnen overdoen. Zo weet ik of ik de oorzaak moet gaan zoeken in mijn setup of ik de oorzaak moet gaan zoeken bij Jumblo.

• Bel met de vaste (draadloze) telefoon naar je gsm. Gebruik hiervoor 1X de provider Jumblo en 1X de provider WeePee of een andere
• Hou de speaker van je gsm tegen je oor
• Spreek iets in, in de micro van het vast toestel
• Bij jumblo komt het geluid er maar door naar 1 sec of langer denk ik. Bij WeePee is het geluid er onmiddelijk (met geluid bedoel ik spraak te horen uit je speaker van je gsm)

Moet je wel eerst weten naar waar de audio gaat, dat is dus niet naar sip.jumblo.com maar naar een server die via RTP benaderd wordt.
Ik had het eens nagekeken bij een andere Betamax clone en het ging toen naar een dedicated server die in Nederland gehost werd, al herinner ik me niet meer bij welke dat was.

De afgelegde weg van de RTP pakketten kan eenvoudig (en kort) maar ook complex zijn (en lang).
Drie voorbeelden ter illustratie:

• Giganet
• WeePee to WeePee
• Jumblo to WeePee

1. Giganet.
De RTP pakketten lopen rechtsreeks tussen beide partijen (in casu IP 192.168.1.30 en IP 192.168.1.31).
Enkel voor het opzetten van het gesprek wordt gebruik gemaakt van de giganet server.



2. WeePee to WeePee.
De RTP pakketten lopen allemaal over één en dezelfde server van WeePee.
Beide partijen (in casu IP 192.168.1.30 en IP 192.168.1.31) communiceren niet rechtstreeks met elkaar.
Afstand (en dus latency) blijft beperkt.



3. Jumblo to WeePee.
De RTP pakketen gaan voor ieder van de partijen over een andere server:

• voor de Jumblo account over een server van Jumblo;
• voor de WeePee account over een server van WeePee;
• de Jumblo en WeePee servers zullen dus de RTP pakketten met elkaar dienen uit te wisselen.

Beide partijen (in casu IP 192.168.1.30 en IP 192.168.1.31) communiceren niet rechtstreeks met elkaar.
Afstand (en dus latency) wordt dus groter.




PS Plaatjes gemaakt met behulp van Wireshark.

[ubremoved_15739]

Dit is effectief het probleem hier thuis. 1 sec is zeker niet overdreven. Met WeePee is alles OK maar met Jumblo niet. Het geluid komt er wel door maar véél te laat.

't Is maar een gedacht, maar probeer eens om de proxy server van Jumblo te nemen in plaats van WeePee.
En maak dan eens een gesprek naar een GSM met uw Jumblo account.


==> Zelf heb ik Jumblo geconfigureerd zoals in onderstaand plaatje.



==> En WeePee heb ik geconfigureerd zoals in onderstaand plaatje (beiden op hetzelfde basisstation).

[TomVH]

Ik heb de proxy instellingen al eens gewijzigd. Echter zonder resultaat.

Ik dacht dat RTP-pakketten altijd rechtstreeks van bron naar bestemming gingen. Blijkbaar is dit niet het geval? Ik lees overal dat RTP-sessie altijd wordt opgebouwd tussen bron en bestemming. Maar 77.72.168.156 is gelegen in Zwitserland en 91.208.12.38 is gelegen in België. RTP-pakketten gaan dus niet rechtstreeks naar de bestemming?

Ik dacht dat het zo ging:
1) Een gesprek tussen VoIP providers.

Bij het opbouwen van het gesprek worden de IP-adressen uitgewisseld en worden de nodige poorten geopend (session announcement protocol). Aangezien door NAT het bron-IPadres en bestemmings- IPadress dezelfde zijn zullen de pakketten volgens mij gewoon van de ISP server terug naar de bron-router lopen?

De kwaliteit van een gesprek kan dus eigenlijk weinig verschil geven tussen WeePee en Jumblo aangezien RTP-pakketten rechtstreeks (via de nodige internet hops) van bron naar bestemming gestuurd worden.

2) Een gesprek tussen een VoIP provider en Proximus / Mobistar / Base ,...
De RTP-pakketten worden van de Softphone/ata/... naar X gestuurd (via NAT-router en ISP servers/router). Op de server X worden de pakketten verstuurd naar server Y. Van server Y moet de spraak in de ether gestuurd worden via GSM-masten.
Ik weet dus niets over de servers/routers X en Y. Misschien zit daar het probleem?

Iemand die het opbouwen van de RTP-sessie kan verduidelijken?

[iceke]

Ik heb die SPA3102 al lang buiten gegooid. (ttz, hij ligt op zolder, als iemand interesse heeft, pm me maar)
Altijd problemen met dat ding, sinds ik Siemens ip telefoons heb werkt alles naar behoren.

[ubremoved_15739]

Ik dacht dat RTP-pakketten altijd rechtstreeks van bron naar bestemming gingen.

't Is maar wat je onder "bestemming" verstaat.
Er kan in het SIP-pakket staan:

• "bestemming": de RTP server van jouw SIP provider. En deze handelt jouw call verder af met jouw beoogde eind-bestemming, via de wegen die nodig zijn en die zij ter beschikking hebben (eventueel via nog een andere RTP server van een andere provider, GSM, PSTN, ...).
• "bestemming": jouw beoogde eind-bestemming, rechtstreeks (zoals in het giganet voorbeeld dat ik in een voorgaand bericht heb weergegeven).

Afin, zulke zaken zie je ook mooi in Wireshark staan (het volledige SIP-pakket of RTP-pakket van naaldje tot draadje).

Ik heb die SPA3102 al lang buiten gegooid. (ttz, hij ligt op zolder, als iemand interesse heeft, pm me maar)
Altijd problemen met dat ding, sinds ik Siemens ip telefoons heb werkt alles naar behoren.

Dat zou misschien veel verklaren.
Ik dacht al zoiets, maar ja, ik heb zelf geen hands-on ervaring met dat toestel.
En ja, zelf ben ik ook heel tevreden met die Siemens IP telefoons. 't Zijn natuurlijk instapmodelletje in de VoIP wereld, maar ze werken wel goed.

Ik vergelijk het een beetje met e-mail (de vergelijking gaat natuurlijk niet helemaal op):

• een goede e-mail client (samen met een goede ISP) is privé (of MKB) voldoende;
• Een full-blow mail server is privé echt niet nodig.

.

[ubremoved_15739]

@ TomVH

Aansluitend op jouw pm nog onderstaand.

Hopelijk is het ook interessant voor de andere Userbase VoIP forum gebruikers.

Betreffende de flow van de SIP en RTP pakketten heb ik voor bovenstaande gesprekken deze netwerkdumps eens weergeven in een ander, allicht overzichtelijker, formaat: een grafische analyse in flow formaat.
Dit formaat is een samenvatting van het begin tot het einde van een gesprek. Men ziet duidelijk hoe de flow van de pakketten in elkaar zit en welke toestellen/servers met elkaar communiceren via welke wijze.
Bij de "comments" aan de rechterzijde zijn de RTP pakketten erg gecondenseerd doch het correspondeerde pijltje aan de linkerzijde is wat dikker.
De RTP pakketten bevatten de daadwerkelijke gespreksgegevens en zijn dus in aantal massaal meer aanwezig (doch 't is heel repetitief op pakket niveau).

Verder werden er twee gesprekken bijgevoegd:
=> eentje via Poivy tussen de twee Gigaset basisstations;
=> en een gesprek naar een Telenet (jaja) aansluiting met een FB7390 (met een WeePee nummer).

De plaatjes zijn niet optimaal. Wireshark wou ofwel links ofwel rechts een stukje niet tevoorschijnt toveren. Niet echt storend, maar toch.
Verder zijn de "gevoelige delen" gecensureerd met een rood balkje.

1. S685IP (192.168.1.30) naar A580IP (192.168.1.31) via giganet.
Giganet SIP server, geen giganet RTP server.
Rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten).


Klik op het plaatje voor de grotere versie.

2. A580IP (192.168.1.31) naar GSM via Jumblo.
Jumblo SIP server en een aparte Jumblo RTP server.
Uiteraard geen rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten).
Enkel data (forward en reversed) van de A580IP.


Klik op het plaatje voor de grotere versie.

3. A580IP (192.168.1.31) via Jumblo naar S685IP (192.168.1.30) bij WeePee
Jumblo: een SIP server en een aparte Jumblo RTP server.
WeePee: een SIP server en RTP server op dezelfde machine (IP-adres).
Geen rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten via Jumblo en WeePee RTP servers).


Klik op het plaatje voor de grotere versie.

4. S685IP (192.168.1.30) via Poivy naar A580IP (192.168.1.31) bij WeePee.
Poivy: een SIP server en een aparte Poivy RTP server.
WeePee: een SIP server en RTP server op dezelfde machine (IP-adres).
Geen rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten via Poivy en WeePee RTP servers).


Klik op het plaatje voor de grotere versie.

5. S685IP (192.168.1.30) via WeePee naar A580IP (192.168.1.31) bij WeePee.
WeePee: een SIP server en RTP server op dezelfde machine (IP-adres).
Geen rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten zowel voor beller als bestemmeling via de WeePee RTP server).


Klik op het plaatje voor de grotere versie.

6. A580IP (192.168.1.31) via WeePee naar FB7390 (Telenet aansluiting) bij WeePee
WeePee: een SIP server en RTP server op dezelfde machine (IP-adres).
Geen rechtstreeks communicatie tussen beller en bestemmeling (RTP pakketten voor de beller via de WeePee RTP server).
Geen data weergegeven vanaf de zijde van de bestemmeling.

[VOiD]

Er kan in het SIP-pakket staan:

• "bestemming": de RTP server van jouw SIP provider. En deze handelt jouw call verder af met jouw beoogde eind-bestemming, via de wegen die nodig zijn en die zij ter beschikking hebben (eventueel via nog een andere RTP server van een andere provider, GSM, PSTN, ...).
• "bestemming": jouw beoogde eind-bestemming, rechtstreeks (zoals in het giganet voorbeeld dat ik in een voorgaand bericht heb weergegeven).

De eindpunten van een SIP gesprek kunnen zelfs tijdens het gesprek dynamisch wijzigen. Denk bv. aan wachtmuziek, conferenties, opnames, doorschakelingen etc.

[ubremoved_15739]

Dat is waar. Je kan als gebruiker jouw eindpunt wijzigen indien gewenst.
Maar WeePee of één van de betamax clonen zullen wel hun inkomsten (het gesprek) niet laten lopen gaan ...
Voor giganet (wat gratis is) maakt het niet uit natuurlijk. Daar mag je de details van het andere eindpunt dan ook zonder problemen weten.

[TomVH]

't Is maar wat je onder "bestemming" verstaat.

RTP-stream van "user1" naar "user2" bedoel ik. En niet zoals aangegeven in Wireshark:
"User1" => RTP proxy => .... => "User2" Het geluid gaat dus eerst naar Canada en dan terug.
In andere post heb ik gelezen dat RTP-proxy servers van Betamax zich bevonden in Nederland. Dit is nu blijkbaar niet meer het geval.
Ik begrijp dan wel niet waarom in één van je vorige posts de latency niet verschillend is. Jumblo RTP servers bevinden zich in "Canada" en WeePee RTP bevind zich in België,... De latency moet dan toch ook verschillend zijn?

iceke schreef:Ik heb die SPA3102 al lang buiten gegooid. (ttz, hij ligt op zolder, als iemand interesse heeft, pm me maar)
Altijd problemen met dat ding, sinds ik Siemens ip telefoons heb werkt alles naar behoren.

Dat zou misschien veel verklaren.
Ik dacht al zoiets, maar ja, ik heb zelf geen hands-on ervaring met dat toestel.

En WeePee doet het wel goed? Hmmm. Ik koop mij eens een manageble switch zodat de pakketten verzonden door de ATA gecapteerd kunnen worden met wireshark.

PS: hier is geen mogelijkheid om een IP-telefoon te plaatsen. We hebben nog een ouderwetse telefooncentrale. En ik wil eerst de reden weten WAAROM jumblo het niet goed doet i.v.m. WeePee met mijn huidige setup

[TomVH]

Maar WeePee of één van de betamax clonen zullen wel hun inkomsten (het gesprek) niet laten lopen gaan ...

Daarvoor bestaat SIP-proxy toch? Ik kan voorlopig maar 1 reden bedenken waarom ze RTP-proxy zouden gebruiken en dat is: Het oplossen van de NAT problemen die kunnen optreden bij VoIP.

[VOiD]

Dat is waar. Je kan als gebruiker jouw eindpunt wijzigen indien gewenst.
Maar WeePee of één van de betamax clonen zullen wel hun inkomsten (het gesprek) niet laten lopen gaan ...
Voor giganet (wat gratis is) maakt het niet uit natuurlijk. Daar mag je de details van het andere eindpunt dan ook zonder problemen weten.

Neen, de server kan dit ook wijzigen (of althans vragen om dit te doen).
Je moet een onderscheid maken tussen signalisatie en RTP stream. Het is niet omdat de RTP stream rechstreeks tussen de 2 eindpunten loopt dat de servers de controle over de signalisatie verliezen. Betamax kan nog perfect factureren ook al loopt er geen RTP stream via hun netwerk.

[ubremoved_15739]

Ik stel voor dat men de plaatjes eerst eens grondig bekijkt ....
En wat theoretisch mogelijk is en in de praktijk in de commerciële wereld gebeurt niet door elkaar haalt.

[philippe_d]

Theoretisch zou WeePee er kunnen vor zorgen dat de geprekken (RTP streams) tussen 2 WeePee gebruikers (of zelfs tussen bijvoorbeeld een WeePee gebruier en een 3* of Nomado gebruiker rechtstreeks lopen ussen de 2 eindpunten.
Ze verliezen dan wel niet de "controle" over de RTP stream, maar wel de inhoud. Ze zouden dus niet meer kunnen "aftappen".
Gezien telecom operatoren wettelijk de infrastructuur moet hebben om gesprekken te kunnen aftappen (op gerechterlijk bevel), moeten ze dus de gesprekken routeren over hun eigen servers Dit vlgens mij de reden.

Als je dus "rechtsreeks" wil bellen nar een andere VoIP gebruiker, moet je dit via de sip-uri doen van de bestemming. Dan gaat het rehtstreeks zoals in het Giganet vooreeld hierboven.

[VOiD]

Eternum, ik ben al jaren actief in de telefonie sector en doe niks anders dan zeer grote voip systemen implementeren. Ik spreek uit ervaring, niet op basis van theorieen.

Je kan zelfs perfect rechstreeks een RTP stream opzetten tussen een SIP endpoint en een H.323 endpoint (signalisatie is verschillende maar de RTP stream is hetzelfde) zolang de signalisatie vertaald wordt. (en ik spreek hier van een setup die actief is bij een van de grootste operatoren in Belgie )

[ubremoved_15739]

VOiD, ik geloof je best dat je zulke systemen opzet.

Maar wat is dan volgens jouw de reden (of meerdere) waarom ik als eindgebruiker blijkbaar via WeePee noch via een betamax kloon de gegevens van mijn eind-bestemmeling niet (via SIP/RTP) kan/mag verkrijgen? Via giganet is dit blijkbaar geen probleem.
Ik geloof wel degelijk wat ik zie via Wireshark.

Philippe heeft zeker een punt qua aftappen. Maar dat (RTP pakketten over hun servers en daar dan onderscheppen) zouden ze ook op het moment van dergelijk gerechtelijk bevel kunnen invoeren. Zij het dat je het dan wel zou kunnen zien aan de afgelegde weg dat er iets loos is.
Maar het kan een beslissing zijn die genomen is uiteraard.

[TomVH]

Ik stel voor dat men de plaatjes eerst eens grondig bekijkt ....

De latency is toch overal ongeveer gelijk in je plaatjes en RTP-servers bevinden zich toch op een verschillende geografische plaats? Hoe valt dit te verklaren? Of zie ik het verkeerd?

[VOiD]

Maar wat is dan volgens jouw de reden (of meerdere) waarom ik als eindgebruiker blijkbaar via WeePee noch via een betamax kloon de gegevens van mijn eind-bestemmeling niet (via SIP/RTP) kan/mag verkrijgen? Via giganet is dit blijkbaar geen probleem.

Daar kunnen zo veel redenen voor zijn. Omwille van recording (eigenlijk conferencing) zoals reeds gezegd, NAT fixup, transcoding,.... Meest voor de hand liggende reden is uiteraard dat de 2 eindpunten niet rechtsreeks met elkaar KUNNEN spreken.

Philippe heeft zeker een punt qua aftappen. Maar dat (RTP pakketten over hun servers en daar dan onderscheppen) zouden ze ook op het moment van dergelijk gerechtelijk bevel kunnen invoeren. Zij het dat je het dan wel zou kunnen zien aan de afgelegde weg dat er iets loos is.
Maar het kan een beslissing zijn die genomen is uiteraard.

Inderdaad, dat zou wel eens één van de belangrijkste redenen kunnen zijn. Ik denk dat de mensen van Weepee hier correct kunnen op antwoorden

[VOiD]

De latency is toch overal ongeveer gelijk in je plaatjes en RTP-servers bevinden zich toch op een verschillende geografische plaats? Hoe valt dit te verklaren? Of zie ik het verkeerd?

De lantency in de trace is tot aan de Jumblo gateway. Maar wat daarachter ? Langs waar routeren zijn het gesprek naar de GSM ? Welke apparatuur gebruiken ze voor de conversie etc. Kan allemaal een invloed hebben...

@TomVH & @Eternum, welke internetproviders gebruiken jullie trouwens ?

[ubremoved_15739]

Ik heb een Belgacom VDSL2 lijntje.

Nu heb ik ook even gekeken naar de forward en reverse Delta (aan mijn Belgacom zijde) van een gesprek tussen twee WeePee nummers: de ene met een BGC aansluiting de andere met een TN aansluiting.
Het valt me op dat wat er van de TN aansluiting terug komt toch wel veel meer jitter opzit. De reversed Delta veel groter etc.







Edit: laatste twee plaatjes toegevoegd.

[TomVH]

Ik gebruik scarlet ADSL (5Mbit/500kbit met speedtest)

De lantency in de trace is tot aan de Jumblo gateway.

Dus een RTP-pakket naar Brussel (WeePee) versturen duurt even lang als naar Canada (Jumblo)?

[ubremoved_15739]

Waar vind jij dat de RTP server van Jumblo in Canada staat?

[philippe_d]

Maar wat is dan volgens jouw de reden (of meerdere) waarom ik als eindgebruiker blijkbaar via WeePee noch via een betamax kloon de gegevens van mijn eind-bestemmeling niet (via SIP/RTP) kan/mag verkrijgen? Via giganet is dit blijkbaar geen probleem.

Daar kunnen zo veel redenen voor zijn. Omwille van recording (eigenlijk conferencing) zoals reeds gezegd, NAT fixup, transcoding,.... Meest voor de hand liggende reden is uiteraard dat de 2 eindpunten niet rechtsreeks met elkaar KUNNEN spreken.

- giganet is geen telecom operator: zij verbinden gewoon 2 eindtoestellen met mekaar (p2p zoals msn).
- WeePee: zie bovengenoemde redenen (aftap, NAT issues, etc ...)
- Betamax: zij werken gewoon met transit providers (zij weten dus niet of de eindgebruiker een VoIP client is, welke ISP, etc ...). Dus kunnen zij onmogelijk een point-to-point verbinding opzetten, toch?

[ubremoved_15739]

Philippe heeft zeker een punt qua aftappen. Maar dat (RTP pakketten over hun servers en daar dan onderscheppen) zouden ze ook op het moment van dergelijk gerechtelijk bevel kunnen invoeren. Zij het dat je het dan wel zou kunnen zien aan de afgelegde weg dat er iets loos is.
Maar het kan een beslissing zijn die genomen is uiteraard.

Inderdaad, dat zou wel eens één van de belangrijkste redenen kunnen zijn. Ik denk dat de mensen van Weepee hier correct kunnen op antwoorden

Ik zal eens een pm naar hen sturen, betreffende dit.
Ik ben ook eens benieuwd naar hun antwoord.

[VOiD]

- giganet is geen telecom operator: zij verbinden gewoon 2 eindtoestellen met mekaar (p2p zoals msn).
- WeePee: zie bovengenoemde redenen (aftap, NAT issues, etc ...)
- Betamax: zij werken gewoon met transit providers (zij weten dus niet of de eindgebruiker een VoIP client is, welke ISP, etc ...). Dus kunnen zij onmogelijk een point-to-point verbinding opzetten, toch?

Philippe, volledig correct. Dat bedoel ik dus met dat de eindpunten niet met elkaar kunnen spreken. Dit kan zijn omdat het technisch onmogelijk is (bv. geen gemeenschappelijke codecs of firewalls) maar evengoed dat er gewoonweg geen directe IP route tussen de eindpunten bekend is.

[ubremoved_15739]

Ja maar, van bovenstaande plaatjes waar er geen rechtstreekse communicatie was tussen de eindpunten, zijn er wel verschillende WeePee VoIP nummers zelf (onderling)!
En die verschillende toestellen spreken allemaal G.711 sowieso.
Dat blijkt duidelijk uit de flows.
De WeePee servers weten dit uiteraard vanuit de eerste SIP pakketten.
Dus dat ze niet met elkaar kunnen spreken gaat in deze gevallen geheel niet op.
't Zal wel eerder de richting uitgaan van mogelijkheid tot aftap.

Meer, op de Gigasets staat G.722 als geprefereerde codec en nadien pas de G.711.
Toch wordt de G.711 gekozen door de WeePee servers ondanks dat WeePee ook G.722 ondersteunt...
Ze zullen toch wel weten dat hun eigen klanten onderling aan het bellen zijn, hopelijk.

[peewee_power]

Zoals hier gezegd is transcoding en transrating het belangrijkst hier, alsook legal intercept (ja op gerechterlijk bevel zijn wij verplicht uw gesprekken af te tappen) en hier geldt dan ook het principe van topology hiding: alles achter de border elements (de sswx.brussels.weepee.org) is verstopt en verhindert dus inderdaad P2P RTP. Als wij niet Back to Back user agent zouden zijn, kunnen we ook nooit debuggen, kwaliteit monitoren, etc etc etc

Wat wel het geval is dat bij ons de Media Gateways, Registratie servers en signaling gateways dezelfde machines zijn. Bij andere providers is die architectuur anders.

[ubremoved_15739]

En betreffende voormelde WeePee keuze van de codec G.711 boven de geprefereerde codec G.722?

[peewee_power]

Wij forceren geen codec keuzes? Dus ik begrijp je punt niet echt?