Wel, indien ik op beide Gigaset basisstations codec G.722 bovenaan in de lijst zet en G.711 (beiden) hieronder dan zal het gesprek toch met codec G.711 tot stand komen.
Enkel indien ik G.722 als enige beschikbare codec laat staan zal het gesprek ook daadwerkelijk met deze codec tot stand komen.
Ik had verwacht indien G.722 als meest geprefereerde codec staat dat deze dan ook gebruikt zou worden...
Nu G.711 is kwalitatief ook een goede codec, daar niet van natuurlijk. Maar codec G.722 is kwalitatief nog beter. Niet?
latency jumblo
-
- Elite Poster
- Berichten: 2831
- Lid geworden op: 13 jul 2010, 13:21
- Uitgedeelde bedankjes: 608 keer
- Bedankt: 542 keer
-
- ISP Official
- Berichten: 28
- Lid geworden op: 14 jan 2011, 23:36
- Bedankt: 14 keer
In onze core is altijd alles G711, dus de edge kan G722 aan, maar dit wordt ge-transcode richting onze core. Dus als beide endpoints ook G711 aanvaarden, kiezen we dat aangezien er dan geen transcoding (delay en kwaliteits impact) nodig is...
G722 is goed voor HQ audio (muziek etc...) voor gesprekken is G711 meer dan goed!
G722 is goed voor HQ audio (muziek etc...) voor gesprekken is G711 meer dan goed!
-
- Elite Poster
- Berichten: 2831
- Lid geworden op: 13 jul 2010, 13:21
- Uitgedeelde bedankjes: 608 keer
- Bedankt: 542 keer
Codec G.711 is inderdaad goed. Men verstaat elkaar duidelijk.
Doch, indien ik via giganet bel dan verloopt het gesprek met codec G.722, RTP-pakketten rechtstreeks tussen beide partijen, geen transcoding, geen kwaliteitsimpact, etc.
Het verschil tussen codec G.711 en codec G.722 is in deze omstandigheden toch zeer duidelijk merkbaar in de positieve zin.
Wel is het zo dat ik van Limburg ben. Dus het zou kunnen dat die G.722 muziek/zang codec meer geschikt is...
Doch, indien ik via giganet bel dan verloopt het gesprek met codec G.722, RTP-pakketten rechtstreeks tussen beide partijen, geen transcoding, geen kwaliteitsimpact, etc.
Het verschil tussen codec G.711 en codec G.722 is in deze omstandigheden toch zeer duidelijk merkbaar in de positieve zin.
Wel is het zo dat ik van Limburg ben. Dus het zou kunnen dat die G.722 muziek/zang codec meer geschikt is...

-
- Pro Member
- Berichten: 368
- Lid geworden op: 13 nov 2010, 18:30
- Locatie: Zaffelare
- Uitgedeelde bedankjes: 11 keer
- Bedankt: 7 keer
ik had gisteren thuis eens het IPadres ingegeven dat door de softphone van jumblo gebruikt wordt (wireshark). Ik kwam toen in canada uiteternum schreef:Waar vind jij dat de RTP server van Jumblo in Canada staat?

