The References Header for SIP

In many situations, the processing of a SIP "telephone call" involves a number of different SIP dialogs. Of course, the existing SIP headers provide adequate information for the SIP elements to carry out the needed operations. But in many cases, it is difficult for an observer to identify from a network trace the particular SIP dialogs that are involved in one operation. For example, if a user agent receives a REFER message within one dialog, it sends an INVITE to establish a new dialog which replaces the previous one within the user interface of the user agent. But since the connection between the new dialog and the old dialog is only realized within the user agent, there is no algorithmic way to associate the two dialogs based on the SIP messages alone -- the best available technique is to extract all the messages to/from the particular user agent, and then observe the INVITE that is sent immediately after receipt of the REFER. The purpose of the References header is to allow a SIP message to specify that the message carrying it (and by extension, the dialog that contains the message) is related to one or more other dialogs, specified by their Call-Id values. Ideally, when given a Call-Id, an automated process can use the connections between dialogs specified in References headers to determine the entire set of dialogs that are needed to understand a complete "telephone call" or other SIP interaction.

The syntax of the References header is as follows. (All rules not defined here are taken from section 25.1 of RFC 3261.)

Multiple References headers may appear in a SIP message, and their values may be combined or separated as allowed by section 7.3 of RFC 3261. The ordering of References values is not significant. The call-id elements of the Replaces and Join headers are considered implicit References and so SHOULD NOT be specified in References headers. The presence of a References header in a SIP message means that the message (and by implication, the dialog containing it) is related to the dialog(s) bearing the specified Call-Id(s). Note that since there is no way to specify the to-tag and from-tag of the referenced dialog, the References header does not distinguish different dialogs that have the same Call-Id, and all dialogs sharing a Call-Id are considered to be related a priori. The processor of References headers should consider the "related" relationship of dialogs to include the symmetric-transitive closure of the References relationship; that is, if a message in dialog A references dialog B, and a message in dialog B references dialog C, then all three dialogs should be considered related to each other. The nature of the relationship between the message's dialog and the referenced dialog(s) is indicated by the "rel" parameter (if it is present). Since the message containing the References header is likely to be constrained to be generated after the creation of the dialog mentioned by the header, and the UA may not have control over this time-ordering, relationship natures are considered symmetric. E.g., a request with Call-Id A that performs an inquiry to assist in routing dialog B may contain "References: B;rel=inquiry", but the same meaning can be indicated by a message in dialog B containing "References: A;rel=inquiry". The currently defined values of the "rel" parameter are: "refer" meaning that this request was generated due to a REFER with the specified Call-Id "inquiry" meaning that this request was generated to obtain information needed to properly process a request with the specified Call-Id. (For example, in section 2.16, "Call Pickup" of , a SUBSCRIBE is generated to discover the UA which sent an INVITE to a designated AOR.) "xfer" meaning that the dialog of this message and the dialog with the specified Call-Id are the two legs of a consultative (or attended) transfer. One endpoint of each dialog will become an endpoint of the final dialog. These values are case-sensitive (although the parameter name, "rel", is not). These values are the value of the ref-value after any quoting has been removed. As shown in the ABNF, the quoting which may be applied to rel-value is the same as what may be applied to a gen-value, specifically, if it is surrounded by double-quotes, then any character may be quoted with a backslash. Thus, 'References: 12345600@atlanta.example.com;rel=xfer' is equivalent to 'References: 12345600@atlanta.example.com;rel="xfer"' and 'References: 12345600@atlanta.example.com;rel="\x\f\e\r"' It is expected that the References header will usually appear in the dialog-forming request of a dialog, but it may appear in any request or response. Since 1xx responses are not delivered reliably, a References header value that is present only in a 1xx response may not be seen by an element that ought in principle to see the response, and such a value SHOULD be present in another message of the dialog going to that UA. All parameters and parameter values that are not understood by the processor of the References header MUST be ignored. Parameters and values that start with "X-" (case-insensitive) are reserved for non-standardized purposes. Note that while the SIP References header is similar in function to the Internet e-mail References header, they have different syntaxes and are not interchangeable.

