SIP Delayed Offer

Diese Seite beschreibt eine Besonderheit im SIP-Protokoll zur Aushandlung der Audio und Video Endpunkte. Normalerweise passiert dies mit der ersten Einladung. In einigen Fällen aber erst später. Beide Möglichkeiten sind übrigens als verpflichtend im SIP Standard hinterlegt. Es gibt also kein besser oder schlechter. Ssie haben beide ihre vor Nachteile und Endgeräte müssen beide Varianten unterstützt, wobei "Early Offer" deutlich häufiger genutzt wird. und "Late Offer" daher weniger bekannt ist. Auf die Bedeutung der Vorteile der ein oder anderen Funktion komme ich weiter unten.

Normalfall (SIP Early Offer)

Wenn zwei Gegenstellen über das Protokoll SIP eine Verbindung aufbauen wollen dann sendet der Initiator normalerweise ein INVITE zum Ziel, Welche auch alle notwendigen Informationen für den späteren verbindungsaufbau enthält das heißt die IP Adressen der Kandidaten als auch die verwendeten Codecs und die gewünschte Nutzung durch Audio oder Video oder Desktop Sharing oder ähnliches in einer SDP - Session Description Protocol-Struktur. Das Ziel seinerseits melde den Anruf und sendet mit der Rückmeldung ebenfalls seine Kandidaten.

Beide Endpunkte ermitteln dann die möglichen RTP-Verbindungen Und teilen sich danach mit welche Kandidaten letztlich zum Einsatz kommen. Dieses Ablaufdiagramm ist natürlich stark vereinfacht. so fehlen die diversen zwischen Meldungen wie ein „100 TRYING“ oder ein „183 SESSION PROGRESS“ und diverse PRACK die nach Protokoll zusätzlich vorkommen.

Delayed Offer

In Verbindung mit einem verspäteten SDP hingegen enthält der INVITE keine Informationen über Kandidaten und Codecs. Das Ziel sendet aber seine Kandidaten zurück, worauf der Anrufer mit einem ACK antwortet.

Erst nach dem Eingang des ACK beim Ziel kann das Ziel ermitteln welche Kandidaten die Quellen nutzt und seinerseits mit einem 200 OK die ausgewählten Kandidaten auf seiner Seite an den Anrufer senden. Hier mal am Beispiel eines Audiocodes Gateway:

Ein Anruf kommt per ISDN beim Gateway an, welches dann den Anruf nach intern weiter gibt. Der erste INVITE enthält keinen SDP. Erst später kommt auf das "200 OK" der Gegenstelle 10.1.1.2 ein "ACK (SDP)" vom Gateway zum Ziel.

Warum das Ganze?

Hierbei stellt sich natürlich die Frage, warum ein Anrufer an den Empfänger seine Kandidaten erst verzögert senden möchte. Normalerweise haben ja beide Endpunkte etwas davon, möglichst früh ihre Kandidaten zu kennen, um basieren darauf dann eine RTP-Verbindung aufzubauen.

Die Übermittlung der Kandidaten direkt mit der ersten Einladung (INVITE) Ist natürlich der häufigste Fall, der anzutreffen ist. Bei dieser Konstellation kennt der Anrufer natürlich überhaupt keine Informationen des angerufenen Ziels. Ein Vermittlungssystem kann daher die Auswahl der Codecs oder die Auswahl der Kandidaten noch nicht einschränken. Das kann in diesem Fall nur der angerufene Teilnehmer, welche anhand der Kandidaten des Anrufers und seiner eigenen Kandidaten und der angeboten Kodex in die Verbindung eingreifen kann. Die Verarbeitung von Kandidaten beim angerufenen Teilnehmer öffne daher die Möglichkeit bestimmte Verbindungen zu unterbinden oder bestimmte Codecs zu verhindern.

Wenn jedoch der Anrufer ein Interesse daran hat die Verbindung und verwendeten Codecs zu optimieren, dann sollte der Anrufer selbst zuerst keine Kandidaten mit schicken und auf die Rückantwort des Empfängers warten, der immer seine Kandidaten liefern muss. Wenn er dann die Rückantwort des Empfängers mit besten Kandidaten hat, kann er seine Kandidaten auf die Kommunikation besser abstimmen.

