The References Header for SIP
Avaya Inc.
600 Technology Park Dr.BillericaMA01821US+1 978 288 5505dworley@avaya.comhttp://www.avaya.com
Transport
SIP
This document defines a SIP extension header, References, to be used
within SIP messages to signify that the message (and the
dialog containing it) is related to one or more other dialogs.
It is expected to be used largely for diagnostic purposes.
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 values of the Replaces and Join headers are considered
implicit References values and so SHOULD NOT be specified in
References headers.
Similarly to the grammar for the Call-ID header, no escaping is
defined for the call-id value in the References header.
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,
each relationship nature defined below implicitly defines a reverse
relationship, whose "rel" parameter value is prefixed with "-".
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:
"chain"
meaning that this request is the logical continuation of the dialog with the
specified Call-Id through a B2BUA or the like, in that it will carry
media that have the same meaning to the user
"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.)
"join" - this value is permanently reserved so that it may be used as a value of
cognate data items when describing dialogs related by a "Join" header
"refer"
meaning that this request was generated due to a REFER with the
specified Call-Id
"replaces" - this value is permanently reserved so that it may be used as a value of
cognate data items when describing dialogs related by a "Replaces" header
"service"
means that this dialog is to obtain "service media" for use by the dialog
with the specified Call-Id. "Service media" includes music-on-hold,
alert tones, and the like.
"sequel"
means that this dialog is the continuation of the conversation carried
by the dialog with the specified Call-Id
"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).
The processor of the References header MUST remove any quoting from
the "rel" parameter value before processing it.
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 the following are all equivalent:
References: 12345600@atlanta.example.com;rel=xfer
References: 12345600@atlanta.example.com;rel="xfer"
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 element.
The semantics of some "rel" values (e.g., "chain" and "xfer") are
inherently symmetric; in these cases the "reverse" value, prefixed
with "-" is still valid, and the processor of the References
header SHOULD treat the base relationship and the reverse
relationship identically.
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.
This implies that rel-values that start with "-X-" (case-insensitive)
are similarly reserved.
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 the two "sides" of a single
logical dialog that
passes through a B2BUA (which might not have the same Call-Id).
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
.
In order to execute the blind transfer, Alice's UA sends a REFER to Bob's UA:
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:
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
.
The INVITE that establishes the second leg has a References header
naming the first leg:
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.
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
.
Bill's UA sends a SUBSCRIBE to find the target dialog:
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, using the rel-value "-inquiry":
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:
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:
Note that B2BUA 2 does not create a new "References chain" 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 information 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.
Refresh of expired Internet-Draft.
Updated author's contact information.
Added the "rel=service" value.
Added the convention of naming the reversed relationships by prefixing
the rel-value with "-".
Added the "rel=chain" and "rel=sequel" values.
Reserved the "rel=replaces" and "rel=join" values.
Added B2BUA example for "rel=chain".
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.
SIP: Session Initiation ProtocolSession Initiation Protocol Service ExamplesInternet Message FormatThe Session Initiation Protocol (SIP) Dialog CorrelationA Session Identifier for the Session Initiation Protocol (SIP)