7.1. Flux de messages de base avec early media et SIP Identity

Avant d'établir la session, Alice et Bob génèrent tous deux des certificats auto-signés utilisés pour une seule session ou, plus probablement, réutilisés pour plusieurs sessions. Dans cet exemple, Alice appelle Bob. Nous supposons qu'Alice et Bob partagent le même proxy.

Cet exemple montre les flux de messages SIP où Alice joue le rôle d'extrémité passive et Bob celui d'extrémité active; dès réception de l'INVITE d'Alice avec DTLS indiqué dans la ligne « m= » de l'offre, Bob commence à négocier une association DTLS avec Alice pour les flux RTP et RTCP. L'early media (RTP et RTCP) commence à circuler de Bob vers Alice dès que Bob envoie le message DTLS Finished à Alice. Un média bidirectionnel (RTP et RTCP) peut circuler après qu'Alice a reçu la réponse SIP 200 et une fois qu'Alice a envoyé le message DTLS Finished.

La signalisation SIP d'Alice vers son proxy est transportée sur TLS pour garantir un canal protégé en intégrité entre Alice et son service d'identité. Le transport entre proxys devrait aussi être protégé, surtout si SIP Identity n'est pas utilisé.

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 | | |----------------------------------->|

Message (1): INVITE Alice → Proxy

Il s'agit de l'INVITE initial d'Alice vers Bob, transporté sur TLS pour un canal protégé en intégrité entre Alice et son proxy agissant comme service d'identité d'Alice. Alice a demandé à être l'extrémité active ou passive en indiquant a=setup:actpass dans le SDP. Bob choisit d'agir comme client DTLS et initiera la session. Notez aussi l'attribut fingerprint dans le SDP, calculé à partir du certificat auto-signé d'Alice.

Cette offre inclut une ligne « m= » par défaut proposant RTP au cas où le répondant ne prend pas en charge SRTP. Toutefois, la configuration potentielle avec transport SRTP est préférée. Voir [MMUSIC-SDP] pour la négociation des capacités 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

Message (2): INVITE Proxy → Bob

L'INVITE est relayé vers Bob depuis Alice (et le proxy de Bob). Le proxy d'Alice a inséré des en-têtes Identity et Identity-Info. Pour simplifier, un seul élément proxy est montré. Bob vérifie l'identité fournie avec l'INVITE.

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

Message (3): ClientHello Bob → Alice

Si l'identité d'Alice est valide, la ligne 3 montre Bob envoyant un ou des DTLS ClientHello directement à Alice. Ici, deux messages ClientHello seraient envoyés: un vers ua1.example.com:6056 pour RTP et un autre vers le port 6057 pour RTCP; une seule flèche figure pour compacité.

Message (4): ServerHello+Certificate Alice → Bob

Alice renvoie ServerHello, Certificate et ServerHelloDone pour les associations RTP et RTCP. Le même certificat est utilisé pour les deux. Avec multiplexage RTP/RTCP [RFC5761], une seule association suffirait.

Message (5): Certificate Bob → Alice

Bob envoie Certificate, ClientKeyExchange, CertificateVerify, change_cipher_spec et Finished pour RTP et RTCP. Bob utilise le même certificat serveur pour les deux associations.

Message (6): Early media Bob → Alice

Bob peut commencer l'early media (RTP et RTCP) vers Alice. Alice ne peut pas encore faire confiance au média car l'empreinte n'a pas été reçue. Ce manque de média sûr de confiance est indiqué à Alice via l'interface utilisateur de l'UA.

Message (7): Finished Alice → Bob

Après réception du message 7 par Bob, Alice envoie change_cipher_spec et Finished.

Message (8): 200 OK Bob → Alice

Quand Bob décroche, il envoie 200 OK avec l'empreinte de son certificat. Bob signale la configuration réelle SRTP sur DTLS via le paramètre 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

Message (9): 200 OK Proxy → Alice

Alice reçoit le message via son proxy et valide le certificat présenté au message 7. L'endpoint indique alors à Alice que l'appel est sécurisé.

Message (10): RTP+RTCP Alice → Bob

Alice peut commencer à envoyer RTP et RTCP à Bob.

Message (11): ACK Alice → Bob

Alice envoie enfin le SIP ACK à Bob.