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

The previous example did not show the use of RFC 4916 for connected identity. The following example does:

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

The first 9 messages of this example are the same as before. However, Messages 10-13, performing the RFC 4916 UPDATE, are new.

Message (10): UPDATE Bob -> Proxy

Bob sends an RFC 4916 UPDATE towards Alice. This update contains his fingerprint. Bob's UPDATE contains the same session information that he provided in his 200 OK (Message 8). Note that in principle an UPDATE here can be used to modify session parameters. However, in this case it's being used solely to confirm the fingerprint.

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

Message (11): UPDATE Proxy -> Alice

This shows the UPDATE being relayed to Alice from Bob (and Alice's proxy). Note that Bob's proxy has inserted an Identity and Identity-Info header. As above, we only show one element for both proxies for purposes of simplification. Alice verifies the identity provided. (Note: the actual identity signatures here are incorrect and provided merely as examples.)

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

Message (12): 200 OK Alice -> Bob

This shows Alice's 200 OK response to Bob's UPDATE. Because Bob has merely sent the same session parameters he sent in his 200 OK, Alice can simply replay her view of the session parameters as well.

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