draft-ietf-sipping-transc-conf-03.txt   rfc5370.txt 
SIPPING Working Group G. Camarillo
Internet-Draft Ericsson
Expires: November 23, 2006 May 22, 2006
The Session Initiation Protocol (SIP) Conference Bridge Transcoding
Model
draft-ietf-sipping-transc-conf-03.txt
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 Network Working Group G. Camarillo
Task Force (IETF), its areas, and its working groups. Note that Request for Comments: 5370 Ericsson
other groups may also distribute working documents as Internet- Category: Standards Track October 2008
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 November 23, 2006. The Session Initiation Protocol (SIP)
Conference Bridge Transcoding Model
Copyright Notice Status of This Memo
Copyright (C) The Internet Society (2006). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document describes how to invoke transcoding services using the This document describes how to invoke transcoding services using the
conference bridge model. This way of invocation meets the conference bridge model. This way of invocation meets the
requirements for SIP regarding transcoding services invocation to requirements for SIP regarding transcoding services invocation to
support deaf, hard of hearing and speech-impaired individuals. support deaf, hard of hearing, and speech-impaired individuals.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. Caller's Invocation . . . . . . . . . . . . . . . . . . . . . 4 3. Caller's Invocation .............................................3
3.1. Procedures at the User Agent . . . . . . . . . . . . . . . 4 3.1. Procedures at the User Agent ...............................3
3.2. Procedures at the Transcoder . . . . . . . . . . . . . . . 4 3.2. Procedures at the Transcoder ...............................3
3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Example ....................................................4
3.4. Unsuccessful Session Establishment . . . . . . . . . . . . 7 3.4. Unsuccessful Session Establishment .........................6
4. Callee's Invocation . . . . . . . . . . . . . . . . . . . . . 8 4. Callee's Invocation .............................................7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations .........................................7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors ....................................................8
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References ......................................................8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References .......................................8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References .....................................9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
The Framework for Transcoding with SIP [8] describes how two SIP [3] RFC 5369 [RFC5369] describes how two SIP [RFC3261] UAs (User Agents)
UAs (User Agents) can discover imcompatibilities that prevent them can discover incompatibilities that prevent them from establishing a
from establishing a session (e.g., lack of support for a common codec session (e.g., lack of support for a common codec or for a common
or for a common media type). When such incompatibilities are found, media type). When such incompatibilities are found, the UAs need to
the UAs need to invoke transcoding services to successfully establish invoke transcoding services to successfully establish the session.
the session. The transcoding framework introduces two models to The transcoding framework introduces two models to invoke transcoding
invoke transcoding services: the 3pcc (third-party call control) services: the 3pcc (third-party call control) model [RFC4117] and the
model [7] and the conference bridge model. This document specifies conference bridge model. This document specifies the conference
the conference bridge model. bridge model.
In the conference bridge model for transcoding invocation, a In the conference bridge model for transcoding invocation, a
transcoding server that provides a particular transcoding service transcoding server that provides a particular transcoding service
(e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent) (e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent)
between both UAs and is identified by a URI. As shown in Figure 1, between both UAs and is identified by a URI. As shown in Figure 1,
both UAs, A and B, exchange signalling and media with the transcoder both UAs, A and B, exchange signalling and media with the transcoder
T. The UAs do not exchange any traffic (signalling or media) directly T. The UAs do not exchange any traffic (signalling or media)
between them. directly between them.
+-------+ +-------+
| |** | |**
| T | ** | T | **
| |\ ** | |\ **
+-------+ \\ ** +-------+ \\ **
^ * \\ ** ^ * \\ **
| * \\ ** | * \\ **
| * SIP ** | * SIP **
SIP * \\ ** SIP * \\ **
skipping to change at page 3, line 48 skipping to change at page 2, line 48
| | | | | | | |
| A | | B | | A | | B |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
<-SIP-> Signalling <-SIP-> Signalling
******* Media ******* Media
Figure 1: Conference bridge model Figure 1: Conference bridge model
Section 3 and Section 4 specify how the caller A or the callee B, Sections 3 and 4 specify how the caller A or the callee B,
respectively, can use the conference bridge model to invoke respectively, can use the conference bridge model to invoke
transcoding services from T. transcoding services from T.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [RFC2119], and indicate requirement
compliant implementations. levels for compliant implementations.
3. Caller's Invocation 3. Caller's Invocation
User agent A needs to perform two operations to invoke transcoding User agent A needs to perform two operations to invoke transcoding
services from T for a session between user agent A and user agent B. services from T for a session between user agent A and user agent B.
User agent A needs to establish a session with T and provide T with User agent A needs to establish a session with T and provide T with
user agent B's URI so that T can generate an INVITE towards user user agent B's URI so that T can generate an INVITE towards user
agent B. agent B.
3.1. Procedures at the User Agent 3.1. Procedures at the User Agent
User agent A uses the procedures for Conference Establishment Using User agent A uses the procedures for RFC 5366 [RFC5366] to provide T
Request-Contained Lists in SIP [10] to provide T with B's URI using with B's URI using the same INVITE that establishes the session
the same INVITE that establishes the session between A and T. That between A and T. That is, user agent A adds to the INVITE a body
is, user agent A adds to the INVITE a body part whose disposition part whose disposition type is recipient-list [RFC5363]. This body
type is recipient-list [9]. This body part consists of a URI-list part consists of a URI-list that contains a single URI: user agent
that contains a single URI: user agent B's URI. B's URI.
Note that, as described in the transcoding framework [8], the Note that, as described in the transcoding framework [RFC5369],
transcoding model described in this document is modeled as a two- the transcoding model described in this document is modeled as a
party conference server. Consequently, this document focuses on two-party conference server. Consequently, this document focuses
two-party sessions that need transcoding. Multi-party sessions on two-party sessions that need transcoding. Multi-party sessions
can be established using INVITE requests with multiple URIs in can be established using INVITE requests with multiple URIs in
their bodies, as specified in [10]. their bodies, as specified in [RFC5366].
3.2. Procedures at the Transcoder 3.2. Procedures at the Transcoder
On receiving an INVITE with a URI-list body, the transcoder follows On receiving an INVITE with a URI-list body, the transcoder follows
the procedures in [10] to generate an INVITE request towards the URI the procedures in [RFC5366] to generate an INVITE request towards the
contained in the URI-list body. Note that the transcoder acts as a URI contained in the URI-list body. Note that the transcoder acts as
B2BUA, not as a proxy. a B2BUA, not as a proxy.
Additionally, the transcoder MUST generate the From header field of Additionally, the transcoder MUST generate the From header field of
the outgoing INVITE request using the same value as the From header the outgoing INVITE request using the same value as the From header
field included in the incoming INVITE request, subject to the privacy field included in the incoming INVITE request, subject to the privacy
requirements (see [4] and [5]) expressed in the incoming INVITE requirements (see [RFC3323] and [RFC3325]) expressed in the incoming
request. Note that this does not apply to the "tag" parameter. INVITE request. Note that this does not apply to the "tag"
parameter.
The session description the transcoder includes in the outgoing The session description the transcoder includes in the outgoing
INVITE request depends on the type of transcoding service that INVITE request depends on the type of transcoding service that
particular transcoder provides. For example, a transcoder resolving particular transcoder provides. For example, a transcoder resolving
audio codec incompatibilities would generate a session description audio codec incompatibilities would generate a session description
listing the audio codecs the transcoder supports. listing the audio codecs the transcoder supports.
When the transcoder receives a final response for the outgoing INVITE When the transcoder receives a final response for the outgoing INVITE
requests, it generates a new final response for the incoming INVITE requests, it generates a new final response for the incoming INVITE
request. This new final response SHOULD have the same status code as request. This new final response SHOULD have the same status code as
the one received in the response for the outgoing INVITE request. the one received in the response for the outgoing INVITE request.
If a trancoder receives an INVITE request with a URI-list with more If a transcoder receives an INVITE request with a URI-list with more
than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list) than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list)
response. response.
3.3. Example 3.3. Example
Figure 2 shows the message flow for the caller's invocation of a Figure 2 shows the message flow for the caller's invocation of a
transcoder T. The caller A sends an INVITE (1) to the transcoder (T) transcoder T. The caller A sends an INVITE (1) to the transcoder (T)
to establish the session A-T. Following the procedures in [10], the to establish the session A-T. Following the procedures in [RFC5366],
caller A adds a body part whose disposition type is recipient-list the caller A adds a body part whose disposition type is recipient-
[9]. list [RFC5363].
A T B A T B
| | | | | |
|-----(1) INVITE SDP A----->| | |-----(1) INVITE SDP A----->| |
| | | | | |
|<-(2) 183 Session Progress-| | |<-(2) 183 Session Progress-| |
| |-----(3) INVITE SDP TB---->| | |-----(3) INVITE SDP TB---->|
| | | | | |
| |<-----(4) 200 OK SDP B-----| | |<-----(4) 200 OK SDP B-----|
| | | | | |
skipping to change at page 5, line 45 skipping to change at page 5, line 4
|<----(6) 200 OK SDP TA-----| | |<----(6) 200 OK SDP TA-----| |
| | | | | |
|---------(7) ACK---------->| | |---------(7) ACK---------->| |
| | | | | |
| ************************* | ************************* | | ************************* | ************************* |
|** Media **|** Media **| |** Media **|** Media **|
| ************************* | ************************* | | ************************* | ************************* |
| | | | | |
Figure 2: Successful invocation of a transcoder by the caller Figure 2: Successful invocation of a transcoder by the caller
The following example shows an INVITE with two body parts: an SDP The following example shows an INVITE with two body parts: an SDP
[13] session description and a URI-list. [RFC4566] session description and a URI-list.
INVITE sip:transcoder@example.com SIP/2.0 INVITE sip:transcoder@example.com SIP/2.0
Via: SIP/2.0/TCP client.chicago.example.com Via: SIP/2.0/TCP client.chicago.example.com
;branch=z9hG4bKhjhs8ass83 ;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70 Max-Forwards: 70
To: Transcoder <sip:transcoder@example.org> To: Transcoder <sip:transcoder@example.org>
From: A <sip:A@chicago.example.com>;tag=32331 From: A <sip:A@chicago.example.com>;tag=32331
Call-ID: d432fa84b4c76e66710 Call-ID: d432fa84b4c76e66710
CSeq: 1 INVITE CSeq: 1 INVITE
Contact: <sip:A@client.chicago.example.com> Contact: <sip:A@client.chicago.example.com>
skipping to change at page 7, line 36 skipping to change at page 6, line 39
|---------(7) ACK---------->| | |---------(7) ACK---------->| |
| | | | | |
Figure 3: Unsuccessful session establishment Figure 3: Unsuccessful session establishment
The ambiguity in this flow is that, if the provisional response (2) The ambiguity in this flow is that, if the provisional response (2)
gets lost, the caller does not know whether the 603 (Decline) gets lost, the caller does not know whether the 603 (Decline)
response means that the initial INVITE (1) was rejected by the response means that the initial INVITE (1) was rejected by the
transcoder or that the INVITE generated by the transcoder (4) was transcoder or that the INVITE generated by the transcoder (4) was
rejected by the callee. The use of the "History-Info" header field rejected by the callee. The use of the "History-Info" header field
[11] between the transcoder and the caller resolves the previous [RFC4244] between the transcoder and the caller resolves the previous
ambiguity. ambiguity.
Note that this ambiguity problem could also have been resolved by Note that this ambiguity problem could also have been resolved by
having transcoders act as a pure conference bridge. The transcoder having transcoders act as a pure conference bridge. The transcoder
would respond with a 200 (OK) the INVITE request from the caller and would respond with a 200 (OK) to the INVITE request from the caller,
generate an outgoing INVITE request towards the callee. The caller and it would generate an outgoing INVITE request towards the callee.
would get information about the result of the latter INVITE request The caller would get information about the result of the latter
by subscribing to the conference event package [14] at the INVITE request by subscribing to the conference event package
transcoder. Nevertheless, while this flow would have resolved the [RFC4575] at the transcoder. Although this flow would have resolved
ambiguity problem without requiring support for the "History-Info" the ambiguity problem without requiring support for the "History-
header field, it is more complex, requires a higher number on Info" header field, it is more complex, requires a higher number of
messages, and introduces higher session setup delays. That is why it messages, and introduces higher session setup delays. That is why it
was not chosen to implement transcoding services. was not chosen to implement transcoding services.
4. Callee's Invocation 4. Callee's Invocation
If a UA receives an INVITE with a session description that is not If a UA receives an INVITE with a session description that is not
acceptable, it can redirect it to the transcoder by using a 302 acceptable, it can redirect it to the transcoder by using a 302
(Moved Temporarily) response. The Contact header field of the 302 (Moved Temporarily) response. The Contact header field of the 302
(Moved Temporarily) response contains the URI of the transcoder plus (Moved Temporarily) response contains the URI of the transcoder plus
a "?body=" parameter. This parameter contains a recipient-list body a "?body=" parameter. This parameter contains a recipient-list body
skipping to change at page 8, line 45 skipping to change at page 7, line 45
| | | | | |
| ************************* | ************************* | | ************************* | ************************* |
|** Media **|** Media **| |** Media **|** Media **|
| ************************* | ************************* | | ************************* | ************************* |
Figure 4: Callee's invocation of a transcoder Figure 4: Callee's invocation of a transcoder
Note that the syntax resulting from encoding a body into a URI as Note that the syntax resulting from encoding a body into a URI as
described earlier is quite complex. It is actually simpler for described earlier is quite complex. It is actually simpler for
callees to invoke transcoding services using the 3pcc transcoding callees to invoke transcoding services using the 3pcc transcoding
model [7] instead. model [RFC4117] instead.
5. Security Considerations 5. Security Considerations
Transcoders implementing this specification behave as a URI-list Transcoders implementing this specification behave as a URI-list
service as described in [10]. Therefore, the security considerations service as described in [RFC5366]. Therefore, the security
for URI-list services discussed in [9] apply here as well. considerations for URI-list services discussed in [RFC5363] apply
here as well.
In particular, the requirements related to list integrity and In particular, the requirements related to list integrity and
unsolicited requests are important for transcoding services. User unsolicited requests are important for transcoding services. User
agents SHOULD integrity protect URI-lists using mechanisms such as agents SHOULD integrity protect URI-lists using mechanisms such as
S/MIME [6] or TLS [2], which can also provide URI-list S/MIME [RFC3850] or TLS [RFC5246], which can also provide URI-list
confidentiality if needed. Additionally, transcoders MUST confidentiality if needed. Additionally, transcoders MUST
authenticate and authorize users and MAY provide information about authenticate and authorize users and MAY provide information about
the identity of the original sender of the request in their outgoing the identity of the original sender of the request in their outgoing
requests by using the SIP identity mechanism [12]. requests by using the SIP identity mechanism [RFC4474].
The requirement in [9] to use opt-in lists (e.g., using the Framework
for Consent-Based Communications in SIP [15]) deserves special
discussion. The type of URI-list service implemented by transcoders
following this specification does not produce amplification (only one
INVITE request is generated by the transcoder on receiving an INVITE
request from a user agent) and does not involve a translation to a
URI that may be otherwise unknown to the caller (the caller places
the callee's URI in the body of its initial INVITE request).
Additionally, the identity of the caller is present in the INVITE
request generated by the transcoder. Therefore, there is no
requirement for transcoders implementing this specification to use
opt-in lists.
6. IANA Considerations
This document does not contain any IANA actions. The requirement in [RFC5363] to use opt-in lists (e.g., using RFC
5360 [RFC5360]) deserves special discussion. The type of URI-list
service implemented by transcoders following this specification does
not produce amplification (only one INVITE request is generated by
the transcoder on receiving an INVITE request from a user agent) and
does not involve a translation to a URI that may be otherwise unknown
to the caller (the caller places the callee's URI in the body of its
initial INVITE request). Additionally, the identity of the caller is
present in the INVITE request generated by the transcoder.
Therefore, there is no requirement for transcoders implementing this
specification to use opt-in lists.
7. Contributors 6. Contributors
This document is the result of discussions amongst the conferencing This document is the result of discussions amongst the conferencing
design team. The members of this team include Eric Burger, Henning design team. The members of this team include Eric Burger, Henning
Schulzrinne, and Arnoud van Wijk. Schulzrinne, and Arnoud van Wijk.
8. References 7. References
8.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
RFC 2246, January 1999. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[4] Peterson, J., "A Privacy Mechanism for the Session Initiation [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
to the Session Initiation Protocol (SIP) for Asserted Identity Extensions to the Session Initiation Protocol (SIP) for
within Trusted Networks", RFC 3325, November 2002. Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, Extensions (S/MIME) Version 3.1 Certificate Handling", RFC
July 2004. 3850, July 2004.
[7] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, [RFC4117] Camarillo, G., Burger, E., Schulzrinne, H., and A. van
"Transcoding Services Invocation in the Session Initiation Wijk, "Transcoding Services Invocation in the Session
Protocol (SIP) Using Third Party Call Control (3pcc)", Initiation Protocol (SIP) Using Third Party Call Control
RFC 4117, June 2005. (3pcc)", RFC 4117, June 2005.
[8] Camarillo, G., "Framework for Transcoding with the Session [RFC5369] Camarillo, G., "Framework for Transcoding with the Session
Initiation Protocol", Initiation Protocol", RFC 5369, October 2008.
draft-camarillo-sipping-transc-framework-00 (work in progress),
August 2003.
[9] Camarillo, G. and A. Roach, "Framework and Security [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform Considerations for Session Initiation Protocol (SIP) URI-
Resource Identifier (URI)-List Services", List Services", RFC 5363, October 2008.
draft-ietf-sipping-uri-services-05 (work in progress),
January 2006.
[10] Camarillo, G. and A. Johnston, "Conference Establishment Using [RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment
Request-Contained Lists in the Session Initiation Protocol Using Request-Contained Lists in the Session Initiation
(SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in Protocol (SIP)", RFC 5366, October 2008.
progress), February 2006.
[11] Barnes, M., "An Extension to the Session Initiation Protocol [RFC4244] Barnes, M., Ed., "An Extension to the Session Initiation
for Request History Information", Protocol (SIP) for Request History Information", RFC 4244,
draft-ietf-sip-history-info-06 (work in progress), November 2005.
January 2005.
[12] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Identity Management in the Session Initiation Protocol (SIP)", Authenticated Identity Management in the Session
draft-ietf-sip-identity-06 (work in progress), October 2005. Initiation Protocol (SIP)", RFC 4474, August 2006.
8.2. Informative References 7.2. Informative References
[13] Handley, M., "SDP: Session Description Protocol", [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. Description Protocol", RFC 4566, July 2006.
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A
Package for Conference State", Session Initiation Protocol (SIP) Event Package for
draft-ietf-sipping-conference-package-12 (work in progress), Conference State", RFC 4575, August 2006.
July 2005.
[15] Rosenberg, J., "A Framework for Consent-Based Communications in [RFC5360] Rosenberg, J., "A Framework for Consent-Based
the Session Initiation Protocol (SIP)", Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-consent-framework-04 (work in progress), RFC 5360, October 2008.
March 2006.
Author's Address Author's Address
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) 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 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 13, line 28 skipping to change at line 463
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 49 change blocks. 
169 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/