SDP - Session Description Protocol

Auf der Seite ICE und Kandidaten habe ich den Aspekte einer SIP-Verbindung beschrieben, wie die Endpunkte miteinander die IP-Adressen und letztlich eine IP-Verbindung erreichen. SDP steht für Session Description Protocol und ist eine "Nutzlast", die über ein SIP-Paket übertragen wird. Während SIP primär der Anmeldung, Signalisierung und Konfiguration dient, kann über SIP selbst nicht "gesprochen" werden. Die Datenverbindungen zwischen zwei Endpunkten um z.B. Audio, Video, Desktop-Sharing o.ä. zu übertragen laufen am SIP-Paket vorbei. Aber per SIP-Paket findet der Austausch dieser zusätzlichen Konfigurationsinformationen statt.

Beispiel "Phone Call" v=0

Als Beispiel haben Sie hier den Syslog-Trace eines ausgehenden Rufs. Sie sehen gute den "INVITE" als Befehl und dann die Headerzeilen mit weiteren Informationen. Interessant ist nun alles nach dem "CONTENT-TYPE: application/sdp". Dies ist der SDP, um den es hier geht.

INVITE sip:192.168.100.107:5061;transport=tls;User=phone SIP/2.0
FROM: <sip:+495251304613;ext=613@netatwork.de;User=phone>;epid=6CDC4E66B4;tag=182da16c49
TO: <sip:+495249700971@nawm1000.netatwork.de;User=phone>;tag=1c789721132
CSEQ: 85419 INVITE
CALL-ID: 1f5219b6-2923-46de-8a19-8dd774e631ae
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 192.168.100.100:53951;branch=z9hG4bK2e7b2985
CONTACT: <sip:nawlync001.netatwork.de:5067;transport=Tls;ms-opaque=1984a8a7f0f3aaa4>
CONTENT-LENGTH: 373
SUPPORTED: 100rel User-AGENT: RTCC/5.0.0.0 MediationServer
CONTENT-TYPE: application/sdp

v=0
o=- 0 4 IN IP4 192.168.103.63
s=session
c=IN IP4 192.168.103.63
b=CT:99980
t=0 0
m=audio 6354 RTP/SAVP 0 13 101
c=IN IP4 192.168.103.63
a=rtcp:6355
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:6kAMn8ieN/mPZNbxZTJjdkROJGc4GJzEYlkoHPhY|2^31|1:1
a=inactive
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Der Aufbau der Information ähnelt einer früheren "win.ini" nur ohne Sektionen. Das "="-Zeichen trennt die Variable vom Wert. Dieses Beispiel ist ein sehr einfache Muster einer Verbindung ohne umfangreiche Kandidaten.

Erforderliche Felder

Einige der Felder sind zwingend vorgeschrieben, während andere Felder optional sind. 

Feld Beispiel Feldname
Format
Beschreibung

v=

v=0 

protocol version, Ist eigentlich immer 0

o=

o=- 0 4 IN IP4 192.168.103.63

session owner and identifier

o=<Username> <session id> <version> <network type> <address type> <address

IN = Internet

s=

s=SIP Call
s=Phone Call

s=<session name>

beschreibt die Session.

t=

t=0 0

t=<start time> <stop time>

Zeit, in der die Session aktiv ist. Auch wenn es ein verpflichtendes FEld ist, ist es für SIP eigentlich irrelevant. Wer will schon die Dauer eines Anrufs vorhersehen. Wenn das geht, dann stehen hier die Sekunden seit 1900.

m=

m=audio 11424 RTP/AVP 0 8 101
m=audio 6354 RTP/SAVP 0 13 101

media type, format, and transport address

m=<media> <port> <transport> <format list> 

  • Media
    üblicherweise audio odervideo
    wenn mehrere Medien übertragen werden, dann gibt es mehrere solcher Zeilen
  • Port
    Der Port sollte immer "Gerade" sein und der nächste ungerade Port wird dann für RTCP genutzt
  • <transport>
    In der Regel RTP/AVP. Siehe auch RFC3551 unter "RTP protocol with the profile für "Audio and Video Conferences with Minimal Control"
  • <format list>
    Listet die verschiedenen Codecs auf, die im folgenden genauer spezifiziert werden. Einige Nummern sind vorbelegt
    0=G.711 uLaw
    8=G.711 ALaw
    3=GSMcodec
    18=G.729
    Die Reihenfolge gibt zugleich die Präferenz vor.

