TOC 
SIPD. Worley
Internet-DraftBluesocket
Intended status: Standards TrackJuly 06, 2008
Expires: January 7, 2009 


The References Header for SIP
draft-worley-references-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 7, 2009.

Abstract

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.


Table of Contents

1.  Purpose of the References header
2.  Syntax
3.  Examples
    3.1.  REFER
    3.2.  Attended Transfer
    3.3.  Call Pickup
4.  Practical Experience
5.  Security Considerations
6.  Revision History
    6.1.  draft-worley-references-00
7.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements



 TOC 

1.  Purpose of the References header

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.

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 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.


 TOC 

2.  Syntax

The syntax of the References header is as follows. (All rules not defined here are taken from RFC 3261[sip] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).) 

message-header  =/ References
References      =  "References" HCOLON reference *(COMMA reference)
reference       =  callid *( SEMI generic-param)

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[sip] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). The ordering of References values is not significant.

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.

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.

The call-id elements of the Replaces and Join headers are considered implicit "references" and so SHOULD NOT be specified in References headers.

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.


 TOC 

3.  Examples


 TOC 

3.1.  REFER

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[service‑examples] (Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” February 2008.). 

          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    |                    |
            |------------------->|                    |
            |                    |                    |

In order to execute the blind transfer, Alice's UA sends a REFER to Bob's UA: 

      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

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: 

      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]

 TOC 

3.2.  Attended Transfer

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[service‑examples] (Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” February 2008.). 

           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   |              |
             |--------------->|              |

The INVITE that establishes the second leg has a References header naming the first leg: 

      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]

As described in Section 3.1 (REFER), the INVITE that completes the transfer has a References header giving the dialog of the first leg, within which the REFER was sent: 

      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]

 TOC 

3.3.  Call Pickup

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[service‑examples] (Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” February 2008.). 

            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     |
             |<---------------------------------|
             |                                  |

Bill's UA sends a SUBSCRIBE to find the target dialog: 

   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

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: 

   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]

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 can have a References header giving the Call-Id of the INVITE: 

   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

 TOC 

4.  Practical Experience

The current version of the sipX open-source PBX adds a References header to the SUBSCRIBE of a call pickup as described in Section 3.3 (Call Pickup). It has caused no observed interoperability problem.


 TOC 

5.  Security Considerations

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.


 TOC 

6.  Revision History


 TOC 

6.1.  draft-worley-references-00

Initial version.


 TOC 

7. Normative References

[sip] 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 (TXT).
[service-examples] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, “Session Initiation Protocol Service Examples,” I-D draft-ietf-sipping-service-examples-14, February 2008.

 TOC 

Author's Address

  Dale R. Worley
  Bluesocket, Inc.
  10 North Ave.
  Burlington, MA 01803
  US
Phone:  +1 781 229 0533 x173
Email:  dworley@pingtel.com
URI:  http://www.pingtel.com

 TOC 

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.