One use of References is to connect a REFER to the INVITE that it causes to be sent. A typical use of REFER is to implement blind transfer. This example is taken from section 2.4, "Transfer - Unattended" of .

| | | 200 OK F3 | | |------------------->| | | ACK F4 | | |<-------------------| | | RTP | | |<==================>| | | | | | Alice performs unattended transfer | | | | | REFER Refer-To:C F5| | |------------------->| | | 202 Accepted F6 | | |<-------------------| | | NOTIFY F7 | | |<-------------------| | | 200 OK F8 | | |------------------->| | | BYE F9 | | |------------------->| | | 200 OK F10 | | |<-------------------| | | No RTP Session | INVITE Referred-By: A F11 | |------------------->| | | 180 Ringing F12 | | |<-------------------| | | 200 OK F13 | | |<-------------------| | | ACK F14 | | |------------------->| | | RTP | | |<==================>| | NOTIFY F15 | | |<-------------------| | | 200 OK F16 | | |------------------->| | | | | ]]> In order to execute the blind transfer, Alice's UA sends a REFER to Bob's UA:

Bob REFER sips:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds8 Max-Forwards: 70 From: Alice ;tag=1234567 To: Bob ;tag=314159 Call-ID: 12345601@atlanta.example.com CSeq: 101 REFER Refer-To: Referred-By: Contact: Content-Length: 0 ]]> Upon receipt of the REFER, Bob's UA sends an INVITE to Carol's UA. In order to make explicit the relationship between the REFER and the INVITE, the INVITE has a References header giving the Call-Id of the REFER:

Carol INVITE sips:carol@chicago.example.com SIP/2.0 References: 12345601@atlanta.example.com;rel=refer Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnashds1 Max-Forwards: 70 From: Bob ;tag=8675309 To: Carol Call-ID: 7436222@atlanta.example.com CSeq: 1 INVITE Contact: Referred-By: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: ... [SDP omitted] ]]>

An attended transfer normally involves three different dialogs. If the transfer completes, and the REFER that completes the transfer has a References header, the References header in the REFER and the Replaces header in the resulting INVITE will suffice to connect the three dialogs. However, to provide complete information if the transfer does not complete, the INVITE that establishes the "second leg" of the transfer scenario should have a References header naming the "first leg". This example is taken from section 2.5, "Transfer - Attended" of .

| | | 180 Ringing F2 | | |<---------------| | | 200 OK F3 | | |<---------------| | | ACK F4 | | |--------------->| | | RTP | | |<==============>| | |INVITE (hold) F5| | |<---------------| | | 200 OK F6 | | |--------------->| | | ACK F7 | | |<---------------| | | No RTP | | | | INVITE F8 | | |------------->| | | 180 Ringing F9 | |<-------------| | | 200 OK F10 | | |<-------------| | | ACK F11 | | |------------->| | | RTP | | |<============>| | |INVITE (hold) F12 | |------------->| | | 200 OK F13 | | |<-------------| | | ACK F14 | | |------------->| | | No RTP | | REFER Refer-To: C F15 | |<---------------| | |202 Accepted F16| | |--------------->| | | NOTIFY F17 | | |--------------->| | | 200 OK F18 | | |<---------------| | | INVITE Replaces: B F19 | |------------------------------>| | 200 OK F20 | |<------------------------------| | ACK F21 | |------------------------------>| | RTP | |<=============================>| | | BYE F22 | | |<-------------| | | 200 OK F23 | | |------------->| | NOTIFY F24 | | |--------------->| | | 200 OK F25 | | |<---------------| | | BYE F26 | | |<---------------| | | 200 OK F27 | | |--------------->| | ]]> The INVITE that establishes the second leg has a References header naming the first leg:

