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

Das vorherige Beispiel nutzte RFC 4916 für Connected Identity nicht. Das folgende schon:

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

Die ersten neun Nachrichten entsprechen dem vorherigen Beispiel. Neu sind die Nachrichten 10–13 mit RFC-4916-UPDATE.

Nachricht (10): UPDATE Bob → Proxy

Bob sendet ein RFC-4916-UPDATE zu Alice mit seinem Fingerprint und denselben Sitzungsdaten wie in 200 OK (Nachricht 8). Ein UPDATE könnte Parameter ändern; hier dient es nur zur Fingerprint-Bestätigung.

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

Nachricht (11): UPDATE Proxy → Alice

UPDATE wird zu Alice weitergeleitet; Bobs Proxy fügt Identity und Identity-Info ein (vereinfacht). Alice prüft die Identität. (Beispielsignaturen sind nicht korrekt.)

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

Nachricht (12): 200 OK Alice → Bob

Alices 200 OK auf Bobs UPDATE. Da Bob dieselben Sitzungsparameter wie in 200 OK gesendet hat, kann Alice ihre Sicht einfach wiedergeben.

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