Optionale Felder

Nur weil ein Feld hier als Optional geführt wird, sollten Sie dies nicht missverstehen. Welche dieser optionalen Felder letztlich doch "erforderlich" sind hängt von der jeweiligen Anwendung ab. Sie sind nur bezüglich des strukturellen Aufbaus eines SDP optional.

Feld Beispiel Feldname
Format
Beschreibung

c=

c=IN IP4 192.168.103.63

connection information

c=<network type> <address type> <connection address>

Dieses Feld ist "halb" optional. Es muss nicht erscheinen aber wenn es erscheint, dann ist es auf der Ebene der Session und gilt für die ganze Session oder es ist Teil des "m="-Felds hinter der Liste der Formate.

i=

i=xxxx

session information

i=<textual description>

Die Session Information kann auf dem Session Level oder innerhalb der "m="-Felder erscheinen.

k=


																				

encryption key

k=<method>:<encryption key> or k=<method>

Hiermit wird ein Verschlüsselungskey definiert. er kann auf dem Session Level oder innerhalb der "m="-Felder erscheinen.

a=

a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

session attributes

a=<attribute> or a=<attribute><value>

Die SDP-Meldungen kann 0 oder mehrere Session Attribute enthalten. Es gibt eine ganze Menge von verschiedenen Attributen, denen ich daher einen eigenen Abschnitt gewidmet habe.

b=

b=CT:99980 

Bandwidth information 

Es gibt durchaus noch weitere Felder, die für Lync aber weniger interessant sind. Wer es genau wissen möchte, sei auf die RFC4566 SDP: Session Description Protocol (https://tools.ietf.org/html/rfc4566) verwiesen.

Attribute

Diese optionalen Attribute beschreiben in der Regel genauer die verwendeten Formate. Sie beginnen alle mit einem "a="

Attribut Beispiel Format and Description

a=rtpmap

a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

RTMAP

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]

Dieses Attribut kommt in der Regel gleich mehrfach vor und definiert die verschiedenen angeboteten Codecs, mit ihren Nummern, die vorher in der Zeile "m=audio 11424 RTP/AVP 0 8 101" referenziert wurden.

a=sendrecv

a=sendrecv

a=sendrecv

Der Eintrag "a=sendrecv" bestimmt, dass die Verbindung in beide Richtungen aufgebaut wird. Es kann auch ein "SendOnly" oder "RecvOnly" drin stehen. Solch ein SDP wird z.B. während des Gesprächs als INVITE zur Anzeige einer Stummschaltung gesendet.

Manchmal sieht man hier auch ein "inactive" oder "broadcast"

a=ptime

a=ptime:20

a=ptime:<packet time>

Dieser Wert gibt optional mit an, wie viele Millisekunden in einem RTP-Paket übertragen werden. Bei dynamischen Codecs wie RTAUDIO steht es auch auf 20ms, obwohl der Codec natürlich während des Gesprächs dies anpassen kann. Es ist aber interessant für statische Codecs wir G.711, die keine dynamik können.

a=fmtp

a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=fmtp:101 0-16

a=fmtp:<format> <format specific parameters>

Über das Attribut "fmpt" kann man zu einem bestimmten codec noch weitere Parameter versenden. Meist sehen Sie hier den Codec 101 (für DTMF-Töne) mit der erweiterten Information "0-16", welche die erlaubten Zeichen 0-9 und A-F mitteilt.

Auch hier gibt es durchaus weitere Attribute, die weiter untersucht werden können.

MultiPart SDP

Nicht immer befindet sich in einem SIP-Paket genau ein SDP. ähnlich wie bei SMTP-Mails können verschiedene SDP-Formate in einer Message enthalten sein. Sie werden wie bei SMTP abgetrennt. Hier ein Ausschnitt

Content-Type: multipart/alternative; boundary=gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7
Content-Type: application/sdp
Content-ID: <ce14e3cf-e7f9-4e27-8471-7b8afb86de6b>
Content-Disposition: Session;handling=optional;ms-proxy-2007fallback

v=0
...a=fmtp:101 0-16,36

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7
Content-Type: application/sdp
Content-ID: <4db9ee25-f671-43d6-858c-667ca097aaa9>

