doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc7329.txt b/doc/rfc/rfc7329.txt
new file mode 100644
index 0000000..5466d2c
--- /dev/null
+++ b/doc/rfc/rfc7329.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         H. Kaplan
+Request for Comments: 7329                                        Oracle
+Category: Informational                                      August 2014
+ISSN: 2070-1721
+
+
+     A Session Identifier for the Session Initiation Protocol (SIP)
+
+Abstract
+
+   There is a need for having a globally unique session identifier for
+   the same SIP session that can be consistently maintained across SIP
+   Proxies, Back-to-Back User Agents (B2BUAs), and other SIP
+   middleboxes, for the purpose of troubleshooting.  This document
+   proposes a new SIP header to carry such a value: Session-ID.
+
+   The mechanism defined in this document has been widely deployed, and
+   is being followed in a backward-compatible fashion for a new
+   Standards Track document produced by the INSIPID Working Group.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7329.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan                        Informational                     [Page 1]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements ...............................................4
+   2. Terminology .....................................................4
+   3. Overview of Operation ...........................................4
+   4. Session-ID Behavior .............................................5
+      4.1. Generating a Session-ID Value ..............................5
+      4.2. UAC Behavior ...............................................6
+      4.3. UAS Behavior ...............................................6
+      4.4. Proxy Behavior .............................................6
+      4.5. B2BUA Behavior .............................................7
+           4.5.1. B2BUA Generation of New Session-ID ..................8
+           4.5.2. B2BUA Insertion of Saved Session-ID .................8
+   5. Handling SIP Transfer Scenarios .................................8
+      5.1. Out-of-Dialog REFER ........................................9
+      5.2. Refer-To URI ...............................................9
+      5.3. Out-of-Dialog INVITE with Replaces .........................9
+   6. Session-ID Migration and Failure Scenarios .....................10
+   7. New 'Session-ID' Header ........................................11
+      7.1. Augmented BNF Definitions .................................11
+   8. Example Exchange ...............................................11
+   9. Security Considerations ........................................11
+      9.1. Security Considerations for Administrators ................12
+      9.2. Security Considerations for Session-ID Extensions .........12
+   10. IANA Considerations ...........................................13
+   11. Acknowledgments ...............................................13
+   12. References ....................................................13
+      12.1. Normative References .....................................13
+      12.2. Informative References ...................................14
+   Appendix A. Use Cases Not in Scope for Session-ID .................15
+      A.1. Dialog Correlation for SIP ................................15
+
+
+
+
+Kaplan                        Informational                     [Page 2]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+1.  Introduction
+
+   This RFC, which contains the text of an individual Internet-Draft
+   that was submitted originally to the DISPATCH Working Group, is being
+   published now as an Informational document to provide a reference for
+   later RFCs.  The mechanism defined in this document has been widely
+   deployed and is being followed in a backward-compatible fashion for a
+   new Standards Track document produced by the INSIPID Working Group.
+
+   The SIP [RFC3261] Call-ID header value is a globally unique
+   identifier, which is mandatory in all requests/responses and
+   identifies SIP messages belonging to the same dialog or registration.
+   It provides a portion of the SIP message dialog-matching criteria and
+   is used in such things as "Replaces" headers [RFC3891] and dialog-
+   event packages [RFC4235] for matching to dialogs, and in SIP Identity
+   [RFC4474] and Connected Identity [RFC4916] as one of the inputs for
+   signing.
+
+   In practice, the Call-ID is often changed by SIP Back-to-Back User
+   Agents (B2BUAs) and other such middleboxes in the logical end-to-end
+   message path.  A B2BUA logically represents a SIP User Agent Server
+   (UAS) and User Agent Client (UAC), and as such generates a new
+   Call-ID value for the dialog it creates on its UAC side; in fact, for
+   some B2BUA scenarios the Call-ID *must* be changed for SIP to
+   function properly.
+
+   At the same time, there is a need for a unique, common, consistent
+   end-to-end identifier to help troubleshoot SIP sessions and message
+   flows as they cross SIP nodes.  Troubleshooting is more complicated
+   if multiple legs of the session are on different sides of B2BUAs, due
+   to the lack of a common identifier such as a Call-ID to tie the legs
+   together.  Proprietary mechanisms are currently used to achieve this
+   goal.
+
+   Therefore, in order to provide an identifier that will not be
+   modified/replaced by B2BUAs, this document proposes a new SIP Header
+   "Session-ID" and mandatory rules for the value of such a header.  The
+   rules are designed to be such that the value in the Session-ID header
+   is not considered unsafe or private and does not have any property
+   that would cause B2BUAs to change it.  The goal of this document is
+   to enable troubleshooting by providing a unique identifier for a
+   given session that can successfully cross B2BUAs, such as Application
+   Servers, softswitches, Private Branch Exchanges (PBXs), Session
+   Border Controllers (SBCs), feature servers, etc.
+
+
+
+
+
+
+
+Kaplan                        Informational                     [Page 3]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+1.1.  Requirements
+
+   The following requirements drive the need for Session-ID:
+
+   REQ1: It must be possible for an administrator to use the identifier
+         to identify a set of dialogs that have a direct correlation
+         with each other such that they represent the same SIP session,
+         with as high a probability as possible.
+
+   REQ2: It must be possible to pass the identifier through SIP B2BUAs,
+         with as high a probability as possible.  This requirement
+         drives the following requirements:
+
+         REQ2a: The identifier must not reveal any information related
+                to any SIP device or domain identity, including IP
+                address, port, hostname, domain name, username, Address-
+                of-Record (AoR), MAC address, IP address family,
+                transport type, etc.
+
+         REQ2b: The identifier must not reveal to the receiver of it
+                that the Call-ID, tags, or any other SIP header or body
+                portion have been changed by middleboxes, with as high a
+                probability as possible.
+
+         REQ2c: The identifier must not be used for anything at a SIP
+                layer to change the behavior of the SIP protocol.
+
+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 [RFC2119].
+
+   This document uses the terms "header field" and "header field value"
+   following the definition of those terms in [RFC3261]; they are not
+   interchangeable.  The "header field" is the entire SIP header's
+   contents, including any parameters.  The "header field value" is only
+   the field-value portion, which does not include header parameters.
+
+3.  Overview of Operation
+
+   The general concept is that the UAC generating an out-of-dialog
+   request generates a new, pseudorandom, unique value that remains
+   constant for the duration of the transaction, any dialog created from
+   that request, or for a registration.  The value is inserted in a new
+   Session-ID header field defined in this document.  The UAC and UAS
+   then reflect this header field value in all messages for the duration
+   of the dialog.  In other words, the Session-ID provides a value
+
+
+
+Kaplan                        Informational                     [Page 4]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   similar in nature to Call-ID, except one that crosses B2BUAs and that
+   has no sensitive information in it.
+
+   To aid in migration of deployments, a B2BUA or Proxy MAY also
+   generate and/or insert the value on behalf of a UAC or UAS, if one or
+   the other does not support this document's mechanism.
+
+   Although the Session-ID concept is similar to that of Call-ID, it is
+   not used for message dialog-matching rules in RFC 3261, nor does it
+   change the Call-ID usage, nor does it replace the Call-ID value.
+   Instead, this new header field provides an identifier for
+   troubleshooting uses only.
+
+   The format of the Session-ID value is restricted, both to avoid
+   detection of the system type that generated it and to keep it a
+   hexadecimal representation such that it can be stored as a 128-bit
+   binary value in log records.
+
+4.  Session-ID Behavior
+
+4.1.  Generating a Session-ID Value
+
+   This document proposes the Session-ID header value be generated based
+   on a defined hash mechanism for creating a 128-bit pseudorandom value
+   and be encoded as its lowercase hex representation.  The reason for
+   specifying the mechanism is twofold: to make it impossible to
+   determine the manufacturer of the device that generated it by looking
+   at its format or value, and to allow devices to generate the same
+   value if they have the same private key.
+
+   The Session-ID value is generated by taking the Call-ID header value
+   and SHA-1 hashing it based on HMAC (as defined in [RFC2104]) using a
+   locally generated pseudorandom 128-bit system secret key to create a
+   128-bit resultant HMAC value.  The secret key makes the resultant
+   HMAC value not re-creatable by other parties; this is necessary to
+   prevent detection of Call-IDs being changed, as required by REQ2b.
+   Otherwise, middleboxes may have motivation to remove the Session-ID
+   in order to hide the fact that they changed the Call-ID.
+
+   Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value,
+   secret_key), and the 128-bit result is encoded using lowercase
+   alphanumeric hex representation, as defined in Section 7.1
+   ("Augmented BNF Definitions").
+
+   In order to enable troubleshooting of in-dialog messages, a generator
+   needs to remember or re-create the same Session-ID value for the
+   duration of a given dialog(s).  This is described in more detail in
+   the subsequent sections of this document.
+
+
+
+Kaplan                        Informational                     [Page 5]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+4.2.  UAC Behavior
+
+   The rules for when a UAC generates a new Session-ID value are similar
+   as those for Call-ID value: a UAC supporting this document's
+   mechanism MUST generate a new unique Session-ID value when it
+   generates an out-of-dialog request or when there is a new
+   Registration.  The exception to this rule is for out-of-dialog REFER
+   requests or for an INVITE with a Replaces header field (see
+   [RFC3891]), as described in Section 5.
+
+   The UAC MUST reuse the same Session-ID value for in-dialog messages
+   as that of the original dialog-creating request, and for any out-of-
+   dialog request that it retransmits or re-generates in response to a
+   3xx that it reformulates due to failure responses.  This follows the
+   rules in [RFC3261] for Call-ID generation.
+
+   Session-ID values in Registration "refreshes" -- REGISTER requests
+   that are used to update the expiry time but not to register a new
+   contact -- MUST use the same Session-ID value as previous REGISTER
+   requests.  New Registrations, which add or change the Contact URI for
+   the AoR, but do not simply delete them, MUST use a new Session-ID
+   value.  This follows the behavior of Call-ID per RFC 3261; it is
+   reiterated here because some devices incorrectly change their Call-ID
+   value for every re-Registration, and they MUST NOT do the same to the
+   Session-ID.
+
+   The UAC MUST include the Session-ID header field in every SIP message
+   it transmits.
+
+4.3.  UAS Behavior
+
+   A UAS compliant with this document MUST copy a Session-ID header
+   field (received in a request) into responses and subsequent upstream
+   requests sent within the dialog.
+
+   If an out-of-dialog request is received without a Session-ID header
+   field, the UAS SHOULD generate a new one for subsequent use in the
+   transaction and dialog, as defined for a UAC, and use the same value
+   in all responses and upstream in-dialog requests for the same dialog.
+
+4.4.  Proxy Behavior
+
+   A Proxy MUST NOT remove or modify the Session-ID header field it
+   receives, if one is in the message.  By definition, a Proxy that is
+   compliant with RFC 3261 would not modify or remove such a header.
+
+
+
+
+
+
+Kaplan                        Informational                     [Page 6]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   If the Proxy forks a request, it MUST copy the same Session-ID header
+   field into all the forked request copies.  If the Proxy recurses
+   requests due to 3xx redirection, or regenerates requests due to
+   failures, it MUST use the same Session-ID header field as the
+   original request, just as the UAC does.
+
+   If the Proxy locally generates any response or request based on a
+   received request, including 100 Trying, it MUST insert any received
+   Session-ID header field from the original request into the response
+   message it locally creates.  This is necessary for troubleshooting
+   purposes.
+
+   A Proxy compliant with this document MAY generate a new Session-ID or
+   insert a previously saved one if and only if none existed in a
+   received message, following the rules for doing so as a B2BUA as
+   defined in Section 4.5.
+
+4.5.  B2BUA Behavior
+
+   A B2BUA compliant with this document MUST copy:
+
+   -  the Session-ID header field it receives in requests as a UAS into
+      the related requests it generates as a UAC, and
+
+   -  any Session-ID header field it receives in responses as a UAC into
+      the correlated responses it generates as a UAS.
+
+   If the B2BUA forks or creates multiple requests as a UAC, from a
+   request it received as a UAS, the B2BUA MUST copy the same Session-ID
+   header field it received into all the forks/requests.  If the B2BUA
+   recurses on 3xx responses, or regenerates requests due to failures,
+   it MUST use the same Session-ID field, just as the UAC does.
+
+   If the B2BUA locally generates any response or request based on a
+   received request, including 100 Trying, it MUST insert any received
+   Session-ID field from the original request into the response message
+   it locally creates.
+
+   A B2BUA MAY remember the received Session-ID value for the duration
+   of the transaction and dialog, for the purpose of reinsertion, in
+   case the far end does not support this document.
+
+   In all cases, if the SIP message received by a B2BUA contains a
+   Session-ID header field, a B2BUA compliant with this document MUST
+   NOT remove, modify, or replace it as it "forwards" the message on the
+   other logical UA "side" of itself.
+
+
+
+
+
+Kaplan                        Informational                     [Page 7]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+4.5.1.  B2BUA Generation of New Session-ID
+
+   If an out-of-dialog request is received by a B2BUA compliant with
+   this document, and the request does *not* contain a Session-ID header
+   field, the B2BUA MAY generate a new one.  The new Session-ID value
+   MUST be calculated based on the received Call-ID of the received
+   request, even if the B2BUA uses a different Call-ID value for
+   requests generated on its other "side(s)".  It MUST then insert the
+   new Session-ID in any requests or responses it generates, as if it
+   had actually received the new Session-ID from the UAC, following the
+   rules previously defined for a B2BUA.  This allows for a B2BUA to
+   provide a migration to Session-ID deployment, on behalf of upstream
+   nodes that do not yet support it.
+
+   As defined previously, if any received message already had a
+   Session-ID, a B2BUA compliant with this document would not replace
+   it.
+
+4.5.2.  B2BUA Insertion of Saved Session-ID
+
+   If a Session-ID was received in an out-of-dialog request, or the
+   B2BUA locally generated one because none existed, the B2BUA SHOULD
+   insert the same Session-ID field into all responses and upstream
+   in-dialog requests if and only if a Session-ID is not already in
+   them.  This allows for a B2BUA to provide a migration to Session-ID
+   deployment on behalf of downstream nodes that do not yet support it.
+
+5.  Handling SIP Transfer Scenarios
+
+   The transfer or movement of SIP sessions represents a complication
+   for a mechanism like Session-ID.  On the one hand, the replacement
+   SIP session represents a new one and could reasonably be expected to
+   use a new Session-ID value; on the other hand, from a troubleshooting
+   and human-user perspective, it is clearly related to, if not just a
+   continuation of, the previous session.  Since the purpose of this
+   document's mechanism is to aid monitoring and troubleshooting, and
+   it's not used for actual SIP protocol mechanics, the behavior defined
+   in this section is to reuse the same Session-ID value for the
+   replacement SIP session.
+
+   In order to do so, the Session-ID of the "original" session is
+   transferred as well, in the Refer-To URI of a REFER request as
+   described in [RFC3515].  Furthermore, out-of-dialog REFER and INVITE
+   with Replaces requests as described in [RFC3891] use the appropriate
+   Session-ID values.  This assumes, of course, that the UAs involved
+   support the Session-ID mechanism.  If they do not, then it is
+   possible for the Session-ID to not be "carried forward" to the new
+
+
+
+
+Kaplan                        Informational                     [Page 8]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   SIP dialog.  Unfortunately, this means troubleshooting such dialogs
+   is not improved or aided by this document's mechanism; but, it would
+   not "break" anything at a SIP layer.
+
+   It should also be noted that using the same Session-ID for the
+   transferred-to dialog means the same Session-ID now exists in two
+   independent dialogs, because the original one may well continue due
+   to the implicit Subscription usage created by a REFER.  That implicit
+   Subscription-based usage will continue to use the same Session-ID as
+   the new dialog created to the transferred-to party.
+
+   In the following subsections, the term "UA" is used for User Agent.
+   The language applies to the SIP device that creates the request,
+   whether it be a UA or B2BUA.
+
+5.1.  Out-of-Dialog REFER
+
+   A UA compliant with this document MUST use the same Session-ID header
+   field value for an out-of-dialog REFER request it generates, as the
+   original dialog the REFER is targeted to (i.e., as if the REFER had
+   been in-dialog).  For example, if UA Bob has a SIP dialog X to Alice,
+   and Bob sends an out-of-dialog REFER to Alice to refer her to
+   Charlie, the Session-ID header field value of the REFER request would
+   be the same as that used in dialog X.
+
+5.2.  Refer-To URI
+
+   A UA compliant with this document MUST add the Session-ID header
+   field as an embedded header in the Refer-To header field URI of any
+   REFER request it generates, using the value of the session it is
+   referring to.  For example, if UA Bob has a SIP dialog X to Alice and
+   dialog Y to Charlie, and Bob sends a REFER request to Alice to refer
+   her to Charlie, the Session-ID header field value embedded in the
+   Refer-To URI of the REFER request would be the same as that used in
+   dialog Y.
+
+5.3.  Out-of-Dialog INVITE with Replaces
+
+   When generating an out-of-dialog INVITE with a Replaces header field
+   as described in [RFC3891], a UA compliant with this document MUST use
+   the same Session-ID header field value for the INVITE request as that
+   used for the dialog it is replacing, if it knows the value.
+   Typically, the UA would know the value by having received it in the
+   Refer-To header field of a REFER, as described previously.  For
+   example, if UA Bob has a SIP dialog X to Alice and dialog Y to
+   Charlie, and Bob sends a REFER request to Alice to refer her to
+   Charlie, the Session-ID header field value embedded in the Refer-To
+
+
+
+
+Kaplan                        Informational                     [Page 9]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   URI of the REFER request would be the one used in dialog Y, which
+   Alice would use as the Session-ID header field value for her INVITE
+   to Charlie.
+
+   If the UA does not know the Session-ID of the dialog it is replacing,
+   for example, because it is not embedded in the Refer-To URI of a
+   received REFER, then it MUST use a new Session-ID value, calculated
+   using the mechanism as defined in Section 4.1 with the Call-ID of the
+   INVITE.
+
+6.  Session-ID Migration and Failure Scenarios
+
+   SIP is already widely deployed on the Internet, and it is impractical
+   to expect all UAs to be upgraded to support this document's mechanism
+   in the near future.  A solution for gradual migration is necessary
+   and is provided by this document by allowing B2BUAs or Proxies to
+   perform the Session-ID generator and inserter role.  Even within
+   those device types, it is impractical to expect all B2BUAs to support
+   this mechanism all at once or any time in the near future.
+   Therefore, it is expected that some B2BUAs and/or UAs will support
+   generating and inserting Session-ID, while others will not support
+   Session-ID at all.
+
+   Due to the varying types of B2BUAs (such as PBXs, SBCs, Application
+   Servers, feature servers, and softswitches of various flavors) and
+   the numerous SIP deployment models in use, there are going to be
+   cases in which Session-ID will fail to be a consistent value for all
+   related dialogs or fail to successfully match.  The goal of this
+   document is to improve troubleshooting of current deployments as much
+   as possible -- and, in this author's opinion, that is the best that
+   can be done given the constraints.
+
+   One example is for forked requests: if a UAC that does not support
+   this mechanism sends a request to a Proxy or B2BUA that also does not
+   support this mechanism, each fork could reach B2BUAs or UASs that
+   *do* support this mechanism.  In such a case, each of those forked-to
+   B2BUA/UAS will generate unique Session-IDs and put them in their
+   responses, temporarily leading to multiple, different Session-ID
+   values for the same related early dialogs.  Typically, the UAC would
+   eventually only accept one of the dialogs, and only one Session-ID
+   would remain.
+
+
+
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 10]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+7.  New 'Session-ID' Header
+
+   This document adds the "Session-ID" token to the definition of the
+   element "message-header" in the SIP message grammar.  The Session-ID
+   header is a single-instance header.
+
+7.1.  Augmented BNF Definitions
+
+    Session-ID           =  "Session-ID" HCOLON sess-id
+                            *( SEMI generic-param )
+    sess-id              =  32(DIGIT / %x61-66)  ; 32 chars of [0-9a-f]
+
+   NOTE: The sess-id value is technically case-INSENSITIVE, but only
+   lowercase characters are allowed.
+
+   See the Security Considerations section for discussion about using
+   header parameters in Session-ID header fields.
+
+8.  Example Exchange
+
+   In the following example, Alice initiates a call to Bob.  Alice
+   generates a Session-ID header in the out-of-dialog INVITE.
+
+   Alice generates the following.  (Note: much has been left out for
+   simplicity.)
+
+      INVITE sip:bob@example.com SIP/2.0
+      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
+      From: Alice <sip:alice@example.net>;tag=1234567
+      To: Bob <sip:bob@example.com>
+      Call-Id: 123456mcmxcix@1.2.3.4
+      Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6
+      CSeq: 1 INVITE
+      Contact: <sip:alice@192.168.1.1>
+
+9.  Security Considerations
+
+   There are several security considerations surrounding this document's
+   mechanism.
+
+   The Session-ID generation algorithm should provide a reasonably
+   random 32-character Session-ID value to avoid collisions and should
+   not let one re-create the original Call-ID.
+
+   There is no known security issue with viewing or modifying the
+   Session-ID, other than to hamper troubleshooting efforts.
+
+
+
+
+
+Kaplan                        Informational                    [Page 11]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+9.1.  Security Considerations for Administrators
+
+   The requirement for the Session-ID is to be an identifier which
+   cannot be used by a recipient to identify if the Call-ID has been
+   changed by middleboxes.  As such, a UAS/UAC cannot detect the
+   original Call-ID, nor whether it has been changed; thus,
+   administrators should not be concerned if the Session-ID header field
+   is "passed through".
+
+9.2.  Security Considerations for Session-ID Extensions
+
+   The Session-ID's value is created from the Call-ID using a hashing
+   mechanism based on [RFC2104], using SHA-1 and a secret key known only
+   to the system generating the Session-ID.  Because the algorithm is
+   defined in this document, it should be fairly secure from detecting
+   the generator of the Session-ID, in terms of manufacturer or code
+   base.
+
+   The Session-ID generation algorithm should provide a reasonably
+   random 128-bit Session-ID value, to avoid collisions, and should not
+   let one re-create the original Call-ID.  The secret key MUST only be
+   used for the Session-ID mechanism, in case a weakness is found that
+   reveals the key.  One such weakness may be that a UAC generates one
+   or more Call-IDs that have a property that makes determining the key
+   more likely.
+
+   In general, B2BUA behavior cannot be dictated by standards.  They do
+   whatever their owners/operators wish them to do, or whatever is
+   necessary to make their applications work.  This document attempts to
+   normatively specify some B2BUA behavior, by creating a SIP header
+   value for which the properties are such that B2BUAs should have no
+   legitimate reason to interfere.  This effectively creates a "promise"
+   that future uses of this Session-ID header field, including its value
+   *and* any future defined parameters, maintain this benign property.
+   Any future extensions to the Session-ID mechanism and header field
+   MUST maintain this property, or else B2BUAs will begin to modify it
+   again or remove it, and its value will be lost.
+
+   Manufacturers of SIP devices should note that a B2BUA may inspect the
+   Session-ID header field and may remove it if it does not comply with
+   this document's value restrictions.  Any Session-ID header parameters
+   MUST be registered with IANA and documented in RFCs from the IETF
+   stream, pursuant to the requirements of [RFC3968].
+
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 12]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+10.  IANA Considerations
+
+   IANA has registered a new SIP header field named 'Session-ID',
+   pursuant to the registration policies for such in [RFC5727].  This is
+   a single-instance header field and is appropriate for any SIP
+   message, of any Method type, in any request or response.
+
+   The ABNF rules [RFC5234] for this new header allow for header
+   parameters; however, they must be registered following the rules of
+   [RFC3968], as required by [RFC5727].
+
+   This registration is intended to be temporary.  The author expects
+   that a Standards Track definition of Session-ID will be published at
+   a future date.  Assuming such a document is published, it will
+   replace this registration with a reference to itself, at which point
+   this document will no longer be referenced by IANA.
+
+11.  Acknowledgments
+
+   Thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat,
+   Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, Laura Liess,
+   and Adam Roach for their input.
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3261]  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.
+
+   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+              Method", RFC 3515, April 2003.
+
+   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
+              Protocol (SIP) "Replaces" Header", RFC 3891, September
+              2004.
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 13]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
+              (IANA) Header Field Parameter Registry for the Session
+              Initiation Protocol (SIP)", BCP 98, RFC 3968, December
+              2004.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234, January
+              2008.
+
+   [RFC5727]  Peterson, J., Jennings, C., and R. Sparks, "Change Process
+              for the Session Initiation Protocol (SIP) and the Real-
+              time Applications and Infrastructure Area", BCP 67, RFC
+              5727, March 2010.
+
+12.2.  Informative References
+
+   [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An
+              INVITE-Initiated Dialog Event Package for the Session
+              Initiation Protocol (SIP)", RFC 4235, November 2005.
+
+   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
+              Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 4474, August 2006.
+
+   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
+              Protocol (SIP)", RFC 4916, June 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 14]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+Appendix A.  Use Cases Not in Scope for Session-ID
+
+   It is very tempting to use a header field value such as that provided
+   by Session-ID, for other purposes than troubleshooting.  In a
+   previous document for this same Session-ID concept, the proposal
+   included other uses; however, these were removed because any use case
+   other than troubleshooting can easily lead to a B2BUA needing to
+   change the value, in certain cases.  That would defeat the
+   troubleshooting value of Session-ID.  This section discusses such use
+   cases and explains why they are potentially harmful.
+
+A.1.  Dialog Correlation for SIP
+
+   Although Session-ID does provide a means to correlate separate SIP
+   dialogs, messages, and transactions, it does so at a higher layer
+   than SIP.  It does not replace the mechanics of SIP using the Call-ID
+   and To/From tags of SIP messages to correlate SIP dialogs, nor in
+   other uses such as Replaces headers or dialog-event packages.  It is
+   tempting, however, to use it for exactly that purpose in certain
+   cases.
+
+   For example, suppose a call transfer case where Alice calls Bob
+   through B2BUA-1.  Bob then calls Charlie and sends Charlie a REFER
+   with embedded Replaces to make Charlie send an INVITE with a Replaces
+   header to Alice, to replace the Alice-Bob session.  If Charlie uses a
+   different B2BUA-2 to reach Alice, the INVITE with Replaces will fail
+   because the Call-ID/tags won't match anything B2BUA-2 or Alice knows
+   about.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 15]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   +-----+     +-------+    +-------+    +-----+     +-------+
+   |Alice|     |B2BUA-1|    |B2BUA-2|    | Bob |     |Charlie|
+   +-----+     +-------+    +-------+    +-----+     +-------+
+      |            |            |           |            |
+      |INVITE      |            |           |            |
+      |callid:1a   |callid:1b   |           |            |
+      |----------->|----------------------->|INVITE      |
+      |sessid:1    |sessid:1    |           |callid:2a   |
+      |            |            |           |----------->|
+      |            |            |           |sessid:2    |
+      |            |            |           |            |
+      |            |            |           |REFER       |
+      |            |            |           |referto:1b  |
+      |            |            |           |----------->|
+      |            |            |           |            |
+      |            |            |           |      INVITE|
+      |            |            |           | replaces:1b|
+      |            |            X<-----------------------|
+      |            |      INVITE|           |    sessid:1|
+      |            | replaces:1b|           |            |
+      X<------------------------|           |            |
+      |            |    sessid:1|           |            |
+
+                 Example 1: Call Transfer Case
+
+   If, on the other hand, Alice were to use the Session-ID value for
+   correlation, she would see it matches her dialog with Bob (assuming
+   the Session-ID were passed along in the Refer-To and Replaces info).
+
+   There are problems with this approach, however.  The first problem
+   is, by not sending the INVITE with Replaces to B2BUA-1, B2BUA-1 is in
+   an incorrect state; the dialog is getting replaced, and the B2BUA
+   doesn't know it.
+
+   A second issue is the Session-ID doesn't identify enough information
+   to replace a dialog.  Imagine there were a third B2BUA, such as a
+   softswitch, between Alice and B2BUA-1 and B2BUA-2, and the INVITE
+   with Replaces reached the softswitch before Alice.  The softswitch
+   won't know which "side" the INVITE is replacing.  The To/From tags no
+   longer match anything the softswitch knows about, so it can't figure
+   out if the INVITE with Replaces is replacing the dialog from
+   softswitch to Alice, or the one to Bob.  If we try to fix this by
+   creating a tag-type value pair for Session-ID, we're back to devices
+   changing those tag values and defeating the matching property.
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 16]
+
+RFC 7329                 SIP Session Identifier              August 2014
+
+
+   Another example is based on 3GPP 24.605 Annex A.2.2.  Alice has a
+   call with Bob through multiple B2BUAs and an Application Server.  The
+   dialogs of that call all have the same Session-ID, but unique
+   Call-ID/tags.
+
+   Alice wants to invoke a third-party conference facility in the AS and
+   to reference the call she has with Bob for that.  In this particular
+   3GPP scenario, to do that Alice sends a new INVITE to the AS with a
+   resource-list body (a la RFC 5366) containing the call information
+   for the original call.  This is the "RL<sessid:1>" piece in the
+   diagram.  It has the Call-ID/tags as well, but they'll be wrong when
+   received at the AS.
+
+   The AS processes that list, can't match the Call-ID/tags in the
+   resource-lit but does match the Session-ID, and sends a re-INVITE to
+   party B within the original call's dialog.
+
+   +-----+     +-------+      +----+    +-------+     +-----+
+   |Alice|     |B2BUA-1|      | AS |    |B2BUA-2|     | Bob |
+   +-----+     +-------+      +----+    +-------+     +-----+
+      |            |            |           |            |
+      |INVITE      |            |           |            |
+      |callid:1a   |callid:1b   |callid:1c  |callid:1d   |
+      |----------->|----------->|---------->|----------->|
+      |sessid:1    |sessid:1    |sessid:1   |sessid:1    |
+      |            |            |           |            |
+      |INVITE      |            |           |            |
+      |callid:2a   |callid:2b   |           |            |
+      |----------->|----------->|           |            |
+      |sessid:2    |sessid:2    |re-INVITE  |            |
+      |RL<sessid:1>|RL<sessid:1>|callid:1c  |callid:1d   |
+      |            |            |---------->|----------->|
+      |            |            |sessid:1   |sessid:1    |
+      |            |            |           |            |
+
+                    Example 2: Resource List
+
+Author's Address
+
+   Hadriel Kaplan
+   Oracle
+   EMail: hadrielk@yahoo.com
+
+
+
+
+
+
+
+
+
+Kaplan                        Informational                    [Page 17]
+