7.2. Flux de messages avec identité connectée (RFC 4916)

L'exemple précédent n'utilisait pas la RFC 4916 pour l'identité connectée. L'exemple suivant l'illustre:

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

Les neuf premiers messages sont identiques à l'exemple précédent. Les messages 10 à 13, avec l'UPDATE RFC 4916, sont nouveaux.

Message (10): UPDATE Bob → Proxy

Bob envoie un UPDATE RFC 4916 vers Alice. Il contient son empreinte et les mêmes informations de session que dans son 200 OK (message 8). En principe un UPDATE peut modifier les paramètres de session; ici il sert uniquement à confirmer l'empreinte.

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

UPDATE relayé vers Alice; le proxy de Bob a inséré Identity et Identity-Info (un proxy pour simplifier). Alice vérifie l'identité. (Les signatures d'exemple ne sont pas correctes.)

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

Réponse 200 OK d'Alice à l'UPDATE de Bob. Comme Bob a renvoyé les mêmes paramètres de session que dans son 200 OK, Alice peut simplement rejouer sa vue des paramètres de session.

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