v=0
...a=ptime:20
a=x-mediasettings:signalboostunsupported

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7

Der Grund hierfür ist, dass es mittlerweile mehrere Formate gibt, wie sie in den Beispielen weiter unten sehen, und moderne Clients die neuen Möglichkeiten nutzen wollen aber das "alte Format" zusätzlich mit senden, falls die Gegenseite das neue Format mal nicht versteht.

ICEv6 und ICEv19

So gibt es zwei von Microsoft genutzte Definition der Kandidaten. ICEv6 ist die zuerst verwendete Beschreibung, die z.B. schon Exchange 2007 und OCS unterstützen. Neuere Clients nutzen beide während der Skype for Business 2016 Client anscheinend nur noch ICEv19 verwendet. Das führt aber auch dazu, dass z.B. ein Skype for Business 2016 Client nicht mehr mit Exchange 2007 UM sich verbinden kann.

ICEv19

a=candidate:1 1 UDP 2130706431 192.168.100.100 52028 typ host
a=candidate:1 2 UDP 2130705918 192.168.100.100 52029 typ host
a=candidate:2 1 tcp-pass 174456319 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:2 2 tcp-pass 174455806 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:3 1 UDP 184548351 80.66.20.21 59334 typ relay raddr 192.168.100.100 rport 53944
a=candidate:3 2 UDP 184547838 80.66.20.21 55715 typ relay raddr 192.168.100.100 rport 53945
a=candidate:4 1 tcp-act 174848511 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:4 2 tcp-act 174847998 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:5 1 tcp-act 1684797439 192.168.100.100 49366 typ srflx raddr 192.168.100.100 rport 49366
a=candidate:5 2 tcp-act 1684796926 192.168.100.100 49366 typ srflx raddr 192.168.100.100 rport 49366

ICEv6

a=candidate:sKB/DojWGcwJ3sOyjk1H0CitsSiN8iLRUi3jpSkJGRM 1 5T3+GkALCNYzP3CoULX8Gw UDP 0.830 192.168.100.100 56340
a=candidate:sKB/DojWGcwJ3sOyjk1H0CitsSiN8iLRUi3jpSkJGRM 2 5T3+GkALCNYzP3CoULX8Gw UDP 0.830 192.168.100.100 56341
a=candidate:AYrGKytapaHMK+lmXLEDCXOBUq4aI+ucGwJDsOx7GnI 1 0BAXHbmamSJ5YMXj17/sSg TCP 0.150 80.66.20.21 53885
a=candidate:AYrGKytapaHMK+lmXLEDCXOBUq4aI+ucGwJDsOx7GnI 2 0BAXHbmamSJ5YMXj17/sSg TCP 0.150 80.66.20.21 53885
a=candidate:XW4dqWxam0TRBg6pOQU9Yzgz5JlTtO1vcpUSx1yCkjc 1 mvCuaylFyY/GEnJKaQe4ow UDP 0.450 80.66.20.21 50166
a=candidate:XW4dqWxam0TRBg6pOQU9Yzgz5JlTtO1vcpUSx1yCkjc 2 mvCuaylFyY/GEnJKaQe4ow UDP 0.450 80.66.20.21 53017
a=candidate:2j9FM2jWF693Dl1xHdB2xa8J7R0l/avC/kS9mT+Mfnc 1 mBdk74Y/cVMvhkqA/Ps0wQ TCP 0.250 192.168.100.100 52566
a=candidate:2j9FM2jWF693Dl1xHdB2xa8J7R0l/avC/kS9mT+Mfnc 2 mBdk74Y/cVMvhkqA/Ps0wQ TCP 0.250 192.168.100.100 52566

Useragent und ICE-Version

Ich habe mal ein paar UserAgenten und deren ICESDP Kandidaten aufgelistet, die ich aus verschiedenen SIP-Traces extrahiert habe. Ein "NEIN" bedeutet aber nicht, dass die Systeme das jeweilige ICE-Protokoll nicht können, sondern nur, dass ich in den Traces keine entsprechenden Kandidaten  gesehen habe. Das kann durchaus daran liegen, dass z.B. ICEv19 abgeschaltet war, der Patchstand nicht passte oder es eine Antwort auf ein INVITE war, in dem kein ICEv19 Angebot zu finden war.

