One document matched: draft-marjou-mmusic-sdp-rtsp-00.txt
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
Marjou, et al. Expires April 15, 2007 [Page 1]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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 the '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
Marjou, et al. Expires April 15, 2007 [Page 2]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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
Marjou, et al. Expires April 15, 2007 [Page 3]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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
Marjou, et al. Expires April 15, 2007 [Page 4]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 5]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 6]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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=<media> <port> <transport> <fmt> ...
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).
Marjou, et al. Expires April 15, 2007 [Page 7]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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 <parameter name>=<value>
4 different format specific parameters are defined in this
specification.
Marjou, et al. Expires April 15, 2007 [Page 8]
Internet-Draft RTSP in SDP Offer/Answer October 2006
8.1. RTSP Version
a=fmtp:rtsp version=<version-number>
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=<request-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-<header-name>=<header-value>
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-<vendor-id>=<vendor-param>
where
Marjou, et al. Expires April 15, 2007 [Page 9]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 10]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 11]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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
Marjou, et al. Expires April 15, 2007 [Page 12]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 13]
Internet-Draft RTSP in SDP Offer/Answer October 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: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>
Call-ID: a84b4c76e66711@a.atlanta.example.com
CSeq: 1 INVITE
Accept: application/sdp
Contact: <sip:alice@a.atlanta.example.com>
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: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: a84b4c76e66711@a.atlanta.example.com
Marjou, et al. Expires April 15, 2007 [Page 14]
Internet-Draft RTSP in SDP Offer/Answer October 2006
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bf9
From: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>;tag=8321234356
Call-ID: a84b4c76e66711@a.atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:bob@b.biloxi.example.com>
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: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>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
Marjou, et al. Expires April 15, 2007 [Page 15]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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
Marjou, et al. Expires April 15, 2007 [Page 16]
Internet-Draft RTSP in SDP Offer/Answer October 2006
Via: SIP/2.0/UDP a.atlanta.example.com;branch=z9hG4bK74bd6
Max-Forwards: 70
From: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>;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: <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: <sip:bob@biloxi.example.com>;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
Marjou, et al. Expires April 15, 2007 [Page 17]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 18]
Internet-Draft RTSP in SDP Offer/Answer October 2006
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.
Marjou, et al. Expires April 15, 2007 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 21:30:56 |