MMUSIC Working Group X. Marjou Internet-Draft France Telecom Expires: April 15, 2007 S. Whitehead Verizon M.J. Montpetit S. Ganesan Motorola D. Ress D. Goodwill Nortel October 12, 2006 Session Description Protocol (SDP) Format for Real Time Streaming Protocol (RTSP) Streams. draft-marjou-mmusic-sdp-rtsp-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 April 15, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies how to describe RTSP streams in SDP session descriptions. Agents using the offer/answer model to establish RTSP streams use this format in their offers and their answers. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RTSP Usage Restriction when used with SDP Offer/Answer . . . . 3 4. Procedure at the SDP Offerer . . . . . . . . . . . . . . . . . 4 4.1. Offerer is an RTSP Client . . . . . . . . . . . . . . . . 4 4.2. Offerer is an RTSP Server . . . . . . . . . . . . . . . . 5 5. Procedure at the SDP Answerer . . . . . . . . . . . . . . . . 6 5.1. Answerer is an RTSP Server . . . . . . . . . . . . . . . . 6 5.2. Answerer is an RTSP Client . . . . . . . . . . . . . . . . 7 6. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . . 7 7. RTSP Grouping of Media Lines . . . . . . . . . . . . . . . . . 8 8. Mapping of RTSP Parameters to SDP Attributes . . . . . . . . . 8 8.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . . 9 8.2. RTSP Request-URI . . . . . . . . . . . . . . . . . . . . . 9 8.3. RTSP Header Attributes . . . . . . . . . . . . . . . . . . 9 8.4. RTSP Vendor Specific Attributes . . . . . . . . . . . . . 9 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11.1. Registration of 'TCP/RTSP' and 'TCL/TLS/RTSP' SDP 'Proto' 12 11.2. Registration of the SDP 'rtspid' Attribute . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.2. Normative References . . . . . . . . . . . . . . . . . . . 13 13.3. Informational References . . . . . . . . . . . . . . . . . 14 Appendix A. A SIP-RTSP call-flow example . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 1. Introduction The Real Time Streaming Protocol [1] [2], or RTSP, is an application- level protocol for control over the delivery of data with real-time properties. Although RTSP works perfectly well as a standalone protocol, there are some use-cases where it is desirable to establish an RTSP session using an offer/answer exchange [3], as discussed in [4]. A first example of use-case is a scenario mixing video-surveillance with a regular call: a user monitors a remote scene, possibly with trick play commands, and when a remote user appears at the remote scene, he engages a multimedia conversation with this remote user. A second example of use-case is a scenario where trick play commands are possible within a conference. A user joins a conference late and uses a fast rewind command to come back to the beginning of the presentation and possibly learn the names of the participants. This document therefore describes how to setup an RTSP session with the SDP offer/answer model. Section 3 details the minor restrictions associated to RTSP when used together with the offer/answer. Section 4 and Section 5 rule-out the detailed behavior of an SDP offerer and answerer. Section 6 details the media line associated to an RTSP stream. Section 7 defines a new extension for grouping the media lines of the RTSP media stream and the other media streams that are under its control. Section 8 defines the mapping between some existing RTSP attributes and new SDP parameters. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [5] 3. RTSP Usage Restriction when used with SDP Offer/Answer In this specification, a session signalling protocol (typically SIP) is used to establish an RTSP stream via an SDP offer/answer. This session signalling protocol initiates, modifies and terminates the media session. Therefore, when used in the context of SDP offer/ answer, the RTSP SETUP and TEARDOWN requests MUST NOT be used within the RTSP stream. Similarly, the RTSP REDIRECT request MUST NOT be used, as it is the responsibility of the session signalling protocol to perform redirections. In the same vein, the description of the targeted presentation or media object makes part of the SDP offer/answer. Therefore, the RTSP DESCRIBE and ANNOUNCE requests MUST NOT be used. This implies consequences on the existing rules of [1] and [2] for the life of an RTSP session. o The RTSP session MUST also be able to start right after an accepted SDP offer followed by an RTSP transport connection. o The RTSP session MUST also be able to terminate either at the reception of new SDP offer with the port number for that stream set to zero or at the reception of a terminating session signalling message(typically a SIP BYE). The removal of DESCRIBE and SETUP requests also has some impacts: o An alternate means of conveying some of their parameters is needed. This is described in Section 8 that specifies how to convey an RTSP Request-URI, an RTSP-Version and necessary RTSP header fields. o Another notable difference concerns two RTSP header fields. As the transport parameters are negotiated within the SDP offer/ answer, the Transport header field is not used anymore. In addition, there is no RTSP CSeq attribute in the SDP offer/answer. In addition, the following topics are considered out of scope and not discussed further in this document: RTSP over UDP, NAT traversal, embedded (interleaved) binary data. [[OPEN-ISSUE-1: There is currently no consensus amongst the authors on whether the SETUP and DESCRIBE methods should be kept or not. If the SETUP and DESCRIBE methods are not used, then the number of message round-trips is less important and the integration with the SDP offer/answer mechanism is feasible. On the other side, if they are still used, then no RTSP header field parameters need to be conveyed within SDP offer and answer and the integration with existing RTSP servers is easier.]] 4. Procedure at the SDP Offerer 4.1. Offerer is an RTSP Client When an agent wishes to offer the role of an RTSP client, it has to perform the actions described in this section. It MUST offer a 'm' line for an RTSP stream (c.f. Section 6). It MUST also indicate that it will initiate the outgoing connection for this stream as described in [6]. Typically, the port number should be a port number of 9 (the discard port) on its 'm' line, and the 'setup' attribute is set to 'active'. If it is attempting to establish a new RTSP session, it MUST NOT include the RTSP session header in the offer. Otherwise, if it wants to reuse an existing RTSP session, it MUST add it in a "fmtp:rtsp h-session" attribute. In order to identify the targeted presentation or media object, it MAY include an RTSP Request-URI in a "fmtp:rtsp uri" parameter. Otherwise, expressing the targeted content will be the responsibility of the session signalling protocol (e.g. with SIP, the SIP URI of the To header field is typically sufficient for targeting a live content, [9] is also typically sufficient for targeting a media object). It MUST include the RTSP Version in a "fmtp:rtsp version" parameter. It MAY include any necessary RTSP header field under the form of a "fmtp:rtsp h-*" parameter. It MAY indicate the association between the RTSP media stream and the media streams that are under its control (c.f. Section 7). For each media stream controlled by the RTSP media stream, it MUST include an "a=recvonly" or "a=inactive" attribute. 4.2. Offerer is an RTSP Server When an agent wishes to offer the role of an RTSP server, it has to perform the actions described in this section. It MUST offer a 'm' line for an RTSP stream (c.f. Section 6). It MUST also indicate that it will accept an incoming RTSP connection as defined in [6]. Typically, the port number is a port number of 554 (rtsp server port) on its 'm' line, and the 'setup' attribute is set to 'passive'. It MUST either generate a new RTSP session or reuse an existing one, and add it in a "fmtp:rtsp h-session" attribute. It MUST include RTSP control attributes in a "control" parameter, as defined in [1] and [2]. If a "control" parameter contains a relative URI, a base URI must also be provided in a "fmtp rtsp h-content-base" or "fmtp rtsp h-content-location" attribute so that the RTSP client can construct an RTSP absolute request URI for its RTSP requests. It MUST include the RTSP Version in a "fmtp:rtsp version" parameter. It MAY include any necessary RTSP header field under the form of a "fmtp:rtsp h-*" parameter. It MUST indicate the association between the RTSP media stream and the media streams that are under its control (c.f. Section 7). For each media stream controlled by the RTSP media stream, it MUST also include an "a=sendonly" or "a=inactive" attribute. 5. Procedure at the SDP Answerer 5.1. Answerer is an RTSP Server When an agent both wishes to accept an offer from an RTSP client and to provide the role of an RTSP server, it has to perform the actions described in this section. It MUST offer a 'm' line for an RTSP stream (c.f. Section 6). It MUST also indicate that it accepts an incoming RTSP connection as defined in [6]. Typically, the port number is a port number of 554 (rtsp server port) on its 'm' line, and the 'setup' attribute is set to 'passive'. It MUST either generate a new RTSP session if no one was provided in the offer, or reuse an existing RTSP session. The RTSP session is added in the answer in a "fmtp:rtsp h-session" attribute. It MUST include RTSP control attributes in a "control" parameter, as defined in [1] and [2]. If a "control" parameter contains a relative URI, a base URI must also be provided in a "fmtp rtsp h-content-base" or "fmtp rtsp h-content-location" attribute so that the RTSP client can construct an RTSP absolute request URI for its RTSP requests. It MUST include the same "fmtp:rtsp version" attribute as received in the offer. It MAY include any other necessary RTSP header under the form of a "fmtp:rtsp h-*" parameter. It MUST indicate the association between the RTSP media stream and the media streams that are under its control (c.f. Section 7). For each media stream controlled by the RTSP media stream, it MUST also include an "a=sendonly" or "a=inactive" attribute. 5.2. Answerer is an RTSP Client When an agent both wishes to accept an offer from an RTSP server and to provide the role of an RTSP client, it has to perform the actions described in this section. It MUST offer a 'm' line for an RTSP stream (c.f. Section 6). It MUST also indicate that it will initiate the outgoing connection for this stream as described in [6]. Typically, the port number should be a port number of 9 (the discard port) on its 'm' line, and the 'setup' attribute is set to 'active'. It MUST add in the answer the same "fmtp:rtsp h-session" attribute as received in the offer. It MUST include in the offer the same "fmtp:rtsp version" attribute as received in the offer. It MAY include any necessary RTSP header field under the form of a "fmtp:rtsp h-*" parameter. It MUST indicate the association between the RTSP media stream and the media streams that are under its control (c.f. Section 7). For each media stream controlled by the RTSP media stream, it MUST include an "a=recvonly" or "a=inactive" attribute. 6. Fields in the 'm' Line This Section describes how to generate an 'm' line for an RTSP stream. According to the SDP specification [7], the 'm' line format is the following: m= ... The media field MUST have a value of "application". The port field is set following the rules in [6]. Depending on the value of the 'setup' attribute, the port field contains the port the remote endpoint will initiate its TCP connection to, or is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of 9, which is the discard port. In this specification RTSP only runs on top of TCP, therefore the port is always a TCP port. A port field value of zero has the standard SDP meaning (i.e., rejection of the media stream). This specification defines two new values for the transport field: TCP/RTSP and TCP/TLS/RTSP. The former is used when RTSP runs directly on top of TCP and the latter is used when RTSP runs on top of TLS, which in turn runs on top of TCP. In order to have a fmt available for fmtp parameters dedicated to RTSP, this specification defines a new token, which value is "rtsp", that MUST be used in the fmt field. [[OPEN-ISSUE-2: can't we find a more elegant proposal than the "rtsp" token in the fmt field of the m-line?]] The following is an example of an 'm' line for an RTSP connection: m=application 554 TCP/RTSP rtsp 7. RTSP Grouping of Media Lines This document defines an rtsp SDP media-level attribute. Its Augmented BNF syntax is: rtsp-id-attribute = "a=rtspid" [" m-stream:" token *(SP token)] The rtspid attribute is used in RTSP 'm' lines. It defines an rtsp identifier and, possibly, associates it with one or more media streams. The token representing the media stream is a pointer to the media stream, which is identified by an SDP label attribute [8] Endpoints which use the offer/answer model to establish RTSP connections MUST support the 'rtspid' and the 'label' attributes. An RTSP server acting as an offerer or as an answerer SHOULD include these attributes in its session descriptions. 8. Mapping of RTSP Parameters to SDP Attributes An RTSP parameter is included in "a=fmtp" line of SDP and is expressed in the form of parameter=value. a=fmtp:rtsp = 4 different format specific parameters are defined in this specification. 8.1. RTSP Version a=fmtp:rtsp version= The "version" parameter sets the "version-number" representing the version of RTSP that will be used in the RTSP media stream. The version number MUST either be "1.0" or "2.0". The RTSP version MUST be included in all SDP offers and answers. The same version MUST be used by both endpoints. 8.2. RTSP Request-URI a=fmtp:rtsp uri= The "request-uri" sets the value of the RTSP URI that can be used by the client to target a specific presentation or media object in the RTSP server. Typically, it is the counterpart of the Request-URI existing in a SETUP or DESCRIBE request. 8.3. RTSP Header Attributes To exchange RTSP header fields within the SIP offer/answer, the RTSP media stream allows for attributes with the following format: a=fmtp:rtsp h-= where "header-name" is the name of the RTSP header field being described and "header-value" is the value of the RTSP header field. The value of the header-name is case insensitive. The value of the header-value is interpreted according to the rules of RTSP. [[OPEN-ISSUE-3: This point is similar to OPEN-ISSUE-1. Do we allow to transport any RTSP necessary header within SDP or do we restrict the list to some really few RTSP headers?]] 8.4. RTSP Vendor Specific Attributes Attributes specific to RTSP vendors can be used under the following format: a=fmtp:rtsp v-= where o vendor-id is a globally unique vendor-identifier (the vendor's SMI network management private enterprise code) See [RFC 1700]. o vendor-param is an alpha numeric parameter name, optionally followed by a ":" and a parameter value. So for example, if Kasenna (vendor-id: 6293) wanted to convey a vendor specific attribute named foo with a value of "bar 1234", it would be encoded as follows: a=fmtp:rtsp v-6293:foo:bar 1234 9. Examples The following is an example of an offer sent by an agent, 'Alice', using SIP to establish the session and using an RTSP client for playing media streams. During the session Alice switches the session mode to a conversational mode with an updated SDP. In the case of SIP being used to establish the session, this new SDP will be encapsulated in a re INVITE with the original session establishment dialog. v=0 o=alice 2890844526 2890844526 IN IP4 a.atlanta.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 a.atlanta.example.com t=0 0 m=application 9 TCP/RTSP rtsp a=fmtp:rtsp request-uri: rtsp://b.biloxi.example.com/scene a=fmtp:rtsp version: 2.0 a=fmtp:rtsp h-accept-ranges: NPT a=connection:new a=setup:active a=rtspid m-stream:10 m=audio 6666 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly a=label:10 The following is the answer returned by the client. v=0 o=bob 2808844564 2808844564 IN IP4 b.biloxi.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 b.biloxi.example.com t=0 0 m=application 554 TCP/RTSP rtsp a=connection:new a=setup:passive a=control: rtsp://b.biloxi.example.com/scene a=fmtp:rtsp version: 2.0 a=fmtp:rtsp h-accept-ranges: NPT a=fmtp:rtsp h-session: 6238237 a=fmtp:rtsp h-date: Tue, 05 Sep 2006 09:56:44 GMT a=fmtp:rtsp h-rtp-info: url="rtsp://b.biloxi.example.com/scene" ssrc=1631654733:seq=53961;rtptime=0 a=rtspid m-stream:10 m=audio 8888 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly a=label:10 Some time later, a new offer is sent to switch to a conversational mode. The port field of the RTSP media stream is set to zero, and the audio media stream is set to "sendrecv" v=0 o=alice 2890844526 2890844527 IN IP4 a.atlanta.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 a.atlanta.example.com t=0 0 m=application 0 TCP/RTSP rtsp a=rtspid m-stream:10 m=audio 6666 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv a=label:10 The following is the answer returned by the client. v=0 o=bob 2808844564 2808844565 IN IP4 b.biloxi.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 b.biloxi.example.com t=0 0 m=application 0 TCP/RTSP rtsp a=rtspid m-stream:10 m=audio 8888 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendrecv a=label:10 10. Security Considerations T.B.D. 11. IANA Considerations 11.1. Registration of the 'TCP/RTSP' and 'TCL/TLS/RTSP' SDP 'Proto' This section instructs the IANA to register the following two new values for the SDP 'proto' field under the Session Description Protocol (SDP) Parameters registry: +--------------+-----------+ | Value | Reference | +--------------+-----------+ | TCP/RTSP | RFCxxxx | | TCP/TLS/RTSP | RFCxxxx | +--------------+-----------+ Table 1: Values for the SDP 'proto' field [Note to the RFC editor: please, replace RFCxxxx with the RFC number that this document will be assigned.] 11.2. Registration of the SDP 'rtspid' Attribute This section instructs the IANA to register the following SDP att- field under the Session Description Protocol (SDP) Parameters registry: Contact name: xavier.marjou@orange-ft.com Attribute name: rtspid Long-form attribute name: RTSP Identifier Type of attribute Media level Subject to charset: No Purpose of attribute: The 'rtspid' attribute associates an RTSP media stream with one or more media streams. Allowed attribute values: Tokens 12. Acknowledgements TBD. 13. References 13.2. Normative References [1] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [2] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and A. Narasimhan, "Real Time Streaming Protocol 2.0 (RTSP)", draft-ietf-mmusic-rfc2326bis-13.txt (work in progress), October 2005. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Whitehead, S., Montpetit, M., and X. Marjou, "An Evaluation of Session Initiation Protocol (SIP) for use in Streaming Media Applications", draft-whitehead-mmusic-sip-for-streaming-media-01 (work in progress), June 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005. [7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [8] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006. 13.3. Informational References [9] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005. 13. References Appendix A. A SIP-RTSP call-flow example [[NOTE: This section shows a session where Alice is doing trick plays. This example appears only for early illustrative purposes and will be removed in the next version of this document]] INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 From: ;tag=9fxced76sl To: Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 1 INVITE Accept: application/sdp Contact: Content-Type: application/sdp Content-Length: 338 v=0 o=alice 2155025512 2155025512 IN IP4 a.atlanta.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 a.atlanta.example.com t=0 0 m=application 9 TCP/RTSP rtsp a=connection:new a=setup:active a=rtsp version: 2.0 a=rtsp h-accept-ranges: NPT a=rtspid m-stream:10 m=video 8888 RTP/AVP 26 a=recvonly a=label:10 SIP/2.0 100 Trying Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bf9 From: ;tag=9fxced76sl To: ;tag=8321234356 Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 1 INVITE Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bf9 From: ;tag=9fxced76sl To: ;tag=8321234356 Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 147 v=0 o=bob 2890844527 2890844527 IN IP4 b.biloxi.example.com s=Streaming Session i=A Streaming session declared within the session description protocol c=IN IP4 b.biloxi.example.com t=0 0 m=application 554 TCP/RTSP rtsp a=connection:new a=setup:passive a=control: rtsp://b.biloxi.example.com/scene a=rtsp version: 2.0 a=rtsp h-accept-ranges: NPT a=rtsp h-session: 6238237 a=rtsp h-date: Tue, 05 Sep 2006 09:56:44 GMT a=rtsp h-rtp-info: url="rtsp://b.biloxi.example.com/scene" ssrc=1631654733:seq=53961;rtptime=0 a=rtspid m-stream:10 m=video 6666 RTP/AVP 26 a=sendonly a=label:10 ACK sip:bob@b.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bd5 Max-Forwards: 70 From: ;tag=9fxced76sl To: 5060>;tag=8321234356 Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 1 ACK Content-Length: 0 PLAY rtsp://b.biloxi.example.com/scene RTSP/2.0 CSeq: 1 Session: 6238237 Scale: 1 Range: npt=now- User-Agent: foobar RTSP/2.0 200 OK CSeq: 1 Session: 6238237 Range: npt=now- Date: Tue, 05 Sep 2006 09:56:45 GMT RTP-Info: url="rtsp://b.biloxi.example.com/scene" ssrc=1631654733:seq=53961;rtptime=0 Server: barfoo PAUSE rtsp://b.biloxi.example.com/scene RTSP/2.0 CSeq: 2 Session: 6238237 Scale: 0 User-Agent: foobar RTSP/2.0 200 OK CSeq: 2 Session: 6238237 Range:12- Date: Tue, 05 Sep 2006 09:56:50 GMT PLAY rtsp://b.biloxi.example.com/scene RTSP/2.0 CSeq: 3 Session: 6238237 Scale: -1 User-Agent: foobar RTSP/2.0 200 OK CSeq: 3 Session: 6238237 Range: npt=now- Date: Tue, 05 Sep 2006 09:56:55 GMT RTP-Info: url="rtsp://b.biloxi.example.com/scene" ssrc=1631654733:seq=54024;rtptime=1080000 Server: barfoo BYE sip:bob@b.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bd6 Max-Forwards: 70 From: ;tag=9fxced76sl To: ;tag=8321234356 Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 2 BYE Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bd6 From: ;tag=9fxced76sl To: ;tag=8321234356 Call-ID: a84b4c76e66711@a.atlanta.example.com CSeq: 2 BYE Content-Length: 0 Authors' Addresses Xavier Marjou France Telecom 2, rue Pierre Marzin Lannion, Brittany 22307 France Email: xavier.marjou@orange-ft.com Steven Whitehead Verizon 40 Sylvan Road Waltham, MA 02451 USA Email: steven.d.whitehead@verizon.com Marie-Jose Montpetit Motorola 55 Hayden Avenue, 1st floor Lexington, MA 02421 USA Email: mmontpetit@motorola.com Sam Ganesan Motorola 55 Hayden Avenue, 1st floor Lexington, MA 02421 USA Email: sam.ganesan@motorola.com David Ress Nortel Email: dress@nortel.com Dominic Goodwill Nortel Email: goodwill@nortel.com Full 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. 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.