User Agent  ICEv6 ICEv19

Skype for Business Client 2016

NEIN

Ja

Skype for Business Client 2013 

Ja

Ja

Skype for Business MCU 

Ja

Ja

RTCC/5.0.0.0 MediationServer 

Ja

Ja

Lync 2013 RTCC/4.0.0.0 MediationServer 

Ja

Ja

Lync 2013 Server MCU

Ja

Ja

Lync 2013 Client
UCCAPI/15.0.4517.1004 OC/15.0.4517.1004 (Microsoft Lync)

Ja

Ja

UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010) 
UCCAPI/4.0.7577.256 OC/4.0.7577.280 (Microsoft Lync 2010)

Ja

Ja

Lync Mobile Client

 

 

Audiocodes-Sip-Gateway-Mediant 1000 - MSBG/v.6.20A.031

Ja

Ja

Mediant 1000/v.6.80A.270.002

Ja

Nein 

MP-124 FXS/v.6.60A.254.005

Ja

Nein 

MP-114 FXS/v.6.60A.241.010

Ja

Nein 

AUDC-IPPhone-420HD_UC_2.0.1.44.5/1.0.0000.0

Ja

Nein

LifeSize Room 220/LS_RM2_5.0.1 (3)

Ja

Nein

PolycomVVX-VVX_500-UA/5.2.0.8330

Ja

Nein

snom760/8.8.2.21-OCS

Ja

Ja

Weitere SDPs

Ich habe hier mal ein paar SDPs als Beispiele veröffentlicht, die ich allesamt auf meinem Client generiert habe.

Einfache IM zu einem Federation Partner

Ich habe einfach eine "Test-Meldung" an einen Lync Partner gesendet. Der erste INVITE hat folgenden SDP, in dem Sie sehen, dass es eine Message ist und welche Formate ich verstehe

v=0
o=- 0 0 IN IP4 192.168.178.64
s=session
c=IN IP4 192.168.178.64
t=0 0
m=message 5060 sip null
a=accept-types:text/plain multipart/alternative image/gif text/rtf text/html application/x-ms-ink application/ms-imdn+xml text/x-msmsgsinvit

Die andere Seite antwortet natürlich im einem Trying und Ringing aber ohne SDP. Sie sendet ja erst mal nichts und letztlich braucht man für Kurzmitteilungen ja auch keinen RTP-Kanal.

Lync Call zwischen mir und einem NAW Mitarbeiter spät abends, beide extern zu hause

Zuerst einmal mein erster INVITE über den Edge zum Anrufziel. Sie sollten neben den Candidates sehen können, dass ich Audio anbiete.

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7
Content-Type: application/sdp
Content-ID: <ce14e3cf-e7f9-4e27-8471-7b8afb86de6b>
Content-Disposition: Session;handling=optional;ms-proxy-2007fallback

v=0
o=- 2739 0 IN IP4 192.168.100.100
s=session
c=IN IP4 192.168.100.100
b=CT:1000000
t=0 0
m=audio 56340 RTP/AVP 0 8 115 13 118 97 101
c=IN IP4 192.168.100.100
a=rtcp:56341
a=candidate:sKB/DojWGcwJ3sOyjk1H0CitsSiN8iLRUi3jpSkJGRM 1 5T3+GkALCNYzP3CoULX8Gw UDP 0.830 192.168.100.100 56340
a=candidate:sKB/DojWGcwJ3sOyjk1H0CitsSiN8iLRUi3jpSkJGRM 2 5T3+GkALCNYzP3CoULX8Gw UDP 0.830 192.168.100.100 56341
a=candidate:AYrGKytapaHMK+lmXLEDCXOBUq4aI+ucGwJDsOx7GnI 1 0BAXHbmamSJ5YMXj17/sSg TCP 0.150 80.66.20.21 53885
a=candidate:AYrGKytapaHMK+lmXLEDCXOBUq4aI+ucGwJDsOx7GnI 2 0BAXHbmamSJ5YMXj17/sSg TCP 0.150 80.66.20.21 53885
a=candidate:XW4dqWxam0TRBg6pOQU9Yzgz5JlTtO1vcpUSx1yCkjc 1 mvCuaylFyY/GEnJKaQe4ow UDP 0.450 80.66.20.21 50166
a=candidate:XW4dqWxam0TRBg6pOQU9Yzgz5JlTtO1vcpUSx1yCkjc 2 mvCuaylFyY/GEnJKaQe4ow UDP 0.450 80.66.20.21 53017
a=candidate:2j9FM2jWF693Dl1xHdB2xa8J7R0l/avC/kS9mT+Mfnc 1 mBdk74Y/cVMvhkqA/Ps0wQ TCP 0.250 192.168.100.100 52566
a=candidate:2j9FM2jWF693Dl1xHdB2xa8J7R0l/avC/kS9mT+Mfnc 2 mBdk74Y/cVMvhkqA/Ps0wQ TCP 0.250 192.168.100.100 52566
a=label:main-audio
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:cCHTn/CSiQ4c3sRvohvsWfR3q/doqOCdMN6cPJYE|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+eyg9HK/QVDBrjWPWDuHjS1r6txQfzQ0AgwnB/cM|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:44Pqmy/Q+B0LhfgcNBA/t41zEdGObzYj8nh1N5E5|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,36

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7
Content-Type: application/sdp
Content-ID: <4db9ee25-f671-43d6-858c-667ca097aaa9>

