idnits 2.17.1
draft-ietf-sip-multiple-refer-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 21.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 577.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== It seems as if not all pages are separated by form feeds - found 0 form
feeds but 15 pages
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The REFER-Recipient SHOULD not create an implicit subscription, and
SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (January 8, 2007) is 6312 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: 'RFCXXXX' on line 458
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-uri-services-06
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-capacity-attribute-03
== Outdated reference: A later version (-15) exists of
draft-ietf-sip-gruu-11
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIP Working Group G. Camarillo
3 Internet-Draft Ericsson
4 Intended status: Standards Track A. Niemi
5 Expires: July 12, 2007 M. Isomaki
6 M. Garcia-Martin
7 Nokia
8 H. Khartabil
9 Khartabil Internet Telephony
10 Consulting
11 January 8, 2007
13 Referring to Multiple Resources in the Session Initiation Protocol (SIP)
14 draft-ietf-sip-multiple-refer-01.txt
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on July 12, 2007.
41 Copyright Notice
43 Copyright (C) The IETF Trust (2007).
45 Abstract
47 This document defines extensions to the SIP REFER method so that this
48 method can be used to refer servers to multiple resources. These
49 extensions include the use of pointers to Uniform Resource Identifier
50 (URI)-lists in the Refer-To header field and the "multiple-refer" SIP
51 option-tag.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3
58 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4
59 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4
60 6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5
61 7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 7
62 8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 7
63 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
67 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
68 12.2. Informative References . . . . . . . . . . . . . . . . . 12
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
70 Intellectual Property and Copyright Statements . . . . . . . . . . 15
72 1. Introduction
74 RFC 3261 (SIP) [5] is extended by RFC 3515 [7] with a REFER method
75 that allows a user agent to request a server to send a request to a
76 third party. Still, a number of applications need to request a
77 server to initiate transactions towards a set of destinations. In
78 one example, the moderator of a conference may want the conference
79 server to send BYE requests to a group of participants. In another
80 example, the same moderator may want the conference server to INVITE
81 a set of new participants.
83 We define an extension to the REFER method so that REFER request can
84 be used to refer servers to multiple destinations. In addition, this
85 mechanism uses the suppression of the REFER method implicit
86 subscription specified in RFC 4488 [8] to suppress REFER's implicit
87 subscription.
89 2. Terminology
91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
93 document are to be interpreted as described in BCP 14, RFC 2119 [1]
94 and indicate requirement levels for compliant implementations.
96 We define the following three new terms:
98 REFER-Issuer: the user agent issuing the REFER request.
100 REFER-Recipient: the user agent receiving the REFER request.
102 REFER-Target: the intended final recipient of the request to be
103 generated by the REFER-Recipient.
105 3. Overview of operation
107 This document defines an extension to the SIP REFER method specified
108 in RFC 3515 [7] that allows a SIP User Agent Client (UAC) to include
109 a URI-list as specified in the XML Format for Representing Resource
110 Lists [9] of REFER-Targets in a REFER request and send it to a
111 server. The server will create a new request for each entry in the
112 list of REFER-Target URIs.
114 The URI-list of REFER-Targets is used in conjunction with the XML
115 Format Extension for Representing Copy Control Attributes in Resource
116 Lists [11] to allow the sender indicate the role (e.g., 'to', 'cc',
117 or anonymous) in which the REFER-Target is involved in the
118 signalling.
120 We represent the multiple REFER-Targets of a REFER using a URI-list
121 as specified in the XML Format for Representing Resource Lists [9].
122 A UAC (User Agent Client) that wants to refer a server to a set of
123 destinations creates a SIP REFER request. The Refer-To header
124 contains a pointer to a URI-list, which is included in a body part,
125 and an option-tag in the Require header field: "multiple-refer".
126 This option-tag indicates the requirement to support the
127 functionality described in this specification.
129 When the server receives such request it creates a new request per
130 destination and sends them.
132 This document does not provide any mechanism for UACs to find out
133 about the results of a REFER with multiple REFER-Targets.
134 Furthermore, it does not provide support for the implicit
135 subscription mechanism that is part of the SIP REFER method. The way
136 UACs are kept informed about the results of a REFER is service
137 specific. For example, a UAC sending a REFER to INVITE a set of
138 participants to a conference can discover which participants were
139 successfully brought into the conference by subscribing to the
140 conference state event (RFC 4575) [12].
142 4. The multiple-refer SIP Option-Tag
144 We define a new SIP option-tag for the Require and Supported header
145 fields: "multiple-refer".
147 A user agent including the "multiple-refer" option-tag in a Supported
148 header field indicates compliance with this specification.
150 A user agent generating a REFER with a pointer to a URI-list in its
151 Refer-To header field MUST include the "multiple-refer" option-tag in
152 the Require header field of the REFER.
154 5. Suppressing REFER's Implicit Subscription
156 REFER requests with a single REFER-Target establish implicitly a
157 subscription to the refer event. The REFER-Issuer is informed about
158 the result of the transaction towards the REFER-Target through this
159 implicit subscription. As described in RFC 3515 [7], NOTIFY requests
160 sent as a result of an implicit subscription created by a REFER
161 request contain a body of type "message/sipfrag", RFC 3420 [6], that
162 describes the status of the transaction initiated by the REFER-
163 Recipient.
165 In the case of a REFER-Issuer that generates a REFER with multiple
166 REFER-targets, the REFER-Issuer is typically already subscribed to
167 other event package that can provide the information about the result
168 of the transactions towards the REFER-Targets. For example, a
169 moderator instructing a conference server to send a BYE request to a
170 set of participants is usually subscribed to the conference state
171 event package for the conference. Notifications to this event
172 package will keep the moderator and the rest of the subscribers
173 informed of the current list of conference participants.
175 Most of the applications using multiple REFER do not need its
176 implicit subscription. Consequently, a SIP REFER-Issuer generating a
177 REFER request with multiple REFER-Targets SHOULD include the
178 "norefersub" option-tag in a Require header field and SHOULD include
179 a Refer-Sub header field set to "false" to indicate that no
180 notifications about the requests should be sent to the REFER-Issuer.
181 The REFER-Recipient SHOULD honor the suggestion and also include a
182 Refer-Sub header field set to "false" in the 200 (OK) response. The
183 "norefersub" SIP option-tag and the Refer-Sub header field are
184 specified in RFC 4488 [8].
186 RFC 4488 [8] indicates that a condition for the REFER-Issuer to
187 include a Refer-Sub header is that the REFER-Issuer is sure that
188 the REFER request will not fork.
190 At the time of writing, there is no extension that allows to report
191 the status of several transactions over the implicit subscription
192 associated with a REFER dialog. That is the motivation for this
193 document to recommend the usage of the "norefersub" option-tag. If
194 in the future such an extension is defined, REFER-Issuers using it
195 could refrain from using the "norefersub" option-tag and use the new
196 extension instead.
198 6. URI-List Format
200 As described in the Framework and Security Considerations for SIP
201 URI-List Services [10], specifications of individual URI-list
202 services, need to specify a default format for 'recipient-list'
203 bodies used within the particular service.
205 The default format for 'recipient-list' bodies for conferencing UAs
206 (User Agents) and servers is the XML Formats for Representing
207 Resource Lists [9] extended with the XML Format Extension for
208 Representing Copy Control Attributes in Resource Lists [11]. REFER-
209 Recipients handling 'recipient-list' bodies MUST support both of
210 these formats and MAY support other formats.
212 As described in the XML Format Extension for Representing Copy
213 Control Attributes in Resource Lists [11], each URI can be tagged
214 with a 'copyControl' attribute set to either "to", "cc", or "bcc",
215 indicating the role in which the recipient will get the referred SIP
216 request. However, depending on the target SIP method, a
217 'copyControl' attribute lacks sense. For example, while a
218 'copyControl' attribute can be applied to INVITE requests, it does
219 not make sense with mid-dialog requests such as BYE requests.
221 In addition to the 'copyControl' attribute, URIs can be tagged with
222 the 'anonymize' attribute, also specified in the XML Format Extension
223 for Representing Copy Control Attributes in Resource Lists [11] to
224 prevent that the server discloses the target URI in a URI-list.
226 Additionally, the XML Format Extension for Representing Copy Control
227 Attributes in Resource Lists [11] defines a 'recipient-list-history'
228 body that contains the list of recipients. The default format for
229 'recipient-list-history' bodies for conference services is also the
230 XML Formats for Representing Resource Lists [9] extended with the XML
231 Format Extension for Representing Copy Control Attributes in Resource
232 Lists [11]. Conferencing servers supporting this specification MUST
233 support both of these formats; UASes MAY support these formats. Both
234 conferencing servers and UASes MAY support other formats.
236 Nevertheless, the XML Format for Representing Resource Lists [9]
237 document provides features, such as hierarchical lists and the
238 ability to include entries by reference relative to the XCAP root
239 URI, that are not needed by the multiple REFER service defined in
240 this document.
242 Figure 1 shows an example of a flat list that follows the resource
243 list document.
245
246
249
250
251
252
253
254
256 Figure 1: URI List
258 7. Behavior of SIP REFER-Issuers
260 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
261 creates a REFER request with multiple REFER-Targets includes a
262 "multiple-refer" and "norefersub" option-tags in the Require header
263 field and, if appropriate, a Refer-Sub header field set to "false".
264 The REFER-Issuer includes the set of REFER-Targets in a recipient-
265 list body whose disposition type is 'recipient-list', as defined in
266 the Framework and Security Considerations for SIP URI-List Services
267 [10]. The URI-list body is further described in Section 6.
269 The Refer-To header field of a REFER request with multiple REFER-
270 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
271 Locator (URL) as per RFC 2392 [3]) that points to the body part that
272 carries the URI-list. The REFER-Issuer SHOULD NOT include any
273 particular URI more than once in the URI-list.
275 The XML Format for Representing Resource Lists [9] document provides
276 features, such as hierarchical lists and the ability to include
277 entries by reference relative to the XCAP root URI. However, these
278 features are not needed by the multiple REFER service defined in this
279 document. Therefore, when using the default resource list document,
280 SIP REFER-Issuers generating REFER requests with multiple REFER-
281 Targets SHOULD use flat lists (i.e., no hierarchical lists) and
282 SHOULD NOT use elements.
284 8. Behavior of REFER-Recipients
286 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
287 [7] to determine the status code of the response to the REFER.
289 The REFER-Recipient SHOULD not create an implicit subscription, and
290 SHOULD add a Refer-Sub header field set to "false" in the 200 OK
291 response.
293 If the URI-list of the REFER request contains a repeated URI, the
294 REFER-Recipient MUST behave as if that URI appeared in the URI-list
295 only once. The REFER-Recipient uses the comparison rules specific to
296 the URI scheme of each of the URIs in the URI-list to determine if
297 there is any URI which appears more than once.
299 The incoming REFER request typically contains a URI-list document or
300 reference with the actual list of recipients. If this URI-list
301 includes resources tagged with the 'copyControl' attribute set to a
302 value of "to" or "cc", and if appropriate for the service, e.g., if
303 it is non-mid dialog request, the URI-list server SHOULD include a
304 URI-list in each of the outgoing requests. This list SHOULD be
305 formatted according to the XML Format for Representing Resource Lists
306 [9] and the XML Format Extension for Representing Copy Control
307 Attributes in Resource Lists [11]. The URI-list server MUST follow
308 the procedures specified in XML Format for Representing Resource
309 Lists [9] with respect handling of the 'anonymize', 'count' and
310 'copyControl' attributes.
312 If the server includes a URI-list in an outgoing request, it MUST
313 include a Content-Disposition header field, specified in RFC 2183
314 [2], with the value set to 'recipient-list-history' and a 'handling'
315 parameter, specified in RFC 3204 [4], set to "optional".
317 Since the multiple REFER service does not use hierarchical lists nor
318 lists that include entries by reference to the XCAP root URI, a
319 REFER-Recipient receiving a URI-list with more information than what
320 has been described in Section 6 MAY discard all the extra
321 information.
323 The REFER-Recipient follows the rules in RFC 3515 [7] to generate the
324 necessary requests towards the REFER-Targets, acting as if it had
325 received a regular (no URI-list) REFER per each URI in the URI-list.
327 9. Example
329 Figure 2 shows an example flow where a REFER-Issuer sends a multiple-
330 REFER request to the focus of a conference, which acts as the REFER-
331 Recipient. The REFER-Recipient generates a BYE request per REFER-
332 Target. Details for using REFER request to remove participants from
333 a conference are specified in RFC 4579 [13].
335 +--------+ +---------+ +--------+ +--------+ +--------+
336 | REFER | | REFER | | REFER | | REFER | | REFER |
337 | issuer | |recipient| |target 1| |target 2| |target 3|
338 +--------+ +---------+ +--------+ +--------+ +--------+
339 | 1. REFER | | | |
340 | ---------------->| | | |
341 | 2. 202 Accepted | | | |
342 |<---------------- | 3. BYE | | |
343 | | ----------->| | |
344 | | 4. BYE | | |
345 | | ----------------------->| |
346 | | 5. BYE | | |
347 | | ----------------------------------->|
348 | | 6. 200 OK | | |
349 | |<----------- | | |
350 | | 7. 200 OK | | |
351 | |<----------------------- | |
352 | | 8. 200K OK| | |
353 | |<----------------------------------- |
354 | | | | |
355 | | | | |
356 | | | | |
358 Figure 2: Example flow or a REFER request containin multiple REFER-
359 Targets
361 The REFER request (1) contains a Refer-To header field that includes
362 a pointer to the message body, which carries a list with the URIs of
363 the REFER-Targets. In this example, the URI-list does not contain
364 the copyControl attribute extension. The REFER's Require header
365 field carries the "multiple-refer" and "norefersub" option-tags. The
366 Request-URI is set to a Globally Routable User Agent URIs (GRUU) [14]
367 (as a guarantee that the REFER request will not fork). The Refer-Sub
368 header field is set to "false" to request the suppression of the
369 implicit subscription. Figure 3 shows an example of this REFER
370 request. The resource list document contains the list of REFER-
371 Target URIs along with the method of the SIP request that the REFER-
372 Recipient generates.
374 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
375 Via: SIP/2.0/TCP client.chicago.example.com
376 ;branch=z9hG4bKhjhs8ass83
377 Max-Forwards: 70
378 To: "Conference 123"
379 From: Carol ;tag=32331
380 Call-ID: d432fa84b4c76e66710
381 CSeq: 2 REFER
382 Contact:
383 Refer-To:
384 Refer-Sub: false
385 Require: multiple-refer, norefersub
386 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
387 Allow-Events: dialog
388 Accept: application/sdp, message/sipfrag
389 Content-Type: application/resource-lists+xml
390 Content-Disposition: recipient-list
391 Content-Length: 362
392 Content-ID:
394
395
397
398
399
400
401
402
404 Figure 3: REFER request with multiple REFER-Targets
406 Figure 4 shows an example of the BYE request (3) that the REFER-
407 Recipient sends to the first REFER-Target.
409 BYE sip:bill@example.com SIP/2.0
410 Via: SIP/2.0/TCP conference.example.com
411 ;branch=z9hG4bKhjhs8assmm
412 Max-Forwards: 70
413 From: "Conference 123" ;tag=88734
414 To: ;tag=29872
415 Call-ID: d432fa84b4c34098s812
416 CSeq: 34 BYE
417 Content-Length: 0
419 Figure 4: BYE request
421 10. Security Considerations
423 The Framework and Security Considerations for SIP URI-List Services
424 [10] discusses issues related to SIP URI-list services. Given that a
425 REFER-Recipient accepting REFER requests with multiple REFER-targets
426 acts as an URI-list service, implementations of this type of server
427 MUST follow the security-related rules in the Framework and Security
428 Considerations for SIP URI-List Services [10]. These rules include
429 mandatory authentication and authorization of clients, and opt-in
430 lists.
432 Additionally, REFER-Recipients SHOULD only accept REFER requests
433 within the context of an application the server understands (e.g., a
434 conferencing application). This implies that servers MUST NOT accept
435 REFER requests for methods they do not understand. The idea behind
436 these two rules is that servers are not used as dumb servers whose
437 only function is to fan-out random messages they do not understand.
439 11. IANA Considerations
441 This document defines a new SIP option-tag: "multiple-refer". This
442 option-tag should be registered in the SIP Parameters registry.
444 The following row shall be added to the "Option Tags" section of the
445 SIP Parameter Registry:
447 +-----------------+-------------------------------------+-----------+
448 | Name | Description | Reference |
449 +-----------------+-------------------------------------+-----------+
450 | multiple-refer | This option tag indicates support | [RFCXXXX] |
451 | | for REFER requests that contain a | |
452 | | resource list document describing | |
453 | | multiple REFER targets. | |
454 +-----------------+-------------------------------------+-----------+
456 Table 1: Registration of the 'multiple-refer' Option-Tag in SIP
458 Note to the RFC Editor: Please replace [RFCXXXX] with the RFC number
459 of this specification.
461 12. References
463 12.1. Normative References
465 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
466 Levels", BCP 14, RFC 2119, March 1997.
468 [2] Troost, R., Dorner, S., and K. Moore, "Communicating
469 Presentation Information in Internet Messages: The Content-
470 Disposition Header Field", RFC 2183, August 1997.
472 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource
473 Locators", RFC 2392, August 1998.
475 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
476 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
477 Objects", RFC 3204, December 2001.
479 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
480 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
481 Session Initiation Protocol", RFC 3261, June 2002.
483 [6] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
484 November 2002.
486 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer
487 Method", RFC 3515, April 2003.
489 [8] Levin, O., "Suppression of Session Initiation Protocol (SIP)
490 REFER Method Implicit Subscription", RFC 4488, May 2006.
492 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for
493 Representing Resource Lists",
494 draft-ietf-simple-xcap-list-usage-05 (work in progress),
495 February 2005.
497 [10] Camarillo, G. and A. Roach, "Framework and Security
498 Considerations for Session Initiation Protocol (SIP) Uniform
499 Resource Identifier (URI)-List Services",
500 draft-ietf-sipping-uri-services-06 (work in progress),
501 September 2006.
503 [11] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language
504 (XML) Format Extension for Representing Copy Control
505 Attributes in Resource Lists",
506 draft-ietf-sipping-capacity-attribute-03 (work in progress),
507 December 2006.
509 12.2. Informative References
511 [12] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
512 Initiation Protocol (SIP) Event Package for Conference State",
513 RFC 4575, August 2006.
515 [13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP)
516 Call Control - Conferencing for User Agents", BCP 119,
517 RFC 4579, August 2006.
519 [14] Rosenberg, J., "Obtaining and Using Globally Routable User
520 Agent (UA) URIs (GRUU) in the Session Initiation Protocol
521 (SIP)", draft-ietf-sip-gruu-11 (work in progress),
522 October 2006.
524 Authors' Addresses
526 Gonzalo Camarillo
527 Ericsson
528 Hirsalantie 11
529 Jorvas 02420
530 Finland
532 Email: Gonzalo.Camarillo@ericsson.com
534 Aki Niemi
535 Nokia
536 P.O. Box 321
537 NOKIA GROUP, FIN 00045
538 Finland
540 Email: Aki.Niemi@nokia.com
542 Markus Isomaki
543 Nokia
544 Itamerenkatu 11-13
545 Helsinki 00180
546 Finland
548 Email: Markus.Isomaki@nokia.com
550 Miguel A. Garcia-Martin
551 Nokia
552 P.O.Box 407
553 NOKIA GROUP, FIN 00045
554 Finland
556 Email: miguel.an.garcia@nokia.com
557 Hisham Khartabil
558 Khartabil Internet Telephony Consulting
560 Phone: +61 416 108 890
561 Email: hisham.khartabil@gmail.com
563 Full Copyright Statement
565 Copyright (C) The IETF Trust (2007).
567 This document is subject to the rights, licenses and restrictions
568 contained in BCP 78, and except as set forth therein, the authors
569 retain all their rights.
571 This document and the information contained herein are provided on an
572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
575 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
576 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
579 Intellectual Property
581 The IETF takes no position regarding the validity or scope of any
582 Intellectual Property Rights or other rights that might be claimed to
583 pertain to the implementation or use of the technology described in
584 this document or the extent to which any license under such rights
585 might or might not be available; nor does it represent that it has
586 made any independent effort to identify any such rights. Information
587 on the procedures with respect to rights in RFC documents can be
588 found in BCP 78 and BCP 79.
590 Copies of IPR disclosures made to the IETF Secretariat and any
591 assurances of licenses to be made available, or the result of an
592 attempt made to obtain a general license or permission for the use of
593 such proprietary rights by implementers or users of this
594 specification can be obtained from the IETF on-line IPR repository at
595 http://www.ietf.org/ipr.
597 The IETF invites any interested party to bring to its attention any
598 copyrights, patents or patent applications, or other proprietary
599 rights that may cover technology that may be required to implement
600 this standard. Please address the information to the IETF at
601 ietf-ipr@ietf.org.
603 Acknowledgment
605 Funding for the RFC Editor function is provided by the IETF
606 Administrative Support Activity (IASA).