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

Prima di stabilire la sessione, Alice e Bob generano certificati autofirmati per una singola sessione o, più probabilmente, riutilizzati su più sessioni. In questo esempio Alice chiama Bob; si assume lo stesso proxy.

L'esempio mostra i flussi SIP in cui Alice è l'endpoint passivo e Bob quello attivo: appena Bob riceve l'INVITE da Alice con DTLS nella riga « m= » dell'offerta, inizia a negoziare un'associazione DTLS con Alice per i flussi RTP e RTCP. L'early media (RTP e RTCP) fluisce da Bob ad Alice non appena Bob invia il messaggio DTLS Finished. Il media bidirezionale può fluire dopo che Alice ha ricevuto la risposta SIP 200 e ha inviato il proprio DTLS Finished.

La segnalazione SIP da Alice al proxy è su TLS per un canale a integrità tra Alice e il servizio di identità. Anche il trasporto tra proxy dovrebbe essere protetto, soprattutto senza 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 | | |----------------------------------->|

Messaggio (1): INVITE Alice → Proxy

INVITE iniziale da Alice a Bob su TLS per integrità tra Alice e il proxy che funge da servizio di identità. Alice ha richiesto ruolo attivo o passivo con a=setup:actpass nel SDP. Bob agisce come client DTLS e avvierà la sessione. C'è l'attributo fingerprint nell'SDP, calcolato dal certificato autofirmato di Alice.

L'offerta include una riga « m= » predefinita con RTP se il rispondente non supporta SRTP; la configurazione con trasporto SRTP è preferita. Dettagli in [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

Messaggio (2): INVITE Proxy → Bob

INVITE inoltrato a Bob; il proxy di Alice ha inserito Identity e Identity-Info (un solo elemento proxy per semplicità). Bob verifica l'identità.

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

Messaggio (3): ClientHello Bob → Alice

Con identità Alice valida, Bob invia DTLS ClientHello direttamente ad Alice (due messaggi: RTP porta 6056 e RTCP 6057; una freccia per compattezza).

Messaggio (4): ServerHello+Certificate Alice → Bob

Alice risponde con ServerHello, Certificate e ServerHelloDone per RTP e RTCP; stesso certificato. Con multiplex RTP/RTCP [RFC5761] basterebbe un'associazione.

Messaggio (5): Certificate Bob → Alice

Bob invia Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec e Finished per entrambe le associazioni; stesso certificato server.

Messaggio (6): Early media Bob → Alice

Bob può inviare early media. Alice non può ancora fidarsi del media (manca l'impronta); l'UA lo segnala in UI.

Messaggio (7): Finished Alice → Bob

Dopo il messaggio 7, Alice invia change_cipher_spec e Finished.

Messaggio (8): 200 OK Bob → Alice

Alla risposta, Bob invia 200 OK con fingerprint; configurazione SRTP su DTLS nel parametro acfg.

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

Messaggio (9): 200 OK Proxy → Alice

Alice valida il certificato del messaggio 7; l'endpoint segnala chiamata protetta.

Messaggio (10): RTP+RTCP Alice → Bob

Alice può inviare RTP e RTCP a Bob.

Messaggio (11): ACK Alice → Bob

Alice invia ACK SIP.