v=0
o=- 2740 0 IN IP4 192.168.100.100
s=session
c=IN IP4 192.168.100.100
b=CT:1000000
t=0 0
m=audio 52028 RTP/AVP 0 8 115 13 118 97 101
c=IN IP4 192.168.100.100
a=rtcp:52029
a=ice-ufrag:8PzC
a=ice-pwd:mBEyP2pDW9SRclLfYa3R5tHl
a=candidate:1 1 UDP 2130706431 192.168.100.100 52028 typ host
a=candidate:1 2 UDP 2130705918 192.168.100.100 52029 typ host
a=candidate:2 1 tcp-pass 174456319 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:2 2 tcp-pass 174455806 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:3 1 UDP 184548351 80.66.20.21 59334 typ relay raddr 192.168.100.100 rport 53944
a=candidate:3 2 UDP 184547838 80.66.20.21 55715 typ relay raddr 192.168.100.100 rport 53945
a=candidate:4 1 tcp-act 174848511 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:4 2 tcp-act 174847998 80.66.20.21 59086 typ relay raddr 192.168.100.100 rport 49366
a=candidate:5 1 tcp-act 1684797439 192.168.100.100 49366 typ srflx raddr 192.168.100.100 rport 49366
a=candidate:5 2 tcp-act 1684796926 192.168.100.100 49366 typ srflx raddr 192.168.100.100 rport 49366
a=label:main-audio
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:cCHTn/CSiQ4c3sRvohvsWfR3q/doqOCdMN6cPJYE|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:+eyg9HK/QVDBrjWPWDuHjS1r6txQfzQ0AgwnB/cM|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:44Pqmy/Q+B0LhfgcNBA/t41zEdGObzYj8nh1N5E5|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,36

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7
Content-Type: application/gw-sdp; x-bypassid=48ede576-751f-4a40-84cf-cbc6398c7376
Content-ID: <2e031a57-b08d-494e-8edf-1d1666359483>
Content-Disposition: Session;handling=optional

v=0
o=AudiocodesGW 1807657777 1807657772 IN IP4 192.168.100.107
s=session
c=IN IP4 192.168.100.107
t=0 0
m=audio 7540 RTP/AVP 8 0 18 13 101
c=IN IP4 192.168.100.107
a=rtcp:7541
a=x-bypassid:48ede576-751f-4a40-84cf-cbc6398c7376
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:IwLFB8wJ56x+TVHydAExg6YmGLJms4+/Z/lvApEQ|2^31|255:1
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=x-mediasettings:signalboostunsupported

--gQFzO171UYNTVxxFQgJ2MY7A5PULjDR7

Und dann der Antwort im "183 Session Progress". Hier sollten Sie sehen, dass er Audio akzeptiert, seine Candidates aber auch eine IPv6-Adresse enthalten und er auch Video könnte.

Content-Type: application/sdp
Content-Length: 2281

