7.2. Basic Message Flow with Connected Identity (RFC 4916)

L'esempio precedente non mostrava l'uso della RFC 4916 per l'identità connessa. Il seguente sì:

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

I primi nove messaggi coincidono con l'esempio precedente. Nuovi sono i messaggi 10–13 con UPDATE RFC 4916.

Messaggio (10): UPDATE Bob → Proxy

Bob invia un UPDATE RFC 4916 verso Alice con la propria impronta e le stesse informazioni di sessione del 200 OK (messaggio 8). In linea di principio l'UPDATE può modificare i parametri; qui serve solo a confermare l'impronta.

UPDATE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj To: "Alice" sip:[email protected];tag=843c7b0b From sip:[email protected];tag=6418913922105372816 Route: sip:proxy.example.com;lr Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 2 UPDATE Contact: sip:ua2.example.com Content-Type: application/sdp Content-Length: xxxx Supported: from-change Max-Forwards: 70

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 (11): UPDATE Proxy → Alice

UPDATE inoltrato ad Alice; il proxy di Bob inserisce Identity e Identity-Info (semplificazione a un proxy). Alice verifica l'identità. (Le firme di esempio non sono corrette.)

UPDATE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK-0e53sadfkasldkfj Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bK-0e53sadfkasldkfj To: "Alice" sip:[email protected];tag=843c7b0b From sip:[email protected];tag=6418913922105372816 Call-ID: 6076913b1c39c212@REVMTEpG CSeq: 2 UPDATE Contact: sip:[email protected] Content-Type: application/sdp Content-Length: xxxx Supported: from-change Max-Forwards: 69 Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k 3W+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4XrKFC HYWGCl0nB2sNsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI= Identity-Info: https://example.com/cert

Messaggio (12): 200 OK Alice → Bob

Risposta 200 OK di Alice all'UPDATE di Bob. Poiché Bob ha inviato gli stessi parametri di sessione del 200 OK, Alice può ripresentare la propria vista dei parametri.

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

v=0 o=- 1181923068 1181923196 IN IP4 ua2.example.com s=example1 c=IN IP4 ua2.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