[Problem] Abgeschnittener Telefonatbeginn mit snom D385 und Fonial bei Nutzung des G.722-Codecs

[epistates]

Die Autoprovisionierung von Fonial setzt im snom bei codec_priority_list folgendes:

g722,pcmu,pcma

wenn ich das wie hier empfohlen abändere auf:

pcma,g722,pcmu

bringt dies leider keine Besserung. Wir haben in etlichen Tests nach wie vor einen abgehackten Gesprächsbeginn. Daher habe ich im Snom die Einstellung nur auf folgendes gesetzt:

pcma

Skurillerweise wird bei einem Anruf dann trotzdem auf den g722 zurückgegriffen und der Beginn des Telefonats wird wie üblich ganz kurz am Anfang abgeschnitten, also jemand sagt z.B. "Hallo, Müller am Apparat" dann kommt bei mir nur "...m Apparat" an. Dabei ist es egal ob die Anrufe von Dritten über Handys, Festnetz oder bspw. auch SIP-Apps kommen. Das Phänomen ist überall das gleiche. Lediglich bei Intern-Gesprächen tritt das Problem nicht auf.

Erst wenn die Gegenstelle ebenfalls auf pcma-only geht, wird das Gespräch in G.711 (pcma) geführt und das Telefonat ist am Anfang nicht abgeschnitten.

Kann man G.711 irgendwie erzwingen?
Warum ist der Gesprächsstart bei der HD-Telefonie (G.722) überhaupt verzögert?

 

[Joe_57]

Vermutlich, weil es die Gegenstelle kein G.722 kann oder die Verbindungsstrecke das Protokoll nicht durchgängig unterstützt.

 

[sonyKatze]

Kann man G.711 irgendwie erzwingen?

Normalerweise indem Du ausschließlich „pcma,telephone-event“ angibst. Das habe hier mein Snom mit 10er-Firmware eben auch nochmals getestet. Aber:

Skurillerweise wird bei einem Anruf dann trotzdem auf den g722 zurückgegriffen

Das sollten wir analysieren, weil ich das noch nicht nachstellen konnte. Auf der Web-Oberfläche des Snom siehst Du ein SIP-Log. Soweit ich das verstehe, betrifft das bei Euch Anrufe, die Ihr startet/beginnt. Oder betrifft das auch eingehende Telefonate?

Im SIP-Log müsste ein INVITE sein. Dort (nur) die Zeile m=audio … RTP/AVP anschauen. Welche Nummern folgen dort? Dürfte lediglich „8“ und „101“ sein. Wenn dort eine „9“ steht, ist G.722 irgendwie nicht richtig aus.

Auf das INVITE von Euch müssten ein oder mehrere SIP-Status folgen (100, 180, 200 und so weiter). Manche mit, manche ohne m=audio … RTP/AVP. Kannst Du von allen Antworten (nur) jene mit m=audio (nur) diese ganze Zeile und deren SIP-Status posten?

Warum ist der Gesprächsstart bei der HD-Telefonie (G.722) überhaupt verzögert?

Gute Frage. Manchmal wird während dem Gesprächsaufbau der Audio-Codec nachverhandelt. Einige SIP-Clients haben das noch nie gesehen und Chaos entsteht. Wir müssten im SIP-Log schauen, ob Fonial oder Snom ein solches re-INVITE schicken. Aber idealerweise schneidest Du die Datenpakete komplett mit, also sowohl Signalisierung (SIP) als auch Audio (RTP), sowohl im LAN (am Telefon bzw. nach der Firewall) als auch im WAN (vor der Firewall). Kann nämlich auch sein, dass Eure Firewall ein Problem hat, den einkommenden Audio-Strom zuzuordnen bzw. durchzulassen. Weißt Du wie man für Wireshark mitschneidet? Wenn nicht, welche Firewall hast Du genau (Hersteller, Produkt, Versionsstand)? Dann schaue ich mal nach, wie man die entsprechend bedient bzw. konfiguriert, damit man mitschauen kann.

 

[epistates]

m=audio 31052 RTP/AVP 9 8 0 101 13