v=0
o=- 0 0 IN IP4 80.66.20.21
s=session
c=IN IP4 80.66.20.21
b=CT:99980
t=0 0
a=x-devicecaps:audio:send,recv;video:send,recv
m=audio 59121 RTP/SAVP 0 8 115 97 13 118 101
a=x-ssrc-range:3209117461-3209117461
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp-rsize
a=label:main-audio
a=x-source:main-audio
a=ice-ufrag:c5yr
a=ice-pwd:bCLavI84zmZX8C7+nruv5d52
a=candidate:1 1 UDP 2130706431 192.168.103.5 27034 typ host 
a=candidate:1 2 UDP 2130705918 192.168.103.5 27035 typ host 
a=candidate:2 1 UDP 2130705919 192.168.56.1 12258 typ host 
a=candidate:2 2 UDP 2130705406 192.168.56.1 12259 typ host 
a=candidate:3 1 UDP 2130705407 192.168.182.1 10486 typ host 
a=candidate:3 2 UDP 2130704894 192.168.182.1 10487 typ host 
a=candidate:4 1 UDP 2130704895 192.168.23.1 15656 typ host 
a=candidate:4 2 UDP 2130704382 192.168.23.1 15657 typ host 
a=candidate:5 1 UDP 2130704383 192.168.88.109 21086 typ host 
a=candidate:5 2 UDP 2130703870 192.168.88.109 21087 typ host 
a=x-candidate-ipv6:6 1 UDP 33551871 2001:0:9d38:6abd:8f0:6aee:afbd:ebe4 13626 typ host 
a=x-candidate-ipv6:6 2 UDP 33551358 2001:0:9d38:6abd:8f0:6aee:afbd:ebe4 13627 typ host 
a=candidate:7 1 TCP-PASS 174453759 80.66.20.21 54381 typ relay raddr 192.168.103.5 rport 1897 
a=candidate:7 2 TCP-PASS 174453246 80.66.20.21 54381 typ relay raddr 192.168.103.5 rport 1897 
a=candidate:8 1 UDP 184545791 80.66.20.21 59121 typ relay raddr 192.168.103.5 rport 11470 
a=candidate:8 2 UDP 184545278 80.66.20.21 58328 typ relay raddr 192.168.103.5 rport 11471 
a=candidate:9 1 TCP-ACT 174845951 80.66.20.21 54381 typ relay raddr 192.168.103.5 rport 1897 
a=candidate:9 2 TCP-ACT 174845438 80.66.20.21 54381 typ relay raddr 192.168.103.5 rport 1897 
a=candidate:10 1 TCP-ACT 1684794879 192.168.103.5 1897 typ srflx raddr 192.168.103.5 rport 1897 
a=candidate:10 2 TCP-ACT 1684794366 192.168.103.5 1897 typ srflx raddr 192.168.103.5 rport 1897 
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:7yqJgereYhuL12HzIXQGtlmRn+sm9EtDldcvh35s|2^31|1:1
a=maxptime:200
a=rtcp:58328
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Start eines Screensharing

Hier versuche ich meinen Bildschirm freizugeben. Sie erkennen das an der "m=applicationsharing"-Zeile. Zudem sehen Sie, dass RDP nicht über UDP gesendet wird und daher bei den "Candidates" nur TCP-Optionen angeboten werden.

