Connected Identity in the Session Initiation Protocol (SIP)
RFC 4916

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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 out