One document matched: draft-worley-references-00.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc ipr='full3978' category='std' docName='draft-worley-references-00'>
<front>
<title abbrev='SIP References header'>
The References Header for SIP
</title>
<author initials='D.R.' surname='Worley' fullname='Dale R. Worley'>
<organization abbrev='Bluesocket'>
Bluesocket, Inc.
</organization>
<address>
<postal>
<street>10 North Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>US</country>
</postal>
<phone>+1 781 229 0533 x173</phone>
<email>dworley@pingtel.com</email>
<uri>http://www.pingtel.com</uri>
</address>
</author>
<date month='July' year='2008' />
<area>Transport</area>
<workgroup>SIP</workgroup>
<keyword></keyword>
<abstract>
<t>
This document defines a SIP extension header, References, to be used
within SIP messages to signify that the message (and by extension, the
dialog containing it) is related to one or more other dialogs.
It is expected to be used largely for diagnostic purposes.
</t>
</abstract>
</front>
<middle>
<section title='Purpose of the References header' anchor='purpose'>
<t>
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 operation.
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
The current definition of the References header does not provide for
specifying the nature of the relationship between the dialogs.
Determining the nature of the relationship is expected to be done by a
human observer or a heuristic algorithm.
</t>
</section>
<section title='Syntax' anchor='syntax'>
<t>
The syntax of the References header is as follows.
(All rules not defined here are taken from
RFC 3261<xref target='sip'/>.)
</t>
<figure align='left'>
<artwork align='center' type='abnf'><![CDATA[
message-header =/ References
References = "References" HCOLON reference *(COMMA reference)
reference = callid *( SEMI generic-param)
]]></artwork>
</figure>
<t>
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<xref target='sip'/>.
The ordering of References values is not significant.
</t>
<t>
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).
The exact nature of the relationship is not specified.
Note that since there is no way to specify a to-tag and from-tag, the
References header does not distinguish different dialogs that have the
same Call-Id.
</t>
<t>
Currently, no parameters have defined meanings.
All parameters that are not understood by the processor of the
References header should be ignored.
Parameters whose names start with "X-" (case-insensitive) are reserved
for non-standardized purposes.
</t>
<t>
The call-id elements of the Replaces and Join headers are considered
implicit "references" and so SHOULD NOT be specified in
References headers.
</t>
<t>
Note that while the SIP References header is similar in function to
the SMTP References header, they have a different syntax and are not
interchangeable.
</t>
</section>
<section title='Examples' anchor='examples'>
<section title='REFER' anchor='refer'>
<t>
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
draft-ietf-sipping-service-examples-14<xref target='service-examples'/>.
</t>
<figure align='left'>
<artwork><![CDATA[
Alice Bob Carol
| INVITE F1 | |
|<-------------------| |
| 180 Ringing F2 | |
|------------------->| |
| 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 | |
|------------------->| |
| | |
]]></artwork>
</figure>
<t>
In order to execute the blind transfer, Alice's UA sends a REFER to Bob's UA:
</t>
<figure align='left'>
<artwork><![CDATA[
F5 REFER Alice -> 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 <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=314159
Call-ID: 12345601@atlanta.example.com
CSeq: 101 REFER
Refer-To: <sips:carol@chicago.example.com>
Referred-By: <alice@atlanta.example.com>
Contact: <sips:alice@client.atlanta.example.com>
Content-Length: 0
]]></artwork>
</figure>
<t>
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:
</t>
<figure align='left'>
<artwork><![CDATA[
F11 INVITE Bob -> Carol
INVITE sips:carol@chicago.example.com SIP/2.0
References: 12345601@atlanta.example.com
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds1
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=8675309
To: Carol <sips:carol@chicago.example.com>
Call-ID: 7436222@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@client.biloxi.example.com>
Referred-By: <alice@atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
]]></artwork>
</figure>
</section>
<section title='Attended Transfer' anchor='transfer'>
<t>
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 and Replaces headers 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 of
draft-ietf-sipping-service-examples-14<xref target='service-examples'/>.
</t>
<figure align='left'>
<artwork><![CDATA[
Alice Bob Carol
| | |
| INVITE F1 | |
|--------------->| |
| 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 | |
|--------------->| |
]]></artwork>
</figure>
<t>
The INVITE that establishes the second leg has a References header
naming the first leg:
</t>
<figure align='left'>
<artwork><![CDATA[
F8 INVITE Bob -> Carol
INVITE sips:carol@chicago.example.com SIP/2.0
References: 12345600@atlanta.example.com
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnash
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=8675309
To: Carol <sips:carol@chicago.example.com>
Call-ID: sdjfdjfskdf@biloxi.example.com
CSeq: 42 INVITE
Contact: <sips:bob@client.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
]]></artwork>
</figure>
<t>
As described in <xref target='refer'/>, the INVITE that completes the
transfer has a References header giving the dialog of the first leg,
within which the REFER was sent:
</t>
<figure align='left'>
<artwork><![CDATA[
F19 INVITE Alice -> Carol
INVITE sips:39itp34klkd@chicago.example.com;gr SIP/2.0
References: 12345600@atlanta.example.com
Via: SIP/2.0/TLS chicago.example.com:5061
;branch=z9hG4bKadfe4ko
To: Carol <sips:39itp34klkd@chicago.example.com>
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=3461
Call-ID: 9435674543@atlanta.example.com
CSeq: 1 INVITE
Require: replaces
Referred-By: <sips:bob@biloxi.example.com>
Replaces: sdjfdjfskdf@biloxi.example.com
;to-tag=5f35a3;from-tag=8675309
Contact: <sips:alice@client.atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
]]></artwork>
</figure>
</section>
<section title='Call Pickup' anchor='pickup'>
<t>
References 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 of
draft-ietf-sipping-service-examples-14<xref target='service-examples'/>.
</t>
<figure align='left'>
<artwork><![CDATA[
Alice Bob Bill
| | |
| INVITE F1 | |
|------------->| |
|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 |
|<---------------------------------|
| |
]]></artwork>
</figure>
<t>
Bill's UA sends a SUBSCRIBE to find the target dialog:
</t>
<figure align='left'>
<artwork><![CDATA[
F3 SUBSCRIBE Bill -> 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 <sips:bill@biloxi.example.com>;tag=8675309
To: Bob <sips:bob@biloxi.example.com>
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 SUBSCRIBE
Contact: <sips:bill@pc.biloxi.example.com>
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Content-Length: 0
]]></artwork>
</figure>
<t>
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:
</t>
<figure align='left'>
<artwork><![CDATA[
F7 INVITE Bill -> Alice
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
References: rt4353gs2egg@pc.biloxi.example.com
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74HH
Max-Forwards: 70
From: Bill <sips:bill@biloxi.example.com>;tag=8675310
To: Alice <sips:alice@atlanta.example.com>
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: <sips:bill@pc.biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
[SDP omitted]
]]></artwork>
</figure>
<t>
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.
</t>
<t>
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 can have a References header giving the
Call-Id of the INVITE:
</t>
<figure align='left'>
<artwork><![CDATA[
F3 SUBSCRIBE Bill -> Bob
SUBSCRIBE sips:bob@biloxi.example.com SIP/2.0
References: 563456212@b2.biloxi.example.com
Via: SIP/2.0/TLS pc.biloxi.example.com:5061
;branch=z9hG4bK74bf
Max-Forwards: 70
From: Bill <sips:bill@biloxi.example.com>;tag=8675309
To: Bob <sips:bob@biloxi.example.com>
Call-ID: rt4353gs2egg@pc.biloxi.example.com
CSeq: 1 SUBSCRIBE
Contact: <sips:bill@pc.biloxi.example.com>
Event: dialog
Expires: 0
Accept: application/dialog-info+xml
Content-Length: 0
]]></artwork>
</figure>
</section>
</section>
<section title='Practical Experience' anchor='experience'>
<t>
The current version of the sipX open-source PBX adds a References
header to the SUBSCRIBE of a call pickup as described in
<xref target='pickup'/>.
It has caused no observed interoperability problem.
</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>
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 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.
</t>
</section>
<section title='Revision History' anchor='revision'>
<section title='draft-worley-references-00' anchor='00'>
<t>
Initial version.
</t>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='sip'>
<!-- RFC 3261 -->
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg'><organization/></author>
<author initials='H.' surname='Schulzrinne'><organization/></author>
<author initials='G.' surname='Camarillo'><organization/></author>
<author initials='A.' surname='Johnston'><organization/></author>
<author initials='J.' surname='Peterson'><organization/></author>
<author initials='R.' surname='Sparks'><organization/></author>
<author initials='M.' surname='Handley'><organization/></author>
<author initials='E.' surname='Schooler'><organization/></author>
<date month='June' year='2002'/>
</front>
<seriesInfo name='RFC' value='3261' />
<format type='TXT'
target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>
<reference anchor='service-examples'>
<!-- draft-ietf-sipping-service-examples-14 -->
<front>
<title>Session Initiation Protocol Service Examples</title>
<author initials='A.' surname='Johnston'><organization/></author>
<author initials='R.' surname='Sparks'><organization/></author>
<author initials='C.' surname='Cunningham'><organization/></author>
<author initials='S.' surname='Donovan'><organization/></author>
<author initials='K.' surname='Summers'><organization/></author>
<date month='February' year='2008'/>
</front>
<seriesInfo name='I-D' value='draft-ietf-sipping-service-examples-14' />
<format type='TXT'
target='http://tools.ietf.org/html/draft-ietf-sipping-service-examples-14' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:09 |