Ik moet dus gewoon eens kijken welke rtp-servers er gebruikt worden door de SPA3102 bij mij thuis. Ik zal een Vlan proberen te configureren in mn router of een goedkope manageble switch aankopen. Ik laat dan wel weten wat het resultaat is.
Alvast bedankt voor de grondige uitleg!
edit: geen Vlan maar werken met iptables en de --tee option in OpenWrt
-
- Pro Member
- Berichten: 368
- Lid geworden op: 13 nov 2010, 18:30
- Locatie: Zaffelare
- Uitgedeelde bedankjes: 11 keer
- Bedankt: 7 keer
Na een tijdje zoeken werkt het nu.
Vorige week had ik Jumblo al uitgeschakeld (uit ergernis) omdat de latency te groot was. Alles ging tot vandaag dan maar via WeePee. Vandaag heb ik gevonden hoe ik pakketten van de ATA (192.168.0.226) kan forwarden naar een Ubuntu-PC (192.168.0.145). (na het installeren van iptables-mod-tee en ip6tables op OpenWrt on WNDR3700v2)
Jumblo terug geactiveerd in de ATA (SPA3102) en een test gedaan naar GSM en geanalyseerd met Wireshark.
Conclusie: Er worden idd rtp-servers gebruikt in Nederland. De latency tot de RTP servers is ongeveer 40 ms.
Het rare is dat de kwaliteit van het geluid nu wel in orde is. Maar nu heb ik wel de mogelijk om het VoIP verkeer te analyseren met Wireshark indien de kwaliteit terug de wensen zou overlaten.
Alvast bedankt eternum
Vorige week had ik Jumblo al uitgeschakeld (uit ergernis) omdat de latency te groot was. Alles ging tot vandaag dan maar via WeePee. Vandaag heb ik gevonden hoe ik pakketten van de ATA (192.168.0.226) kan forwarden naar een Ubuntu-PC (192.168.0.145). (na het installeren van iptables-mod-tee en ip6tables op OpenWrt on WNDR3700v2)
Code: Selecteer alles
iptables -t mangle -A POSTROUTING -s 192.168.0.226 -j TEE --gateway 192.168.0.145
iptables -t mangle -A PREROUTING -d 192.168.0.226 -j TEE --gateway 192.168.0.145
Conclusie: Er worden idd rtp-servers gebruikt in Nederland. De latency tot de RTP servers is ongeveer 40 ms.
Het rare is dat de kwaliteit van het geluid nu wel in orde is. Maar nu heb ik wel de mogelijk om het VoIP verkeer te analyseren met Wireshark indien de kwaliteit terug de wensen zou overlaten.
Alvast bedankt eternum
-
- Moderator
- Berichten: 16487
- Lid geworden op: 28 apr 2008, 11:22
- Locatie: Waregem
- Uitgedeelde bedankjes: 820 keer
- Bedankt: 2998 keer
Voor een West-Vlaming die het verschil niet kan uitspreken tussen 'G'en 'H"' is G.729 meer den genoeg daneternum schreef:Wel is het zo dat ik van Limburg ben. Dus het zou kunnen dat die G.722 muziek/zang codec meer geschikt is...

Groeten (vanuit Nederland).
VoIP: WeePee (vaste nummers geporteerd), Sipgate.de, Sipgate.co.uk, MegaVoip (uitgaand België).
Provider: Proximus Start (60/4 mbps down/up).
Modem/Router: Fritz!Box 7590 int, OS 07.39-97058 BETA, profiel 100/35.
Telefoon centrale: Euracom 181 achter FritzBox So.
TV: Telenet CI+, Fritz!DVB-C.
Provider: Proximus Start (60/4 mbps down/up).
Modem/Router: Fritz!Box 7590 int, OS 07.39-97058 BETA, profiel 100/35.
Telefoon centrale: Euracom 181 achter FritzBox So.
TV: Telenet CI+, Fritz!DVB-C.
-
- Elite Poster
- Berichten: 2831
- Lid geworden op: 13 jul 2010, 13:21
- Uitgedeelde bedankjes: 608 keer
- Bedankt: 542 keer
Codec G.711 is narrow band (vergelijkbaar met ISDN gesprekskwaliteit).philippe_d schreef:Voor een West-Vlaming die het verschil niet kan uitspreken tussen 'G'en 'H"' is G.729 meer den genoeg daneternum schreef:Wel is het zo dat ik van Limburg ben. Dus het zou kunnen dat die G.722 muziek/zang codec meer geschikt is....
Groeten (vanuit Nederland).
Codec G.722 is wide band.
Misschien is het verschil tussen een West-Vlaamse "G" en een "H" gebruikmakend van codec G.722 wél hoorbaar...

[youtube]wiSIulBpto0[/youtube]
Gesprekken tussen Gigaset toestellen (met HDSP) gebruikmakend van codec G.722 en giganet zijn mijn inziens nog duidelijker en aangenamer dan de Aastra Hi-Q in bovenstaand filmpje ... maar dat zou ook aan de YouTube opname kunnen liggen natuurlijk.
Ter info voor het verschil in gesprekskwaliteit: promofilmpje van Siemens met een voorbeeld (vanaf 2'30") tussen een gesprek in "gewone" gesprekskwaliteit en in HDSP.
[youtube]b9TpGbQIN6U[/youtube]
Spijtig dat het WeePee netwerk G.722 onmiddellijk transcode naar G.711 richting hun core.
Op het WeePee netwerk is het voor mij niet mogelijk een wide band G.722 end-to-end gesprek te voeren.
Mijn beide basisstations kan ik wel forceren en enkel codec G.722 toelaten richting WeePee netwerk.
Doch de gesprekskwaliteit is, wegens de transcoding bij WeePee zelf, zeker geen wide band gesprekservaring.
Uit de SIP/SDP communicatie lijkt me ook duidelijk welke prioriteit aan de G.722 codec wordt gegeven bij WeePee.
Niet dat het veranderen van de volgorde enige gevolg zou hebben voor de uiteindelijke gesprekskwaliteit.
Afin, het zal wel een tijdje duren eer codec G.722 of dergelijke de gangbare standaard gaat worden.
