Connected Identity in the Session Initiation Protocol (SIP)
RFC 4916
Document | Type |
RFC - Proposed Standard
(June 2007; No errata)
Updates RFC 3261
|
|
---|---|---|---|
Author | John Elwell | ||
Last updated | 2015-10-14 | ||
Replaces | draft-elwell-sip-connected-identity | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4916 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | (None) |
Network Working Group J. Elwell Request for Comments: 4916 Siemens Enterprise Communications Limited Updates: 3261 June 2007 Category: Standards Track Connected Identity in the Session Initiation Protocol (SIP) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). Elwell Standards Track [Page 1] RFC 4916 SIP Connected ID June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Solution . . . . . . . . . . . . . . . . . . . . . 4 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Behaviour of a UA that Issues an INVITE Request Outside the Context of an Existing Dialog . . . . . . . . 6 4.2. Behaviour of a UA that Receives an INVITE Request outside the Context of an Existing Dialog . . . . . . . . 6 4.3. Behaviour of a UA Whose Identity Changes during an Established INVITE-initiated Dialog . . . . . . . . . . . 7 4.4. General UA Behaviour . . . . . . . . . . . . . . . . . . . 7 4.4.1. Sending a Mid-Dialog Request . . . . . . . . . . . . . 7 4.4.2. Receiving a Mid-Dialog Request . . . . . . . . . . . . 8 4.5. Authentication Service Behaviour . . . . . . . . . . . . . 8 4.6. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . 9 4.7. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Sending Connected Identity after Answering a Call . . . . 10 5.2. Sending Revised Connected Identity during a Call . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security considerations . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 Elwell Standards Track [Page 2] RFC 4916 SIP Connected ID June 2007 1. Introduction The Session Initiation Protocol (SIP) (RFC 3261 [1]) initiates sessions but also provides information on the identities of the parties at both ends of a session. Users need this information to help determine how to deal with communications initiated by a SIP. The identity of the party who answers a call can differ from that of the initial called party for various reasons such as call forwarding, call distribution and call pick-up. Furthermore, once a call has been answered, a party can be replaced by a different party with a different identity for reasons such as call transfer, call park and retrieval, etc. Although in some cases there can be reasons for not disclosing these identities, it is desirable to have a mechanism for providing this information. This document extends the use of the From header field to allow it to convey what is commonly called "connected identity" information (the identity of the connected user) in either direction within the context of an existing INVITE-initiated dialog. It can be used to convey: o the callee identity to a caller when a call is answered; o the identity of a potential callee prior to answer; or o the identity of a user that replaces the caller or callee following a call rearrangement such as call transfer carried outShow full document text