draft-ietf-sipping-multiple-refer-02.txt   draft-ietf-sipping-multiple-refer-03.txt 
SIPPING Working Group G. Camarillo SIPPING Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: May 2, 2005 A. Niemi Expires: August 27, 2005 A. Niemi
M. Isomaki M. Isomaki
M. Garcia-Martin M. Garcia-Martin
Nokia Nokia
H. Khartabil H. Khartabil
Telio Telio
November 2004 February 23, 2005
Refering to Multiple Resources in the Session Initiation Protocol Refering to Multiple Resources in the Session Initiation Protocol (SIP)
(SIP) draft-ietf-sipping-multiple-refer-03.txt
draft-ietf-sipping-multiple-refer-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 2, 2005. This Internet-Draft will expire on August 27, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines extensions to the SIP REFER method so that this This document defines extensions to the SIP REFER method so that this
method can be used to refer servers to multiple resources. These method can be used to refer servers to multiple resources. These
extensions include the use of pointers to Uniform Resource Identifier extensions include the use of pointers to Uniform Resource Identifier
(URI)-lists in the Refer-To header field and the "multiple-refer" SIP (URI)-lists in the Refer-To header field and the "multiple-refer" SIP
option-tag. option-tag.
Table of Contents Table of Contents
skipping to change at page 2, line 23 skipping to change at page 2, line 21
3. Overview of operation . . . . . . . . . . . . . . . . . . . 3 3. Overview of operation . . . . . . . . . . . . . . . . . . . 3
4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . 4 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . 4
5. Suppressing REFER's Implicit Subscription . . . . . . . . . 4 5. Suppressing REFER's Implicit Subscription . . . . . . . . . 4
6. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . 5 6. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . 5
7. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . 5 7. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . 5
8. Default URI-List Format . . . . . . . . . . . . . . . . . . 5 8. Default URI-List Format . . . . . . . . . . . . . . . . . . 5
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Security Considerations . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1 Normative References . . . . . . . . . . . . . . . . . . . 9 12.1 Normative References . . . . . . . . . . . . . . . . . . 9
12.2 Informational References . . . . . . . . . . . . . . . . . 10 12.2 Informational References . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 12
1. Introduction 1. Introduction
The SIP [3] REFER method [5] allows a user agent to request a server The SIP [3] REFER method [5] allows a user agent to request a server
to send a request to a third party. Still, a number of applications to send a request to a third party. Still, a number of applications
need to request a server to initiate transactions towards a set of need to request a server to initiate transactions towards a set of
destinations. In one example, the moderator of a conference may want destinations. In one example, the moderator of a conference may want
the conference server to send BYE requests to a group of the conference server to send BYE requests to a group of
skipping to change at page 3, line 38 skipping to change at page 3, line 38
We define the following three new terms: We define the following three new terms:
REFER-Issuer: the user agent issuing the REFER request. REFER-Issuer: the user agent issuing the REFER request.
REFER-Recipient: the user agent receiving the REFER request. REFER-Recipient: the user agent receiving the REFER request.
REFER-Target: the intended final recipient of the request to be REFER-Target: the intended final recipient of the request to be
generated by the REFER-Recipient. generated by the REFER-Recipient.
3. Overview of operation 3. Overview of operation
This document defines an extension to the SIP REFER method [5] that This document defines an extension to the SIP REFER method [5] that
allows a SIP User Agent Client (UAC) to include a list of allows a SIP User Agent Client (UAC) to include a list of REFER-
REFER-Targets in a REFER request and send it to a server. The server Targets in a REFER request and send it to a server. The server will
will create a new request for each entry in the list of REFER-Target create a new request for each entry in the list of REFER-Target URIs.
URIs.
We represent the multiple REFER-Targets of a REFER using a URI-list. We represent the multiple REFER-Targets of a REFER using a URI-list.
A UAC (User Agent Client) that wants to refer a server to a set of A UAC (User Agent Client) that wants to refer a server to a set of
destinations creates a SIP REFER request. The Refer-To header destinations creates a SIP REFER request. The Refer-To header
contains a pointer to a URI-list, which is included in a body part, contains a pointer to a URI-list, which is included in a body part,
and an option-tag in the Required header field: "multiple-refer". and an option-tag in the Required header field: "multiple-refer".
This option-tag indicates the requirement to support the This option-tag indicates the requirement to support the
functionality described in this specification. functionality described in this specification.
When the server receives such request it creates a new request per When the server receives such request it creates a new request per
skipping to change at page 5, line 20 skipping to change at page 5, line 20
extension is defined, REFER-Issuers using it could refrain from using extension is defined, REFER-Issuers using it could refrain from using
the "norefersub" option-tag and use the new extension instead. the "norefersub" option-tag and use the new extension instead.
6. Behavior of SIP REFER-Issuers 6. Behavior of SIP REFER-Issuers
As indicated in Section 4 and Section 5 a SIP REFER-Issuer that As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
creates a REFER request with multiple REFER-Targets includes a creates a REFER request with multiple REFER-Targets includes a
"multiple-refer" and a "norefersub" option-tags in the Require header "multiple-refer" and a "norefersub" option-tags in the Require header
field. field.
The Refer-To header field of a REFER request with multiple The Refer-To header field of a REFER request with multiple REFER-
REFER-Targets MUST contain a pointer (i.e., a Content-ID Uniform Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
Resource Locator (URL) [2]) that points to the body part that carries Locator (URL) [2]) that points to the body part that carries the URI-
the URI-list. The REFER-Issuer SHOULD NOT include any particular URI list. The REFER-Issuer SHOULD NOT include any particular URI more
more than once in the URI-list. than once in the URI-list.
7. Behavior of REFER-Recipients 7. Behavior of REFER-Recipients
The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
[5] to determine the status code of the response to the REFER. [5] to determine the status code of the response to the REFER.
If the URI-list contains a URI more than once, the REFER-Recipient If the URI-list contains a URI more than once, the REFER-Recipient
MUST behave as if that URI appeared in the URI-list only once. The MUST behave as if that URI appeared in the URI-list only once. The
REFER-Recipient uses the comparison rules specific to the URI scheme REFER-Recipient uses the comparison rules specific to the URI scheme
of each of the URIs in the URI-list to determine if there is any URI of each of the URIs in the URI-list to determine if there is any URI
skipping to change at page 6, line 30 skipping to change at page 6, line 30
<entry uri="sip:bill@example.com" /> <entry uri="sip:bill@example.com" />
<entry uri="sip:joe@example.org" /> <entry uri="sip:joe@example.org" />
<entry uri="sip:ted@example.net" /> <entry uri="sip:ted@example.net" />
</list> </list>
</resource-lists> </resource-lists>
Figure 1: URI List Figure 1: URI List
9. Example 9. Example
Figure 2 shows an example flow where a REFER-Issuer sends a Figure 2 shows an example flow where a REFER-Issuer sends a multiple-
multiple-REFER request to the focus of a conference, which acts as REFER request to the focus of a conference, which acts as the REFER-
the REFER-Recipient. The REFER-Recipient generates a BYE request per Recipient. The REFER-Recipient generates a BYE request per REFER-
REFER-Target. (How to use REFER to remove participants from a Target. (How to use REFER to remove participants from a conference
conference is specified in [10].) is specified in [10].)
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER | | REFER |
| issuer | |recipient| |target 1| |target 2| |target 3| | issuer | |recipient| |target 1| |target 2| |target 3|
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| 1. REFER | | | | | 1. REFER | | | |
| ---------------->| | | | | ---------------->| | | |
| 2. 202 Accepted | | | | | 2. 202 Accepted | | | |
|<---------------- | 3. BYE | | | |<---------------- | 3. BYE | | |
| | ------------->| | | | | ----------->| | |
| | 4. BYE | | | | | 4. BYE | | |
| | ------------------------->| | | | ----------------------->| |
| | 5. BYE | | | | | 5. BYE | | |
| | ------------------------------------->| | | ----------------------------------->|
| | 6. 200 OK | | | | | 6. 200 OK | | |
| |<------------- | | | | |<----------- | | |
| | 7. 200 OK | | | | | 7. 200 OK | | |
| |<------------------------- | | | |<----------------------- | |
| | 8. 200 OK | | | | | 8. 200K OK| | |
| |<------------------------------------- | | |<----------------------------------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 2: Example flow or a REFER request containin multiple Figure 2: Example flow or a REFER request containin multiple REFER-
REFER-Targets Targets
The REFER request (1) contains a Refer-To header field that includes The REFER request (1) contains a Refer-To header field that includes
a pointer to the message body, which carries a list with the URIs of a pointer to the message body, which carries a list with the URIs of
the REFER-Targets. The REFER's Require header field carries both the the REFER-Targets. The REFER's Require header field carries both the
"multiple-refer" and the "norefersub" option-tags. Figure 3 shows an "multiple-refer" and the "norefersub" option-tags. Figure 3 shows an
example of this REFER request. The resource list document contains example of this REFER request. The resource list document contains
the list of REFER-Target URIs along with the method of the SIP the list of REFER-Target URIs along with the method of the SIP
request that the REFER-Recipient generates. request that the REFER-Recipient generates.
REFER sip:conf-123@example.com SIP/2.0 REFER sip:conf-123@example.com SIP/2.0
skipping to change at page 8, line 36 skipping to change at page 8, line 36
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com?method=BYE" /> <entry uri="sip:bill@example.com?method=BYE" />
<entry uri="sip:joe@example.org?method=BYE" /> <entry uri="sip:joe@example.org?method=BYE" />
<entry uri="sip:ted@example.net?method=BYE" /> <entry uri="sip:ted@example.net?method=BYE" />
</list> </list>
</resource-lists> </resource-lists>
Figure 3: REFER request with multiple REFER-Targets Figure 3: REFER request with multiple REFER-Targets
Figure 4 shows an example of the BYE request (3) that the Figure 4 shows an example of the BYE request (3) that the REFER-
REFER-Recipient sends to the first REFER-Target. Recipient sends to the first REFER-Target.
REFER sip:bill@example.com SIP/2.0 BYE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP conference.example.com Via: SIP/2.0/TCP conference.example.com
;branch=z9hG4bKhjhs8assmm ;branch=z9hG4bKhjhs8assmm
Max-Forwards: 70 Max-Forwards: 70
From: "Conference 123" <sip:conf-123@example.com>;tag=88734 From: "Conference 123" <sip:conf-123@example.com>;tag=88734
To: <sip:bill@example.com>;tag=29872 To: <sip:bill@example.com>;tag=29872
Call-ID: d432fa84b4c34098s812 Call-ID: d432fa84b4c34098s812
CSeq: 34 BYE CSeq: 34 BYE
Content-Length: 0 Content-Length: 0
Figure 4: BYE request Figure 4: BYE request
10. Security Considerations 10. Security Considerations
The Framework and Security Considerations for SIP URI-List Services The Framework and Security Considerations for SIP URI-List Services
[8] discusses issues related to SIP URI-list services. Given that a [8] discusses issues related to SIP URI-list services. Given that a
server accepting REFERs with multiple REFER-targets acts as an server accepting REFERs with multiple REFER-targets acts as an URI-
URI-list service, implementations of this type of server MUST follow list service, implementations of this type of server MUST follow the
the security-related rules in [8]. These rules include mandatory security-related rules in [8]. These rules include mandatory
authentication and authorization of clients, and opt-in lists. authentication and authorization of clients, and opt-in lists.
Additionally, servers SHOULD only accept REFER requests within the Additionally, servers SHOULD only accept REFER requests within the
context of an application the server understands (e.g., a context of an application the server understands (e.g., a
conferencing application). This implies that servers MUST NOT accept conferencing application). This implies that servers MUST NOT accept
REFERs for methods they do not understand. The idea behind these two REFERs for methods they do not understand. The idea behind these two
rules is that servers are not used as dumb servers whose only rules is that servers are not used as dumb servers whose only
function is to fan-out random messages they do not understand. function is to fan-out random messages they do not understand.
11. IANA Considerations 11. IANA Considerations
skipping to change at page 10, line 6 skipping to change at page 9, line 41
12.1 Normative References 12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Levinson, E., "Content-ID and Message-ID Uniform Resource [2] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002. November 2002.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[6] Rosenberg, J., "Extensible Markup Language (XML) Formats for [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-04 (work in progress), October draft-ietf-simple-xcap-list-usage-05 (work in progress),
2004. February 2005.
[7] Olson, S., "REFER extensions", [7] Levin, O., "Suppression of Session Initiation Protocol REFER
draft-olson-sipping-refer-extensions-02 (work in progress), July Method Implicit Subscription",
2004. draft-ietf-sip-refer-with-norefersub-01 (work in progress),
February 2005.
[8] Camarillo, G., "Requirements and Framework for Session [8] Camarillo, G. and A. Roach, "Requirements and Framework for
Initiation Protocol (SIP)Uniform Resource Identifier (URI)-List Session Initiation Protocol (SIP)Uniform Resource Identifier
Services", draft-ietf-sipping-uri-services-01 (work in (URI)-List Services", draft-ietf-sipping-uri-services-02 (work
progress), October 2004. in progress), December 2004.
12.2 Informational References 12.2 Informational References
[9] Rosenberg, J. and H. Schulzrinne, "A Session Initiation [9] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Protocol (SIP) Event Package for Conference State", Package for Conference State",
draft-ietf-sipping-conference-package-06 (work in progress), draft-ietf-sipping-conference-package-10 (work in progress),
October 2004. March 2005.
[10] Johnston, A. and O. Levin, "Session Initiation Protocol Call [10] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-05 (work in progress), draft-ietf-sipping-cc-conferencing-06 (work in progress),
October 2004. November 2004.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Aki Niemi Aki Niemi
Nokia Nokia
P.O. Box 321 P.O. Box 321
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
EMail: Aki.Niemi@nokia.com Email: Aki.Niemi@nokia.com
Markus Isomaki Markus Isomaki
Nokia Nokia
Itamerenkatu 11-13 Itamerenkatu 11-13
Helsinki 00180 Helsinki 00180
Finland Finland
EMail: Markus.Isomaki@nokia.com Email: Markus.Isomaki@nokia.com
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia
P.O.Box 407 P.O.Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
EMail: miguel.an.garcia@nokia.com Email: miguel.an.garcia@nokia.com
Hisham Khartabil Hisham Khartabil
Telio Telio
P.O. Box 1203 P.O. Box 1203
Olso 0110 Oslo 0110
Norway Norway
EMail: Hisham.Khartabil@telio.no Email: Hisham.Khartabil@telio.no
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 12, line 41 skipping to change at page 12, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/