v=0
o=- 0 0 IN IP4 80.66.20.21
s=session
c=IN IP4 80.66.20.21
b=CT:99980
t=0 0
m=applicationsharing 53517 TCP/RTP/AVP 127
a=ice-ufrag:ZF7y
a=ice-pwd:xUUodB/SAY8+GNVgENklmwaE
a=candidate:1 1 TCP-PASS 2120613887 192.168.178.64 11120 typ host 
a=candidate:1 2 TCP-PASS 2120613374 192.168.178.64 11120 typ host 
a=candidate:2 1 TCP-ACT 2121006591 192.168.178.64 11317 typ host 
a=candidate:2 2 TCP-ACT 2121006078 192.168.178.64 11317 typ host 
a=candidate:3 1 TCP-PASS 2120612863 192.168.56.1 16777 typ host 
a=candidate:3 2 TCP-PASS 2120612350 192.168.56.1 16777 typ host 
a=candidate:4 1 TCP-ACT 2121005567 192.168.56.1 23121 typ host 
a=candidate:4 2 TCP-ACT 2121005054 192.168.56.1 23121 typ host 
a=candidate:5 1 TCP-PASS 2120611839 192.168.182.1 26272 typ host 
a=candidate:5 2 TCP-PASS 2120611326 192.168.182.1 26272 typ host 
a=candidate:6 1 TCP-ACT 2121004543 192.168.182.1 23282 typ host 
a=candidate:6 2 TCP-ACT 2121004030 192.168.182.1 23282 typ host 
a=candidate:7 1 TCP-PASS 2120610815 192.168.23.1 6830 typ host 
a=candidate:7 2 TCP-PASS 2120610302 192.168.23.1 6830 typ host 
a=candidate:8 1 TCP-ACT 2121003519 192.168.23.1 3091 typ host 
a=candidate:8 2 TCP-ACT 2121003006 192.168.23.1 3091 typ host 
a=candidate:9 1 TCP-PASS 2120609791 192.168.178.73 20998 typ host 
a=candidate:9 2 TCP-PASS 2120609278 192.168.178.73 20998 typ host 
a=candidate:10 1 TCP-ACT 2121002495 192.168.178.73 28152 typ host 
a=candidate:10 2 TCP-ACT 2121001982 192.168.178.73 28152 typ host 
a=x-candidate-ipv6:11 1 TCP-PASS 23456767 2001:0:5ef5:79fd:3c75:2b9b:b03b:6f1f 23598 typ host 
a=x-candidate-ipv6:11 2 TCP-PASS 23456254 2001:0:5ef5:79fd:3c75:2b9b:b03b:6f1f 23598 typ host 
a=x-candidate-ipv6:12 1 TCP-ACT 23849471 2001:0:5ef5:79fd:3c75:2b9b:b03b:6f1f 26905 typ host 
a=x-candidate-ipv6:12 2 TCP-ACT 23848958 2001:0:5ef5:79fd:3c75:2b9b:b03b:6f1f 26905 typ host 
a=candidate:13 1 TCP-PASS 174450687 80.66.20.21 53517 typ relay raddr 79.196.144.224 rport 19154 
a=candidate:13 2 TCP-PASS 174450174 80.66.20.21 53517 typ relay raddr 79.196.144.224 rport 19154 
a=candidate:14 1 TCP-ACT 174843391 80.66.20.21 53517 typ relay raddr 79.196.144.224 rport 19154 
a=candidate:14 2 TCP-ACT 174842878 80.66.20.21 53517 typ relay raddr 79.196.144.224 rport 19154 
a=candidate:15 1 TCP-ACT 1684792319 79.196.144.224 19154 typ srflx raddr 192.168.178.64 rport 19154 
a=candidate:15 2 TCP-ACT 1684791806 79.196.144.224 19154 typ srflx raddr 192.168.178.64 rport 19154 
a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:CdOXqfaCq5k+XWHYUl306NxT2NAGqZNlnPlf5YKN|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:o6bJENGtuA9oltfSqhSzbg7Yj2RwUoBTNaYGdBIM|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:wZ7AWYb+5PY3wrbOk+8B3zdpGXNX1lYCqc5b1FXD|2^31
a=setup:active
a=connection:new
a=rtcp:53517
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:r

Audiocall von einem Audiocodes Gateway

Der Invite eines reinen "Audio-Gateways" kann deutlich kürzer ausfallen. Da so ein Gateway in der Regel keinen Edge/STUN/TURN-Server nutzen wird, sondern mit dem Mediation Server spricht, spart es sich hier gleich ganz die "Candidates". Die Gegeneiste nutzt einfach die IP-Adresse aus dem d Feld "c=" und den Port aus "m=". Auch die Liste der Codecs ist kürzer.

v=0
o=AudiocodesGW 50047400 50047107 IN IP4 192.168.100.107
s=session
c=IN IP4 192.168.100.107
t=0 0
m=audio 6710 RTP/AVP 8 0 18 13 101
c=IN IP4 192.168.100.107
a=rtcp:6711
a=x-bypassid:9adbd0b2-866b-4d8c-9b97-e44f05ee61bb
a=sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=x-mediasettings:signalboostunsupported

Weitere Links

SIP Signaling, Negotiation and Media Flows in Skype für Business, Explained
https://channel9.msdn.com/events/Ignite/2015/BRK4102
Sehr schöner Vortrag zu SIP und SDP