Carol INVITE sips:carol@chicago.example.com SIP/2.0 References: 12345600@atlanta.example.com;rel=xfer Via: SIP/2.0/TLS client.biloxi.example.com:5061 ;branch=z9hG4bKnash Max-Forwards: 70 From: Bob ;tag=8675309 To: Carol Call-ID: sdjfdjfskdf@biloxi.example.com CSeq: 42 INVITE Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: ... [SDP omitted] ]]> As described in , the INVITE that completes the transfer has a References header giving the dialog of the first leg, within which the REFER was sent. It also has a Replaces header giving the dialog of the second leg, which acts as an implicit References.

Carol INVITE sips:39itp34klkd@chicago.example.com;gr SIP/2.0 References: 12345600@atlanta.example.com;rel=refer Via: SIP/2.0/TLS chicago.example.com:5061 ;branch=z9hG4bKadfe4ko To: Carol Max-Forwards: 70 From: Alice ;tag=3461 Call-ID: 9435674543@atlanta.example.com CSeq: 1 INVITE Require: replaces Referred-By: Replaces: sdjfdjfskdf@biloxi.example.com ;to-tag=5f35a3;from-tag=8675309 Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: ... [SDP omitted] ]]>

The References header can be used during a call pickup operation to connect the SUBSCRIBE that is used to locate the target dialog with the INVITE which is generated to execute the pickup. This example is taken from section 2.16, "Call Pickup" of .

| | |180 Ringing F2| | |<-------------| | | | SUBSCRIBE F3 | | |<------------------| | | 200 OK F4 | | |------------------>| | | NOTIFY F5 | | |------------------>| | | 200 OK F6 | | |<------------------| | INVITE Replaces:Bob F7 | |<---------------------------------| | | 200 OK F8 | |--------------------------------->| | CANCEL F9 | | |------------->| | | 200 OK F10 | | |<-------------| | | 487 F11 | | |<-------------| | | ACK F12 | | |------------->| | | ACK F13 | |<---------------------------------| | | | Two way RTP Established | |<================================>| | BYE F14 | |--------------------------------->| | 200 OK F15 | |<---------------------------------| | | ]]> Bill's UA sends a SUBSCRIBE to find the target dialog:

Bob SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74bf Max-Forwards: 70 From: Bill ;tag=8675309 To: Bob Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 1 SUBSCRIBE Contact: Event: dialog Expires: 0 Accept: application/dialog-info+xml Content-Length: 0 ]]> After locating the target dialog, Bill's UA generates an INVITE-with-Replaces to execute the pickup. The UA adds the References header to show the connection with the SUBSCRIBE:

Alice INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0 References: rt4353gs2egg@pc.biloxi.example.com;rel=inquiry Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74HH Max-Forwards: 70 From: Bill ;tag=8675310 To: Alice Call-ID: 563456212@b2.biloxi.example.com CSeq: 1 INVITE Require: replaces Replaces: 12345600@atlanta.example.com ;from-tag=314578;to-tag=1234567;early-only Contact: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: ... [SDP omitted] ]]> Note that the executing INVITE F7 does not mention the Call-Id of the original INVITE F1 because it is mentioned in the Replaces header. If the call pickup operation is done by an agent on behalf of Bill's UA (as in the sipX open-source PBX), the executing INVITE is likely to exist before the SUBSCRIBE is generated. In that case, the SUBSCRIBE will have a References header giving the Call-Id of the INVITE:

Bob SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0 References: 563456212@b2.biloxi.example.com;rel=inquiry Via: SIP/2.0/TLS pc.biloxi.example.com:5061 ;branch=z9hG4bK74bf Max-Forwards: 70 From: Bill ;tag=8675309 To: Bob Call-ID: rt4353gs2egg@pc.biloxi.example.com CSeq: 1 SUBSCRIBE Contact: Event: dialog Expires: 0 Accept: application/dialog-info+xml Content-Length: 0 ]]>

