SIP - Das Angebots- / Antwortmodell

Die Verwendung von SDP mit SIP ist in der SDP-Angebotsantwort RFC 3264 angegeben. Der Standard-Nachrichtentexttyp in SIP ist application/sdp.

Der Anrufer listet die Medienfunktionen auf, die er in SDP empfangen möchte, normalerweise entweder in einer EINLADUNG oder in einem ACK.
Der angerufene Teilnehmer listet seine Medienfunktionen in der 200 OK-Antwort auf die EINLADUNG auf.

Eine typische SIP-Verwendung von SDP umfasst die folgenden Felder: Version, Herkunft, Betreff, Uhrzeit, Verbindung sowie ein oder mehrere Medien und Attribute.

Die Betreff- und Zeitfelder werden von SIP nicht verwendet, sind jedoch aus Kompatibilitätsgründen enthalten.
Im SDP-Standard ist das Betrefffeld ein Pflichtfeld und muss mindestens ein Zeichen enthalten, das als s = - vorgeschlagen wird, wenn kein Betreff vorhanden ist.
Das Zeitfeld wird normalerweise auf t = 00 gesetzt. SIP verwendet die Verbindungs-, Medien- und Attributfelder, um Sitzungen zwischen UAs einzurichten.
Das Ursprungsfeld kann nur begrenzt mit SIP verwendet werden.
Die Sitzungs-ID wird normalerweise während einer SIP-Sitzung konstant gehalten.
Die Version wird bei jeder Änderung des SDP erhöht. Wenn der gesendete SDP gegenüber dem zuvor gesendeten unverändert bleibt, bleibt die Version unverändert.
Da der Typ der zu verwendenden Mediensitzung und der zu verwendende Codec Teil der Verbindungsverhandlung sind, kann SIP SDP verwenden, um mehrere alternative Medientypen anzugeben und diese Medientypen selektiv zu akzeptieren oder abzulehnen.

In der Angebots- / Antwortspezifikation RFC 3264 wird empfohlen, für jedes Medienfeld ein Attribut mit a = rtpmap: zu verwenden. Ein Medienstrom wird abgelehnt, indem die Portnummer für das entsprechende Medienfeld in der SDP-Antwort auf Null gesetzt wird.

Beispiel

Im folgenden Beispiel möchte der Anrufer Tesla einen Audio- und Videoanruf mit zwei möglichen Audio-Codecs und einem Video-Codec im SDP einrichten, die in der ersten EINLADUNG enthalten sind.

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Auf die Codecs wird durch die RTP / AVP-Profilnummern 97, 98 verwiesen.

Der angerufene Teilnehmer Marry nimmt den Anruf entgegen, wählt den zweiten Codec für das erste Medienfeld und lehnt das zweite Medienfeld ab, wobei nur eine AMR-Sitzung gewünscht wird.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Wenn dieser Nur-Audio-Anruf nicht akzeptabel ist, sendet Tom eine Bestätigung und dann ein BYE, um den Anruf abzubrechen. Andernfalls würde die Audiositzung eingerichtet und RTP-Pakete ausgetauscht.

Wie dieses Beispiel zeigt, würde der anrufende Teilnehmer nicht sicher wissen, welche Mediensitzungen vom angerufenen Teilnehmer akzeptiert und abgelehnt wurden, es sei denn, die Anzahl und Reihenfolge der Medienfelder wird beibehalten.

Die Angebots- / Antwortregeln sind in den folgenden Abschnitten zusammengefasst.

Regeln für die Erstellung eines Angebots

Ein SDP-Angebot muss alle erforderlichen SDP-Felder enthalten (dies umfasst v =, o =, s =, c = und t =). Dies sind Pflichtfelder in SDP.

Es enthält normalerweise ein Medienfeld ( m = ), muss es aber nicht. Die Medienzeilen enthalten alle Codecs, die in der gewünschten Reihenfolge aufgeführt sind. Die einzige Ausnahme besteht darin, dass, wenn der Endpunkt eine große Anzahl von Codecs unterstützt, die am wahrscheinlichsten akzeptierten oder am meisten bevorzugten Codecs aufgelistet werden sollten. Verschiedene Medientypen umfassen Audio, Video, Text, MSRP, BFCP usw.

Regeln zum Generieren einer Antwort

Eine SDP-Antwort auf ein Angebot muss gemäß den folgenden Regeln erstellt werden:

Die Antwort muss dieselbe Anzahl von m = Zeilen in derselben Reihenfolge wie die Antwort haben.
Einzelne Medienströme können abgelehnt werden, indem die Portnummer auf 0 gesetzt wird.
Streams werden durch Senden einer Portnummer ungleich Null akzeptiert.
Die aufgelisteten Nutzdaten für jeden Medientyp müssen eine Teilmenge der im Angebot aufgeführten Nutzdaten sein.
Für dynamische Nutzdaten muss nicht in jeder Richtung dieselbe dynamische Nutzlastnummer verwendet werden. Normalerweise wird nur eine einzige Nutzlast ausgewählt.

Regeln zum Ändern einer Sitzung

Jede Partei kann einen anderen Angebots- / Antwortaustausch initiieren, um eine Sitzung zu ändern. Wenn eine Sitzung geändert wird, müssen die folgenden Regeln befolgt werden:

Die Versionsnummer der Ursprungszeile ( o = ) muss entweder mit der zuletzt gesendeten übereinstimmen, was darauf hinweist, dass dieser SDP mit dem vorherigen Austausch identisch ist, oder sie kann um eins erhöht werden, was anzeigt, dass ein neuer SDP analysiert werden muss.
Das Angebot muss alle vorhandenen Medienzeilen enthalten und in derselben Reihenfolge gesendet werden.
Zusätzliche Medienströme können am Ende der m = Zeilenliste hinzugefügt werden .
Ein vorhandener Medienstrom kann gelöscht werden, indem die Portnummer auf 0 gesetzt wird. Diese Medienzeile muss im SDP verbleiben und alle zukünftigen Angebots- / Antwortaustausche für diese Sitzung.

Halten Sie an

Ein Teilnehmer eines Anrufs kann den anderen vorübergehend in die Warteschleife stellen. Dies erfolgt durch Senden einer EINLADUNG mit einem identischen SDP wie die ursprüngliche EINLADUNG, jedoch mita = sendonly Attribut vorhanden.

Der Anruf wird wieder aktiviert, indem eine weitere EINLADUNG mit dem gesendet wird a = sendrecvAttribut vorhanden. Die folgende Abbildung zeigt den Anrufverlauf eines gehaltenen Anrufs.