Leider ist es nicht möglich, dass beide Parteien sich individuell auf die Verbindung abstimmen. Diese individuelle Anpassung öffnet sich aber nur immer genau einem Teilnehmer, wobei der Anrufer bestimmt ob er seine Kandidaten schon beim INVITE sendet. so dass sich der angerufene Teilnehmer auf die Kandidaten einstellen kann. Der Anwendungsfall ist zum Beispiel in einem Call Center zu sehen. wenn ein Call Center Agents einen Anruf startet. Meist startet eine Software im Auftrage den Anruf.

In einem Call Center gibt es viele Agenten. Häufig werden ausgehende Anrufe schon gestartet ohne zu wissen, welche Agent diesen Ruf dann direkt bearbeiten wird. So kann sich die Wartezeit eines Agenten vermindern lassen während der Ruf aufgebaut wird. Zu diesem Zeitpunkt gibt es aber noch gar keine IP Adresse eines Agenten die der Gegenseite übermittelt werden kann. Erst wenn die Gegenseite den Ruf angenommen hat und seinerseits Agenten liefert, kann das Call Center sofort den nächsten freien Agenten suchen und dessen Kandidaten entsprechend zurückliefern.

Konfiguration

Gemäß der Beschreibung des sie Protokolls müsste jeder SIP-Client oder Server natürlich beide Varianten unterstützen. Allerdings ist gerade die Unterstützung einer verspäteten SDP-Übermittlung nicht überall komplett ausgeführt. Sie sollten nicht davon ausgehen, dass jede Software auch eine nachträgliche Übermittlung von Kandidaten fehlerfrei unterstützt. Entsprechend gibt es bei Session Border Controllern und Gateways in der Regel auch eine Konfigurationseinstellungen, ob diese Funktionen genutzt werden darf oder nicht.

Da ich primär mit Audiocodes-Gateway zu tun habe, dokumentiere ich hier deren Einstellungen. Anderer Produkte dürfte vergleichbare Optionen haben. Meist geht es ja nur darum die Funktion ausgehend abzuschalten. Gegen eingehende Pakete ohne SDP kann sich ein System ja nicht wirklich wehren. Hier muss dann die Gegenseite die Konfiguration anpassen, wenn ihr System damit nicht umgehen kann.

Bei Audiocodes gibt es zwei Stellen zur Anpassung:

  • Global:. Configuration->VoIP->SIP Definitions->Advanced Parameters
    Dies ist der globale Default für alle SIP-Verbindungen.

Achtung: Diese Einstellung führt dazu, dass auch das Gateway bei ausgehenden Anrufen ein INVITE ohne SDP versendet, wenn auf dem IP-Profil die nicht überschrieben wird.

  • IP-Profile
    Über die Einstellung der IP-Profile, die sie dann auf die Einzelnen Verbindungen anwenden, können Sie individuell die Verwendung steuern:

In der Anleitung ist gut zu sehen, welche Einstellungen z.B. für Lync 2013 vorgenommen werden sollen:


https://www.audiocodes.com/media/10259/ltrt-39360-mediant-e-sbc-for-g12-communications-sip-trunk-with-microsoft-lync-2013-configuration-note.pdf  Seite 43

Das bedeutet damit natürlich auch. das der Mediation Server damit nicht umgehen kann und sie daher zumindest bei einem INVITE zu Lync 2013 immer auch einen SDP mit senden müssen. Wenn die andere Seite keinen SDP sendet, dann muss das Gateway bzw. der SBC als B2BUA und Media-Relay agieren.

"SBC Delayed SDP offer is supported only by devices that support DSP transcoding"
Audiocodes Release Notes 7.0 https://www.audiocodes.com/media/13261/sip-gateways-sbcs-release-notes-ver-70.pdf

Für Transcoding können aber je nach Gateway zusätzliche Hardware (DSP-Chips) oder Lizenzen erforderlich sein.

Weitere Links