Dort ohne SIP-Status...
...Davor und danach

SIP/2.0 200 Ok

Betrifft sowohl eingehende wie ausgehende Telefonate.

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Mit der neuen Einstellung: pcma,telephone-event

Sieht es jetzt so aus:

Ein IINVITE mit

m=audio 28546 RTP/AVP 9 8 0 101 13

Gefolgt von einem SIP/2.0 200 Ok mit

 m=audio 30222 RTP/AVP 8 101

Mir ist zudem aufgefallen das der G.722 offenbar mit der falschen Abtastrate daher kommt:
a=rtpmap:9 G722/8000
Müsste dort nicht "16000" stehen?

ist G.722 irgendwie nicht richtig aus.

Und wie bekomme ich das richtig aus?

 

[Meester Proper]

Mir ist zudem aufgefallen das der G.722 offenbar mit der falschen Abtastrate daher kommt:
a=rtpmap:9 G722/8000
Müsste dort nicht "16000" stehen?

Das ist alles korrekt:

„Even though the actual sampling rate for G.722 audio is 16,000 Hz, the RTP clock rate for the G722 payload format is 8,000 Hz because that value was erroneously assigned in RFC 1890 and must remain unchanged for backward compatibility. The octet rate or sample-pair rate is 8,000 Hz.“

– IETF: RFC 3551, Abschnitt 4.5.2

 

[sonyKatze]

Wie bekomme ich [G.722] richtig aus?

9 ist G.722. 0 is G.711 μ-law. 13 ist Comfort-Noise. Gute Frage. Mein Snom ohne Provisionierung für Fonial macht bei „pcma,telephone-event“ einfach nur G.711 A-law. Kannst Du die Auto-Provisionierung kurzzeitig ausschalten?

 

[epistates]

Auch mit deaktivierter Auto-Provisionierung findet keine Änderung des Phänomens statt. Und nun?
Das scheint mir aber auch kein explizites snom-Phänomen zu sein. Wenn ich mit meinem klassischen o2-Festnetz meine Fonial-Nummer in der SIP-App anrufe tritt das Phänomen ebenfalls auf. Und das ist ja erstens außerhalb des Büro-Netzwerkes und zweitens ohne snom-Hardware. Ich habe in der SIP-App sogar explizit alle Codecs ausgeschaltet außer G.711. Es scheint fast so, als ob Fonial auf die Telefon-/Client-Einstellungen pfeift und trotzdem G.722 verwendet.

Zudem fiel auf, das pcma,telephone-event die Verbindung zur Fonial-Konferenznummer unmöglich macht. Bei Eingabe der PIN kommt als Rückmeldung "ungültig". Bewirkt diese Einstellung ein Nichtfunktionieren von DTMF? Wenn ich nur pcma setze, klappt es mit der Konferenznummer und der PIN-Eingabe.

 

[sonyKatze]

keine Änderung des Phänomens

Bitte wie bei einer Матрёшка von Innen nach Außen vorgehen … bedeutet „Phänomen“, dass das Snom in seinem SDP-INVITE immer noch den Audio-Codec Nummer 9 (G.722) anbietet – trotz Abschaltung der Auto-Provisionierung? Oder bedeutet „Phänomen“, dass Du nicht noch einmal in den SIP-Ablauf reingeschaut hast, sondern den „abgehackten Gesprächsbeginn“ immer noch hast?

ob Fonial auf die Telefon-/Client-Einstellungen pfeift und trotzdem G.722 verwendet.

Das geht technisch nicht, jedenfalls auf Deiner Seite des Gesprächs. Was Fonial zwischen sich und dem Angerufenen macht, ist wieder was anderes. Wenn Dein VoIP/SIP-Client kein G.722 anbietet, dann ist das so, als könne es kein G.722. Dann kann Fonial zwischen Dir und sich auch kein G.722 fahren.

Bewirkt diese Einstellung ein Nichtfunktionieren von DTMF?

Jein. Die DTMF-Töne werden anders übertragen … wenn die Konferenz-Software die Töne anders braucht, dann kannst Du das im Snom an der entsprechende Stelle umstellen …