Codec Negotiation (g711/g722)

[amc]

Hallo

Wir verwenden einen Asterisk 1.6.2.5-0ubuntu1 Server mit Snom Telefonen. Intern telefonieren wir mit dem Breitbandcodec g722. Nach extern sind wir via SIP-Trunk mit g711 an unseren VoIP-Provider angebunden.

Wegen NAT und vereinfachter Firewall-Konfiguration sowie Nutzung gewisser Asterisk-Features schleusen wir alle Gespräche von und nach Extern über den Asterisk-Server (sip.conf canreinvite=no).

Eigentlich funktioniert alles tiptop. Nun habe ich aber festgestellt, dass Asterisk in dieser Konstellation bei Gesprächen von und nach Extern intern weiterhin g722 verwendet und nach extern auf g711 übersetzt. Dies obschon sowohl die Snom Telefone wie auch Asterisk als 2. Codec-Priorität auch g711 akzeptieren würden. Es entsteht dadurch ja eigentlich völlig unnötige Transcoding-Last auf der Server?

Wie ist es möglich interne Gespräche zwar weiterhin mit g722 führen zu können, bei externen aber den ganzen Medien-Pfad auf g711 zu zwingen?

Besten Dank für Eure Hilfe

amc

 

[alfred37]

Hallo,

trotzdem mir der Vorteil von G722 gegenüber G711 nicht klar ist, sieht die Lösung folgend aus:
Konfiguriere im SNOM jeweils einen eigenen SIP-account für externe und interne Gespräche.

Beim account für externe Gespräche stellst Du G711a als Codec ein, beim internen G722.
Am Asterisk brauchst Du ebenfalls 2 SIP-accounts, mit den gleichen Einstellungen.

Die SNOMs sind natürlich mittels Dialplans entsprechend zu konfigurieren, sodass der jeweils richtige account verwendet wird.

Einfacher wäre es IMHO einfach überall G711a zu verwenden

 

[amc]

Hallo alfred37

Danke für Deine rasche Antwort. Mit der neuen Generation von VoIP-Telefonen bietet der g722-Codec doch eine deutliche Verbesserung der Gesprächsqualität. Und wenn doch schon die technischen Mittel vorhanden sind, will man davon auch profitieren, oder ;-)

Dein Vorschlag ist zwar interessant, aber ja nicht wirklich elegant. Ich würde mir eigentlich vorstellen, dass Asterisk dynamisch die beiden Partner auf einen Nenner bringt (hier also g711) und damit seine Ressourcen für andere Zwecke schont.

 

[alfred37]

Ich würde mir eigentlich vorstellen, dass Asterisk dynamisch die beiden Partner auf einen Nenner bringt (hier also g711) ...

Genau das macht Asterisk hier:
Das SNOM Telefon meldet sich an und sagt, dass es am liebsten G722 spricht, der konfigurierte SIP-account sagt "Ja, kann ich", und der eine SIP-Trunk steht. Anschließend versucht asterisk den Call zum SIP-Trunk des Carriers zu verbinden, der sagt, dass er nur G711a spricht, das Protokoll wird dynamisch übersetzt und der Call steht.

Guck mal wieviel Ressourcen das Codec Konvertieren wirklich benötigt, normalerweise braucht asterisk nicht allzuviel CPU-Power

 

[rmh]

Hallo amc,

die Frage hat mich im April ebenfalls beschäftigt. Bis heute fehlt auch mir eine - wie du sagst - elegante Lösung. Siehe dieser Beitrag: http://www.ip-phone-forum.de/showthread.php?t=213953


Gruß
R.

 

[amc]

alfred37 hat das schön beschrieben und dort liegt wohl das Problem begraben: Zuerst wird vom internen Telefon zum Asterisk ein Channel aufgebaut und erst dann in einem zweiten, unabhängigen Schritt der Channel zum VoIP-Provider. Dabei wird nicht zwischen den beiden Endpunkten, sondern zwischen Endpunkt und Asterisk der Codec "verhandelt".

Es sollte meiner Meinung nach eine Möglichkeit geben, die Codecs nachträglich noch einmal zu verhandeln; also so, wie wenn die beiden Peers bei einem Reinvite direkt untereinander die Codecs verhandeln würden.

Hat jemand sich schon mal mit der Variable ${SIP_CODEC} auseinandergesetzt? Die soll ja den Codec für den inbound Call (=first leg) definieren.

Wünsche einen schönen Tag!
amc

 

[rmh]

Guter Hinweis. Scheinbar gibt es für 1.6.2.x neue Variablen wie SIP_CODEC_OUTBOUND. Klingt zunächst vielversprechend, were mich einlesen und sehen wie man den patch umsetzten kann.
EDIT: Scheint ein neues Feature in *1.8 zu sein. Siehe CHANGES.

 

[amc]

ok, bin gespannt... Meine ersten Versuche scheiterten kläglich...

 

[rmh]

Bei mir läuft derzeit Asterisk 1.6.2.10. Anbei ein paar Schnipsel (prinzipiell) aus meiner Konfiguration.

sip.conf

disallow                        = all                      
allow                           = g722
allow                           = alaw

extensions.conf in der Zeile vor dem Dial die Variable SIP_CODEC setzen

exten => _X.,n,Set([COLOR="SeaGreen"]SIP_CODEC[/COLOR]=alaw)

*CLI>

[Jul 29 20:41:52] NOTICE[29183]: chan_sip.c:6184 try_suggested_sip_codec: [COLOR="SeaGreen"]Changing codec to 'alaw' for this call because of ${SIP_CODEC} variable[/COLOR]

Also ausgehend funktioniert es schon mal! Sehr sehr fein.
Eingehende g722 Gespräche konnte ich noch nicht testen, sollten aber nach der codec Rehenfolge der sip.conf bearbeitet- und damit theoretisch richtig vermittelt werden.

 

[amc]

:groesste:

es funktioniert!! Mit dieser Lösung kann ich leben! Sie ist zwar auch nicht 100% "elegant", aber immerhin...

Was mich etwas wundert ist, dass ich die Zeile mit der NOTICE try_suggested_sip_codec dreimal hintereinander aufgelistet kriege. Bei mir läuft auch Asterisk 1.6.2.10.

 

[rmh]

Was mich etwas wundert ist, dass ich die Zeile mit der NOTICE try_suggested_sip_codec dreimal hintereinander aufgelistet kriege.

Das ist mir ebenfalls aufgefallen. Ich vermute das sind Standardausgaben, um das erfolgreiche Erzwingen des Codecs zu bestätigen. Einmal die Bestätigung von Asterisk/Nebenstelle, das zweite mal von Asterisk/Provider, das dritte mal für die Packet2Packet bridge. Ist nur eine These, um das genauer zu verstehen müsste man mal im chan_sip nachsehen.


Gruß
R.