In der initialen Verbindungsanforderung (dem sog. Invite) werden die vom Anrufer angebotenen Codecs (beim Faxversand immer G.711) mit den jeweils gewünschten Eigenschaften als Payloadtypes im SDP angeboten. VBD (Voice Band Data) ist ein General Purpose Media Descriptor, um dem SIP Trunk mitzuteilen, dass eine Modemübertragung im Sprachband geplant ist und daher alle Funktionen, welche eine Manipulation der Payload erlauben (also z.B. Voice Activity Detection, Silence Suppression, Echo Cancellation, Codec Translation usw.) unterbleiben sollten, da diese das Modemsignal (eine Fax-Übertragung ist eine Modem-Übertragung) mitunter beeinträchtigen und zum Abbruch der Verbindung führen können.
In früheren Versionen des OfficeMaster wurde daher per Default zunächst eine Verbindung mit VBD (z.B. Payloadtype 8 mit Voice Band Data) im SDP des Invite angefordert und, wenn der Trunk dies ablehnte, eine neue, weitere Verbindung ohne VBD (ebenfalls Payloadtype 8) angefordert. Obwohl sich entsprechende Beispiele in der Spezifikation finden und diese Verhalten somit auch spezifikationskonform ist, lehnen manche SIP-Trunks die Ergänzung eines Standard-Payloadtypes (8) aber dennoch ab und betroffene SIP Trunk Betreiber wünschten sich für die Verwendung von VBD einen zusätzlichen dynamischen Payloadtype (auch dies erlaubt die Spezifikation). Deshalb wurde OfficeMaster dahingehend angepasst, dass im Rahmen der gleichen Verbindungsanforderung nun im SDP mit höchster Priorität z.B. G.711 a-law mit VBD als dynamischen Payload 96 und gleichzeitig mit niedriger Priorität auch G.711 a-law ohne VBD mit dem Standard-Payloadtype 8 angeboten wird. Somit sollte eigentlich jeder Trunk entsprechend seinen Möglichkeiten etwas Geeignetes auswählen können.
Zumindest soweit die Theorie, denn in der Praxis zeigten manche Trunks auch Probleme, wenn derselbe Codec (im genannten Beispiel G.711 a-law) zeitgleich in mehreren Payloadtypes (im obigen Beispiel 8 und 96) angeboten wurde. Teils führte dies dazu, dass der Trunk einerseits Payloadtype 96 aushandelt, aber anschließend andererseits Payloadtype 8 verwendet. Einen nicht ausgehandelten Payloadtype zu verwenden, widerspricht jedoch klar der Spezifikation und die Payload wird daher im Regelfall ignoriert werden, welches natürlich ebenso im Abbruch der Übertragung resultiert.
Um auch dies zu adressieren, lässt sich durch bewusst nicht veröffentlichte Parameter aktuell auch jede denkbare Permutation der oben genannten Einstellungen konfigurieren - so z.B. der komplette Verzicht auf die Signalisierung von VBD, welches natürlich zur Folge hat, dass nicht mehr signalisiert wird, dass eine Modemverbindung geplant ist und somit für entsprechende Qualitätseinbußen bis hin zu einer stark erhöhten Fehlerrate führen kann. Ebenso ist konfigurierbar, die Verwendung des Standard-Payloadtype 8 gänzlich zu deaktivieren und stattdessen nur noch den dynamischen Payloadtype 96 anzubieten. Last not least geht auch das umgekehrte, d.h. OfficeMaster kann veranlasst werden, keine dynamischen Payloads (also kein 96) und nur noch den Standard-Payloadtype 8 ergänzt um VBD (wie in der ursprünglichen Implementation des OfficeMaster) zu verwenden, welches laut Spezifikation immer noch zulässig ist.
Einen goldenen, immer richtigen Mittelweg der an allen existierenden Trunks funktioniert, gibt es daher leider nicht. Zur Vereinfachung und besserem Verständnis wurde die obige Schilderung des Sachverhalts ferner bewusst auf den Codec G.711 a-law beschränkt, während Faxübertragungen ebenso über G.711 µ-law möglich sind und die Konfiguration sich somit sinngemäß auch auf die ebenfalls implementierten Payloadtypes 0 und 97 erstreckt. Aufgrund der sich hieraus ergebenden Komplexität wurden die möglichen Konfigurationseinstellungen daher bewusst nicht veröffentlicht, sondern wir bitten um Ihr Verständnis, dass diese bei Bedarf über unsere Hotline erfragt werden sollten.
In früheren Versionen des OfficeMaster wurde daher per Default zunächst eine Verbindung mit VBD (z.B. Payloadtype 8 mit Voice Band Data) im SDP des Invite angefordert und, wenn der Trunk dies ablehnte, eine neue, weitere Verbindung ohne VBD (ebenfalls Payloadtype 8) angefordert. Obwohl sich entsprechende Beispiele in der Spezifikation finden und diese Verhalten somit auch spezifikationskonform ist, lehnen manche SIP-Trunks die Ergänzung eines Standard-Payloadtypes (8) aber dennoch ab und betroffene SIP Trunk Betreiber wünschten sich für die Verwendung von VBD einen zusätzlichen dynamischen Payloadtype (auch dies erlaubt die Spezifikation). Deshalb wurde OfficeMaster dahingehend angepasst, dass im Rahmen der gleichen Verbindungsanforderung nun im SDP mit höchster Priorität z.B. G.711 a-law mit VBD als dynamischen Payload 96 und gleichzeitig mit niedriger Priorität auch G.711 a-law ohne VBD mit dem Standard-Payloadtype 8 angeboten wird. Somit sollte eigentlich jeder Trunk entsprechend seinen Möglichkeiten etwas Geeignetes auswählen können.
Zumindest soweit die Theorie, denn in der Praxis zeigten manche Trunks auch Probleme, wenn derselbe Codec (im genannten Beispiel G.711 a-law) zeitgleich in mehreren Payloadtypes (im obigen Beispiel 8 und 96) angeboten wurde. Teils führte dies dazu, dass der Trunk einerseits Payloadtype 96 aushandelt, aber anschließend andererseits Payloadtype 8 verwendet. Einen nicht ausgehandelten Payloadtype zu verwenden, widerspricht jedoch klar der Spezifikation und die Payload wird daher im Regelfall ignoriert werden, welches natürlich ebenso im Abbruch der Übertragung resultiert.
Um auch dies zu adressieren, lässt sich durch bewusst nicht veröffentlichte Parameter aktuell auch jede denkbare Permutation der oben genannten Einstellungen konfigurieren - so z.B. der komplette Verzicht auf die Signalisierung von VBD, welches natürlich zur Folge hat, dass nicht mehr signalisiert wird, dass eine Modemverbindung geplant ist und somit für entsprechende Qualitätseinbußen bis hin zu einer stark erhöhten Fehlerrate führen kann. Ebenso ist konfigurierbar, die Verwendung des Standard-Payloadtype 8 gänzlich zu deaktivieren und stattdessen nur noch den dynamischen Payloadtype 96 anzubieten. Last not least geht auch das umgekehrte, d.h. OfficeMaster kann veranlasst werden, keine dynamischen Payloads (also kein 96) und nur noch den Standard-Payloadtype 8 ergänzt um VBD (wie in der ursprünglichen Implementation des OfficeMaster) zu verwenden, welches laut Spezifikation immer noch zulässig ist.
Einen goldenen, immer richtigen Mittelweg der an allen existierenden Trunks funktioniert, gibt es daher leider nicht. Zur Vereinfachung und besserem Verständnis wurde die obige Schilderung des Sachverhalts ferner bewusst auf den Codec G.711 a-law beschränkt, während Faxübertragungen ebenso über G.711 µ-law möglich sind und die Konfiguration sich somit sinngemäß auch auf die ebenfalls implementierten Payloadtypes 0 und 97 erstreckt. Aufgrund der sich hieraus ergebenden Komplexität wurden die möglichen Konfigurationseinstellungen daher bewusst nicht veröffentlicht, sondern wir bitten um Ihr Verständnis, dass diese bei Bedarf über unsere Hotline erfragt werden sollten.