doc: Add RFC documents

1 files changed, 1347 insertions, 0 deletions

diff --git a/doc/rfc/rfc4916.txt b/doc/rfc/rfc4916.txt
new file mode 100644
index 0000000..a0ab5b6
--- /dev/null
+++ b/doc/rfc/rfc4916.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+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
+      within the PSTN or within a back-to-back user agent (B2BUA) using
+      third party call control techniques.
+
+      Note that the use of standard SIP call transfer techniques,
+      involving the REFER method, leads to the establishment of a new
+      dialog and hence normal mechanisms for caller and callee identity
+      apply.
+
+   The provision of the identity of the responder in a response
+   (commonly called "response identity") is outside the scope of this
+   document.
+
+      Note that even if identity were to be conveyed somehow in a
+      response, there would in general be difficulty authenticating the
+      UAS.  Providing identity in a separate request allows normal
+      authentication techniques to be used.
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                     [Page 3]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [2].
+
+   This specification defines the following additional terms:
+
+   caller: the user of the UA that issues an INVITE request to initiate
+        a call.
+
+   caller identity: the identity (Address of Record) of a caller.
+
+   callee: the user of the UA that answers a call by issuing a 2xx
+        response to an INVITE request.
+
+   callee identity: the identity (Address of Record) of a callee.
+
+   potential callee: the user of any UA to which an INVITE request is
+        targeted resulting in formation of an early dialog, but because
+        of parallel or serial forking of the request, not necessarily
+        the user that answers the call.
+
+   connected user: any user involved in an established call, including
+        the caller, the callee or any user that replaces the caller or
+        callee following a call re-arrangement such as call transfer.
+
+   connected identity: the identity (Address of Record) of a connected
+        user.
+
+3.  Overview of Solution
+
+   A mid-dialog request is used to provide connected identity.  The User
+   Agent Client (UAC) for that request inserts its identity in the From
+   header field of the request.  To provide authentication, the Identity
+   header field (RFC 4474 [3]) is inserted by a suitable Authentication
+   Service on the path of the mid-dialog request.  Unless provided at
+   the UAC, the Authentication Service is expected to be at a proxy that
+   record routes and is able to authenticate the UAC.
+
+   A request in the opposite direction to the INVITE request prior to or
+   at the time the call is answered can indicate the identity of the
+   potential callee or callee respectively.  A request in the same
+   direction as the INVITE request prior to answer can indicate a change
+   of caller.  A request in either direction after answering can
+   indicate a change of the connected user.  In all cases, a dialog
+   (early or confirmed) has to be established before such a request can
+   be sent.
+
+
+
+Elwell                      Standards Track                     [Page 4]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+   This solution uses the UPDATE method (RFC 3311 [4]) for the request,
+   or in some circumstances the re-INVITE method.  To send the callee
+   identity, the UAS for the INVITE request sends the UPDATE request
+   after sending the 2xx response to the INVITE request and after
+   receiving an ACK request.  To send the potential callee identity, RFC
+   3262 [5] is expected to be supported.  In this case, the UAS for the
+   INVITE request sends the UPDATE request after receiving and
+   responding to a PRACK request (which occurs after sending a reliable
+   1xx response to the INVITE request).  The UPDATE request could
+   conceivably be used for other purposes too, e.g., it could be used
+   during an early dialog to send the potential callee identity at the
+   same time as a Session Description Protocol (SDP) offer for early
+   media.  To indicate a connected identity change during an established
+   call, either the UPDATE method or the re-INVITE method can be used.
+   The re-INVITE method would be used if required for other purposes
+   (e.g., when a B2BUA performs transfer using Third Party Call Control
+   (3PCC) techniques it has to issue a re-INVITE request without an SDP
+   offer to solicit an SDP offer from the UA).
+
+   This solution involves changing the URI (not the tags) in the To and
+   From header fields of mid-dialog requests and their responses,
+   compared with the corresponding values in the dialog forming request
+   and response.  Changing the To and From header field URIs was
+   contemplated in Section 12.2.1.1 of RFC 3261 [1], which says:
+
+      "Usage of the URI from the To and From fields in the original
+      request within subsequent requests is done for backwards
+      compatibility with RFC 2543 [6], which used the URI for dialog
+      identification.  In this specification, only the tags are used for
+      dialog identification.  It is expected that mandatory reflection
+      of the original To and From URI in mid-dialog requests will be
+      deprecated in a subsequent revision of this specification."
+
+   This document therefore deprecates mandatory reflection of the
+   original To and From URIs in mid-dialog requests and their responses,
+   which constitutes a change to RFC 3261 [1].  This document makes no
+   provision for proxies that are unable to tolerate a change of URI,
+   since changing the URI has been expected for a considerable time.  To
+   cater for any UAs that are not able to tolerate a change of URI, a
+   new option tag "from-change" is introduced for providing a positive
+   indication of support in the Supported header field.  By sending a
+   request with a changed From header field URI only to targets that
+   have indicated support for this option, there is no need to send this
+   option tag in a Require header field.
+
+   In addition to allowing the From header field URI to change during a
+   dialog to reflect the connected identity, this document also requires
+   a UA that has received a connected identity in the URI of the From
+
+
+
+Elwell                      Standards Track                     [Page 5]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+   header field of a mid-dialog request to use that URI in the To header
+   field of any subsequent mid-dialog request sent by that UA.
+
+   In the absence of a suitable Authentication Service on the path of
+   the mid-dialog request, the UAS will receive an unauthenticated
+   connected identity (i.e., without a corresponding Identity header
+   field).  The implications of this are discussed in Section 7
+
+4.  Behaviour
+
+4.1.  Behaviour of a UA that Issues an INVITE Request Outside the
+      Context of an Existing Dialog
+
+   When issuing an INVITE request, a UA compliant with this
+   specification MUST include the "from-change" option tag in the
+   Supported header field.
+
+      Note that sending the "from-change" option tag does not guarantee
+      that connected identity will be received in subsequent requests.
+
+4.2.  Behaviour of a UA that Receives an INVITE Request outside the
+      Context of an Existing Dialog
+
+   After receiving an INVITE request, a UA compliant with this
+   specification MUST include the "from-change" option tag in the
+   Supported header field of any dialog-forming response.
+
+      Note that sending the "from-change" option tag does not guarantee
+      that connected identity will be received in the event of a change
+      of caller.
+
+   After an early dialog has been formed, if the "from-change" option
+   tag has been received in a Supported header field, the UA MAY issue
+   an UPDATE request (RFC 3311 [4]) on the same dialog, subject to
+   having sent a reliable provisional response to the INVITE request and
+   having received and responded to a PRACK request.  After a full
+   dialog has been formed (after sending a 2xx final response to the
+   INVITE request), if the "from-change" option tag has been received in
+   a Supported header field and an UPDATE request has not already been
+   sent on the early dialog, the UA MUST issue an UPDATE request on the
+   same dialog.  In either case, the UPDATE request MUST contain the
+   callee's (or potential callee's) identity in the URI of the From
+   header field (or an anonymous identity if anonymity is required).
+
+      Note that even if the URI does not differ from that in the To
+      header field URI of the INVITE request, sending a new request
+      allows the Authentication Service to assert authentication of this
+      identity and confirms to the peer UA that the connected identity
+
+
+
+Elwell                      Standards Track                     [Page 6]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+      is the same as that in the To header field URI of the INVITE
+      request.
+
+4.3.  Behaviour of a UA Whose Identity Changes during an Established
+      INVITE-initiated Dialog
+
+   If the "from-change" option tag has been received in a Supported
+   header field during an INVITE-initiated dialog and if the identity
+   associated with the UA changes (e.g., due to transfer) compared to
+   the last identity indicated in the From header field of a request
+   sent by that UA, the UA MUST issue a request on the same dialog
+   containing the new identity in the URI of the From header field (or
+   an anonymous identity if anonymity is required).  For this purpose
+   the UA MUST use the UPDATE method unless for other reasons the re-
+   INVITE method is being used at the same time.
+
+4.4.  General UA Behaviour
+
+4.4.1.  Sending a Mid-Dialog Request
+
+   When sending a mid-dialog request, a UA MUST observe the requirements
+   of RFC 4474 [3] when populating the From header field URI, including
+   provisions for achieving anonymity.
+
+      This will allow an Authentication Service on the path of the mid-
+      dialog request to insert an Identity header field.
+
+   When sending a mid-dialog request, a UA MUST populate the To header
+   field URI with the current value of the remote URI for that dialog,
+   where this is subject to update in accordance with the rules of
+   Section 4.4.2 of this document rather than being fixed at the
+   beginning of the dialog in accordance with RFC 3261 [1].
+
+   After sending a request with a revised From header field URI (i.e.,
+   revised compared to the URI sent in the From header field of the
+   previous request on this dialog or in the To header field of the
+   received dialog-forming INVITE request if no request has been sent),
+   the UA MUST send the same URI in the From header field of any future
+   requests on the same dialog, unless the identity changes again.
+   Also, the UA MUST be prepared to receive the revised URI in the To
+   header field of subsequent mid-dialog requests and MUST also continue
+   to be prepared to receive the old URI at least until a request
+   containing the revised URI in the To header field has been received.
+
+   The mid-dialog request can be rejected in accordance with RFC 4474
+   [3] if the UAS does not accept the connected identity.  If the UAC
+   receives a 428, 436, 437, or 438 response to a mid-dialog request it
+   SHOULD regard the dialog as terminated in the case of a dialog-
+
+
+
+Elwell                      Standards Track                     [Page 7]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+   terminating request and SHOULD take no action in the case of any
+   other request.
+
+      Any attempt to repeat the request or send any other mid-dialog
+      request is likely to result in the same response, since the UA has
+      no control over actions of the Authentication Service.
+
+4.4.2.  Receiving a Mid-Dialog Request
+
+   If a UA receives a mid-dialog request from the peer UA, the UA can
+   make use of the identity in the From header field URI (e.g., by
+   indicating to the user).  The UA MAY discriminate between signed and
+   unsigned identities.  In the case of a signed identity, the UA SHOULD
+   invoke a Verifier (see Section 4.6) if it cannot rely on the presence
+   of a Verifier on the path of the request.
+
+   If a UA receives a mid-dialog request from the peer UA in which the
+   From header field URI differs from that received in the previous
+   request on that dialog or that sent in the To header field of the
+   original INVITE request and if the UA sends a 2xx response, the UA
+   MUST update the remote URI for this dialog, as defined in RFC 3261
+   [1].  This will cause the new value to be used in the To header field
+   of subsequent requests that the UA sends, in accordance with the
+   rules of Section 4.4.1.  If any other final response is sent the UA
+   MUST NOT update the remote URI for this dialog.
+
+4.5.  Authentication Service Behaviour
+
+   An Authentication Service MUST behave in accordance with RFC 4474 [3]
+   when dealing with mid-dialog requests.
+
+      Note that RFC 4474 is silent on how to behave if the identity in
+      the From header field is not one that the UAC is allowed to
+      assert, and therefore it is a matter for local policy whether to
+      reject the request or forward it without an Identity header field.
+      Policy can be different for a mid-dialog request compared with
+      other requests.
+
+      Note that when UAs conform with this specification the
+      Authentication Service should (subject to the normal rules for
+      authentication) be able to authenticate the sender of a request as
+      being the entity identified in the From header field and hence
+      will be able provide a signature for this identity.  This is in
+      contrast to UAs that do not support this specification, where
+      retargeting and mid-dialog identity changes can render the From
+      header field inaccurate as a means of identifying the sender of
+      the request.
+
+
+
+
+Elwell                      Standards Track                     [Page 8]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+4.6.  Verifier Behaviour
+
+   When dealing with mid-dialog requests, an Authentication Service MUST
+   behave in accordance with RFC 4474 [3] updated as stated below.
+
+   RFC 4474 [3] states that it is a matter of policy whether to reject a
+   request with a 428 (Use Identity Header) response if there is no
+   Identity header field in the request.  A UA MAY adopt a different
+   policy for mid-dialog requests compared with other requests.
+
+4.7.  Proxy Behaviour
+
+   A proxy that receives a mid-dialog request MUST be prepared for the
+   To header field URI and/or the From header field URI to differ from
+   those that appeared in the dialog-forming request and response.
+
+   A proxy that is able to provide an Authentication Service for mid-
+   dialog requests MUST record route if Supported: from-change is
+   indicated in the dialog forming request received by the proxy from
+   the UAC.
+
+5.  Examples
+
+   In the examples below, several messages contain unfolded lines longer
+   than 72 characters.  These are captured between tags.  The single
+   unfolded line is reconstructed by directly concatenating all lines
+   appearing between the tags (discarding any line-feeds or carriage
+   returns).
+
+   In the examples, the domain example.com is assumed to have the
+   following private key (rendered in PEM format).  The private key is
+   used by the Authentication Service for generating the signature in
+   the Identity header field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                     [Page 9]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+      -----BEGIN RSA PRIVATE KEY-----
+      MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
+      aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
+      IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
+      AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
+      PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+      +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
+      tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
+      0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
+      J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
+      DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
+      xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
+      6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
+      Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
+      -----END RSA PRIVATE KEY-----
+
+5.1.  Sending Connected Identity after Answering a Call
+
+   In this example, Carol's UA has been reached by retargeting at the
+   proxy and thus her identity (AoR) is not equal to that in the To
+   header field of the received INVITE request (Bob).  Carol's UA
+   conveys Carol's identity in the From header field of an UPDATE
+   request.  The proxy also provides an Authentication Service and
+   therefore adds Identity and Identity-Info header fields to the UPDATE
+   request.
+
+Alice's UA        PROXY +          Carol's UA
+              Authentication
+                 Service
+
+      INVITE(1)            INVITE(2)
+  ---------------->   ---------------->
+
+       200(4)                200(3)
+  <----------------   <----------------
+
+       ACK(5)                ACK(6)
+  ---------------->   ---------------->
+
+      UPDATE(8)            UPDATE(7)
+  <----------------   <----------------
+
+       200(9)                200(10)
+  ---------------->   ---------------->
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 10]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+INVITE (1):
+
+INVITE sip:Bob@example.com SIP/2.0
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
+To: Bob <sip:bob@example.com>
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:alice@ua1.example.com>
+Content-Type: application/sdp
+Content-Length: 154
+
+v=0
+o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
+s=Session SDP
+c=IN IP4 ua1.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 11]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+INVITE (2):
+
+INVITE sip:Carol@ua2.example.com SIP/2.0
+Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
+<allOneLine>
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
+1
+</allOneLine>
+To: Bob <sip:bob@example.com>
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Max-Forwards: 69
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:alice@ua1.example.com>
+Record-Route: <sip:proxy.example.com;lr>
+<allOneLine>
+Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1
+3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT
+p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc="
+</allOneLine>
+Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
+Content-Type: application/sdp
+Content-Length: 154
+
+v=0
+o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
+s=Session SDP
+c=IN IP4 ua1.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 12]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+200 (3):
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.
+0.2.2
+</allOneLine>
+<allOneLine>
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
+1
+<allOneLine>
+To: Bob <sip:bob@example.com>;tag=2ge46ab5
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:carol@ua2.example.com>
+Record-Route: <sip:proxy.example.com;lr>
+Content-Type: application/sdp
+Content-Length: 154
+
+v=0
+o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
+s=Session SDP
+c=IN IP4 ua2.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+200 (4):
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
+1
+</allOneLine>
+To: Bob <sip:bob@example.com>;tag=2ge46ab5
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:carol@ua2.example.com>
+Record-Route: <sip:proxy.example.com;lr>
+Content-Type: application/sdp
+Content-Length: 154
+
+
+
+
+Elwell                      Standards Track                    [Page 13]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+v=0
+o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
+s=Session SDP
+c=IN IP4 ua2.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+ACK (5):
+
+ACK sip:carol@ua2.example.com SIP/2.0
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
+From: Alice <sip:Alice@example.com>;tag=13adc987
+To: Bob <sip:Bob@example.com>;tag=2ge46ab5
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 ACK
+Max-Forwards: 70
+Route: <sip:proxy.example.com;lr>
+Content-Length: 0
+
+ACK (6):
+
+ACK sip:carol@ua2.example.com SIP/2.0
+Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
+<allOneLine>
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.
+1
+</allOneLine>
+From: Alice <sip:Alice@example.com>;tag=13adc987
+To: Bob <sip:Bob@example.com>;tag=2ge46ab5
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 ACK
+Max-Forwards: 69
+Content-Length: 0
+
+UPDATE (7):
+
+UPDATE sip:Alice@ua1.example.com SIP/2.0
+Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:15 GMT
+Route: <sip:proxy.example.com;lr>
+Contact: <sip:Carol@ua2.example.com>
+Content-Length: 0
+
+
+
+Elwell                      Standards Track                    [Page 14]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+      Note that the URI in the From header field differs from that in
+      the To header field in the INVITE request/response.  However, the
+      tag is the same as that in the INVITE response.
+
+UPDATE (8):
+
+UPDATE sip:Alice@ua1.example.com SIP/2.0
+Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
+<allOneLine>
+Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
+3
+</allOneLine>
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Max-Forwards: 69
+Date: Thu, 21 Feb 2002 13:02:15 GMT
+Contact: <sip:Carol@ua2.example.com>
+<allOneLine>
+Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t
+ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9
+KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko="
+</allOneLine>
+Identity-Info: <https://example.com/cert>;alg=rsa-sha1
+Content-Length: 0
+
+200 (9):
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.
+0.2.2
+</allOneLine>
+<allOneLine>
+Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
+3
+</allOneLine>
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Contact: <sip:Alice@ua1.example.com>
+Content-Length: 0
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 15]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+200 (10):
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.
+3
+</allOneLine>
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Contact: <sip:Alice@ua1.example.com>
+Content-Length: 0
+
+5.2.  Sending Revised Connected Identity during a Call
+
+   In this example, a call is established between Alice and Bob, where
+   Bob (not shown) lies behind a B2BUA.  Bob's identity is conveyed by
+   an UPDATE request.  Then the B2BUA executes call transfer using third
+   party call control (3PCC) techniques as described in RFC 3725 [7]
+   (e.g., under the control of a click-to-dial application).  As a
+   result, Alice becomes connected to Carol (also not shown), and a re-
+   INVITE request is issued allowing the session to be renegotiated.
+   The B2BUA provides the Authentication Service and thus generates the
+   Identity header field in the re-INVITE request to provide
+   authentication of Carol's identity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 16]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+Alice's UA        B2BUA
+
+      INVITE(1)
+  ---------------->
+
+       200(2)
+  <----------------
+
+       ACK(3)
+  ---------------->
+
+      UPDATE(4)
+  <----------------
+
+       200(5)
+  ---------------->
+
+    re-INVITE(6)
+  <----------------
+
+       200(7)
+  ---------------->
+
+       ACK(8)
+  <---------------
+
+INVITE (1):
+
+INVITE sip:Bob@example.com SIP/2.0
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
+To: Bob <sip:bob@example.com>
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:alice@ua1.example.com>
+Content-Type: application/sdp
+Content-Length: 154
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 17]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+v=0
+o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
+s=Session SDP
+c=IN IP4 ua1.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+200 (2)
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.
+1
+</allOneLine>
+To: Bob <sip:bob@example.com>;tag=2ge46ab5
+From: Alice <sip:alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 INVITE
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
+Supported: from-change
+Contact: <sip:xyz@b2bua.example.com>
+Content-Type: application/sdp
+Content-Length: 154
+
+v=0
+o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
+s=Session SDP
+c=IN IP4 ua2.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+ACK (3)
+
+ACK sip:xyz@b2bua.example.com SIP/2.0
+Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
+From: Alice <sip:Alice@example.com>;tag=13adc987
+To: Bob <sip:Bob@example.com>;tag=2ge46ab5
+Call-ID: 12345600@ua1.example.com
+CSeq: 1 ACK
+Max-Forwards: 70
+Content-Length: 0
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 18]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+UPDATE (4)
+
+UPDATE sip:alice@ua1.example.com SIP/2.0
+Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
+From: Bob <sip:Bob@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:12 GMT
+Contact: <sip:xyz@b2bua.example.com>
+<allOneLine>
+Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO
+UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c
+D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E="
+</allOneLine>
+Identity-Info: <https://example.com/cert>;alg=rsa-sha1
+Content-Length: 0
+
+200 (5)
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.
+2.2
+</allOneLine>
+From: Bob <sip:Bob@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 2 UPDATE
+Contact: <sip:Alice@ua1.example.com>
+Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 19]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+re-INVITE (6)
+
+INVITE sip:alice@ua1.example.com SIP/2.0
+Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 3 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:03:20 GMT
+Contact: <sip:xyz@b2bua.example.com>
+<allOneLine>
+Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp
+al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U
+3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo="
+</allOneLine>
+Identity-Info: <https://example.com/cert>;alg=rsa-sha1
+Content-Length: 0
+
+200 (7)
+
+SIP/2.0 200 OK
+<allOneLine>
+Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.
+2.2
+</allOneLine>
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 3 INVITE
+Contact: <sip:Alice@ua1.example.com>
+Content-Length: 154
+
+v=0
+o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
+s=Session SDP
+c=IN IP4 ua1.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 20]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+ACK (8)
+
+ACK sip:alice@ua1.example.com SIP/2.0
+Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
+From: Carol <sip:Carol@example.com>;tag=2ge46ab5
+To: Alice <sip:Alice@example.com>;tag=13adc987
+Call-ID: 12345600@ua1.example.com
+CSeq: 3 ACK
+Max-Forwards: 70
+Content-Length: 154
+
+v=0
+o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
+s=Session SDP
+c=IN IP4 ua3.example.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+
+6.  IANA Considerations
+
+   This specification registers a new SIP option tag, as per the
+   guidelines in Section 27.1 of RFC 3261 [1].
+
+   This document defines the SIP option tag "from-change".
+
+   The following row has been added to the "Option Tags" section of the
+   SIP Parameter Registry:
+
+   +------------+------------------------------------------+-----------+
+   | Name       | Description                              | Reference |
+   +------------+------------------------------------------+-----------+
+   | from-change| This option tag is used to indicate that | [RFC4916] |
+   |            | a UA supports changes to URIs in From    |           |
+   |            | and To header fields during a dialog.    |           |
+   +------------+------------------------------------------+-----------+
+
+7.  Security considerations
+
+   RFC 4474 [3] discusses security considerations relating to the
+   Identity header field in some detail.  Those same considerations
+   apply when using the Identity header field to authenticate a
+   connected identity in the From header field URI of a mid-dialog
+   request.
+
+   A received From header field URI in a mid-dialog request for which no
+   valid Identity header field (or other means of authentication) has
+   been received either in this request or in an earlier request on this
+
+
+
+Elwell                      Standards Track                    [Page 21]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+   dialog cannot be trusted (except in very closed environments) and is
+   expected to be treated in a similar way to a From header field in a
+   dialog-initiating request that is not backed up by a valid Identity
+   header field.  However, it is recommended not to reject a mid-dialog
+   request on the grounds that the Identity header field is missing
+   (since this would interfere with ongoing operation of the call).  The
+   absence of a valid Identity header field can influence the
+   information given to the user.  A UA can clear the call if policy or
+   user preference dictates.
+
+   A signed connected identity in a mid-dialog request (URI in the From
+   header field accompanied by a valid Identity header field) provides
+   information about the peer UA in a dialog.  In the case of the UA
+   that was the UAS in the dialog-forming request, this identity is not
+   necessarily the same as that in the To header field of the dialog-
+   forming request.  This is because of retargeting during the routing
+   of the dialog-forming request.  A signed connected identity says
+   nothing about the legitimacy of such retargeting, but merely reflects
+   the result of that retargeting.  History information (RFC 4244 [8])
+   can provide additional hints as to how the connected user has been
+   reached.
+
+   Likewise, when a signed connected identity indicates a change of
+   identity during a dialog, it conveys no information about the reason
+   for such a change of identity or its legitimacy.
+
+   Use of the sips URI scheme can minimize the chances of attacks in
+   which inappropriate connected identity information is sent, either at
+   call establishment time or during a call.
+
+   Anonymity can be required by the user of a connected UA.  For
+   anonymity the UA is expected to populate the URI in the From header
+   field of a mid-dialog request in the way described in RFC 4474 [3].
+
+8.  Acknowledgments
+
+   Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani,
+   Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric
+   Rescorla, Jonathan Rosenberg, Shida Schubert, Ya-Ching Tan, and Dan
+   Wing for providing valuable comments.
+
+
+
+
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 22]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+        Session Initiation Protocol", RFC 3261, June 2002.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [3]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
+        Identity Management in the Session Initiation Protocol (SIP)",
+        RFC 4474, August 2006.
+
+   [4]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
+        Method", RFC 3311, September 2002.
+
+   [5]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+        Responses in the Session Initiation Protocol (SIP)", RFC 3262,
+        June 2002.
+
+9.2.  Informative References
+
+   [6]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
+        "SIP: Session Initiation Protocol", RFC 2543, March 1999.
+
+   [7]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
+        "Best Current Practices for Third Party Call Control (3pcc) in
+        the Session Initiation Protocol (SIP)", RFC 3725, June 2002.
+
+   [8]  Barnes, M., "An Extension to the Session Initiation Protocol
+        (SIP) for Request History Information", RFC 4244, November 2005.
+
+Author's Address
+
+   John Elwell
+   Siemens Enterprise Communications Limited
+   Technology Drive
+   Beeston, Nottingham  NG9 1LA
+   UK
+
+   Phone: +44 115 943 4989
+   EMail: john.elwell@siemens.com
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 23]
+
+RFC 4916                    SIP Connected ID                   June 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Elwell                      Standards Track                    [Page 24]
+