7.1. Basic Message Flow with Early Media and SIP Identity (Nachrichtenfluss)

Vor Sitzungsaufbau erzeugen Alice und Bob selbstsignierte Zertifikate für eine Sitzung oder – wahrscheinlicher – zur Wiederverwendung über mehrere Sitzungen. In diesem Beispiel ruft Alice Bob an; beide teilen sich denselben Proxy.

Das Beispiel zeigt SIP-Nachrichtenflüsse, bei denen Alice passiv und Bob aktiv ist: Sobald Bob die INVITE von Alice mit DTLS in der „m=“-Zeile des Angebots erhält, beginnt er, eine DTLS-Assoziation mit Alice für RTP- und RTCP-Ströme auszuhandeln. Early Media (RTP und RTCP) fließt von Bob zu Alice, sobald Bob die DTLS-Finished-Nachricht sendet. Bidirektionales Media kann fließen, nachdem Alice die SIP-200-Antwort erhalten hat und ihre DTLS-Finished-Nachricht gesendet hat.

Die SIP-Signalisierung von Alice zu ihrem Proxy läuft über TLS für einen integritätsgeschützten Kanal zwischen Alice und ihrem Identity-Dienst. Transport zwischen Proxys sollte ebenfalls geschützt werden, insbesondere ohne SIP Identity.

Alice Proxies Bob |(1) INVITE | | |---------------->| | | |(2) INVITE | | |----------------->| | |(3) hello | |<-----------------------------------| |(4) hello | | |----------------------------------->| | |(5) finished | |<-----------------------------------| | |(6) media | |<-----------------------------------| |(7) finished | | |----------------------------------->| | |(8) 200 OK | | <------------------| |(9) 200 OK | | |<----------------| | | |(10) media | |<---------------------------------->| |(11) ACK | | |----------------------------------->|

Nachricht (1): INVITE Alice → Proxy

Erste INVITE von Alice zu Bob über TLS für Integrität zwischen Alice und ihrem als Identity-Dienst fungierenden Proxy. Alice hat mit a=setup:actpass im SDP aktiv oder passiv angefragt. Bob agiert als DTLS-Client und initiiert die Sitzung. Im SDP steht ein Fingerprint aus Alices selbstsigniertem Zertifikat.

Das Angebot enthält eine Standard-„m=“-Zeile mit RTP, falls der Antwortende kein SRTP unterstützt; bevorzugt ist die Konfiguration mit SRTP-Transport. Details siehe [MMUSIC-SDP].

INVITE sip:[email protected] SIP/2.0 To: sip:[email protected] From: "Alice"sip:[email protected];tag=843c7b0b Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Contact: sip:[email protected] Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Max-Forwards: 70 Content-Type: application/sdp Content-Length: xxxx Supported: from-change

v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=setup:actpass a=fingerprint: SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1

Nachricht (2): INVITE Proxy → Bob

INVITE wird an Bob weitergeleitet. Alices Proxy hat Identity- und Identity-Info-Köpfe eingefügt (vereinfacht ein Proxy-Element). Bob prüft die mitgelieferte Identität.

INVITE sip:[email protected] SIP/2.0 To: sip:[email protected] From: "Alice"sip:[email protected];tag=843c7b0b Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldk Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Record-Route: sip:proxy.example.com;lr Contact: sip:[email protected] Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Max-Forwards: 69 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= Identity-Info: https://example.com/cert Content-Type: application/sdp Content-Length: xxxx Supported: from-change

Nachricht (3): ClientHello Bob → Alice

Bei gültiger Alice-Identität sendet Bob DTLS-ClientHello(s) direkt an Alice (zwei: RTP-Port 6056 und RTCP 6057; eine Pfeilspitze zur Kürze).

Nachricht (4): ServerHello+Certificate Alice → Bob

Alice antwortet mit ServerHello, Certificate und ServerHelloDone für RTP und RTCP; dasselbe Zertifikat. Bei RTP/RTCP-Multiplexing [RFC5761] nur eine Assoziation.

Nachricht (5): Certificate Bob → Alice

Bob sendet Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec und Finished für beide Assoziationen; gleiches Serverzertifikat.

Nachricht (6): Early Media Bob → Alice

Bob kann Early Media senden. Alice vertraut dem Media noch nicht (Fingerprint fehlt); die UA-Oberfläche zeigt das an.

Nachricht (7): Finished Alice → Bob

Nach Empfang von Nachricht 7 sendet Alice change_cipher_spec und Finished.

Nachricht (8): 200 OK Bob → Alice

Bei Annahme sendet Bob 200 OK mit Fingerprint; tatsächliche SRTP-über-DTLS-Konfiguration im acfg-Parameter.

SIP/2.0 200 OK To: sip:[email protected];tag=6418913922105372816 From: "Alice" sip:[email protected];tag=843c7b0b Via: SIP/2.0/TLS proxy.example.com:5061;branch=z9hG4bK-0e53sadfkasldk Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bK-0e53sadfkasldkfj Record-Route: sip:proxy.example.com;lr Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 1 INVITE Contact: sip:[email protected] Content-Type: application/sdp Content-Length: xxxx Supported: from-change

v=0 o=- 6418913922105372816 2105372818 IN IP4 ua2.example.com s=example2 c=IN IP4 ua2.example.com a=setup:active a=fingerprint: SHA-1
FF:FF:FF:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB t=0 0 m=audio 12000 UDP/TLS/RTP/SAVP 0 a=acfg:1 t=1

Nachricht (9): 200 OK Proxy → Alice

Alice validiert das in Nachricht 7 präsentierte Zertifikat; die Oberfläche zeigt gesicherten Anruf.

Nachricht (10): RTP+RTCP Alice → Bob

Alice kann RTP und RTCP zu Bob senden.

Nachricht (11): ACK Alice → Bob

Alice sendet SIP ACK.