The current version of the sipX open-source PBX adds a References header to the SUBSCRIBE of a call pickup as described in section 2.16, "Call Pickup" of . It has caused no observed interoperability problem.

This section discusses other Internet-drafts and their relationship to this work.

The Session Initiation Protocol (SIP) Dialog Correlation This document defines a new header field for use with SIP. The Same-Session header field is used to logically correlate an existing SIP dialog with a new SIP dialog when the media sessions established by both dialogs can be considered a single logical session. This mechanism can be used to share the user interface and other resources between all the media streams from both sessions. The "Same-Session" header prescribes that the media sessions of two INVITE dialog usages are to be considered part of the same session from the users' points of view. Because of this semantic, it cannot be used in place of the References header, as References can be used to express the relationship between two dialogs that are not connected in any particular way in regard to user interface. However, it would be possible to define a "parallel" value of the "rel" parameter to have the semantics of "Same-Session". This usage would require that the References header appears in the INVITE establishing the second dialog (and that the two INVITEs are properly time-sequenced, or that both INVITEs have a References header). But this still might be considered a conflation of mechanism that have different semantics.

A Session Identifier for the Session Initiation Protocol (SIP) There are several reasons for having a globally unique session identifier for the same SIP session, which can be maintained across B2BUA's and other SIP middle-boxes. This draft proposes a new SIP header to carry such a value: Session-ID. The semantics of "Session-ID" are close to those of References, and it would be reasonable to define a "rel" value that meant that the referenced Call-Id was "the other side" of a B2BUA connection. (This would require placing a References header in the INVITE request sent from the recipient side of the B2BUA and one in the response to the INVITE send from the originator side.) But since References contains the real Call-Id of a dialog, this use would not have the security properties described in section 5.1 of . A possible solution to this problem is for the B2BUA to create a "phantom" Call-Id that is suitably random, and use it in References headers sent in both the initial request and response. By the transitivity property, the dialogs on both sides of the B2BUA are declared to be related, even if the referenced dialog contains no messages. For two chained B2BUAs with no forking, this would give a message flow like this:

INVITE 123@aa.example.com Call-Id: qwerty@aa ---> INVITE 123@transit.example.com Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=serial ---> INVITE 123@bb.example.com Call-Id: zxcvbn@bb References: QAZWSXEDCRFV ;rel=serial <--- SIP/2.0 200 OK Call-Id: zxcvbn@bb <--- SIP/2.0 200 OK Call-Id: asdfgh@transit References: QAZWSXEDCRFV;rel=serial <--- SIP/2.0 200 OK Call-Id: qwerty@aa References: QAZWSXEDCRFV;rel=serial ]]> Note that B2BUA 2 does not create a new "References serial" value, but rather reuses the value it received in the initial INVITE. (In principle, B2BUA 2 does not need to add References to the response it sends, as References is present in the request.)

The specification of the relationship between two dialogs could in principle be a privacy issue. But these relationships can usually be discerned by heuristic processing of the stream of SIP messages, and (with one exception) the author knows of no instance where the security or privacy properties of SIP have been based on the inability of an eavesdropper to determine that two SIP dialogs or messages are related. The one known privacy problem is the the "service provider privacy" problem discussed in . This situation is different from conventional "user security" situations because the eavesdropper is assumed to be unable to tap multiple points of the network, and the goal is to prevent the eavesdropper from obtaining informaiton about parts of the network that the eavesdropper cannot directly access. This sort of privacy can be provided by constructing artificial Call-Ids to use in References headers, if References is inserted in both requests and responses.

Specified that the value of the "rel" parameter is not affected by any quoting which is applied. Specified that the value of the "rel" parameter is case-sensitive. Categorize the References header as experimental.

Add the "rel" parameter. Note that References will usually appear in the dialog-forming request. Note that References may appear in a response. Add the "Related Work" section.

Initial version.