draft-ietf-mmusic-media-loopback-13.txt   draft-ietf-mmusic-media-loopback-14.txt 
Internet Draft K. Hedayat Internet Draft K. Hedayat
Expires: October 8, 2010 EXFO Expires: January 27, 2011 EXFO
N. Venna N. Venna
EXFO EXFO
P. Jones P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
A. Roychowdhury A. Roychowdhury
Hughes Systique Corp. Hughes Systique Corp.
C. SivaChelvan C. SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc. BlinkMind, Inc.
April 8, 2010 July 27, 2010
An Extension to the Session Description Protocol (SDP) for Media An Extension to the Session Description Protocol (SDP) for Media
Loopback Loopback
draft-ietf-mmusic-media-loopback-13 draft-ietf-mmusic-media-loopback-14
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 30, 2010. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction .................................................. 3
2. Terminology ................................................... 4 2. Terminology ................................................... 4
3. Offering Entity Behavior ...................................... 4 3. Offering Entity Behavior ...................................... 4
4. Answering Entity Behavior ..................................... 4 4. Answering Entity Behavior ..................................... 4
5. SDP Constructs Syntax ......................................... 5 5. SDP Constructs Syntax ......................................... 5
5.1 Loopback Type Attribute ................................... 5 5.1 Loopback Type Attribute ................................... 5
5.2 Loopback Mode Attribute ................................... 6 5.2 Loopback Mode Attribute ................................... 6
5.3 Generating the Offer for Loopback Session ................. 6 5.3 Payload type mapping for loopback sessions ................ 6
5.4 Generating the Answer for Loopback Session ................ 7 5.4 Generating the Offer for Loopback Session ................. 7
5.5 Offerer Processing of the Answer .......................... 9 5.5 Generating the Answer for Loopback Session ................ 8
5.6 Modifying the Session ..................................... 9 5.6 Offerer Processing of the Answer .......................... 9
5.7 Priming the loopback pump ................................. 9 5.7 Modifying the Session .................................... 10
5.8 Priming the loopback pump ................................ 10
6. RTP Requirements ............................................. 10 6. RTP Requirements ............................................. 10
7. Payload formats for Packet loopback .......................... 11 7. Payload formats for Packet loopback .......................... 11
7.1 Encapsulated Payload format .............................. 11 7.1 Encapsulated Payload format .............................. 12
7.2 Direct loopback RTP payload format ....................... 13 7.2 Direct loopback RTP payload format ....................... 14
8. Payload formats for Priming the Loopback Pump ................ 15 8. Payload format for Priming the Loopback Pump ................. 15
8.1 Usage of RTP Header fields ............................... 15 8.1 Usage of RTP Header fields ............................... 15
8.2 Usage of SDP ............................................. 15 8.2 Usage of SDP ............................................. 16
9. RTCP Requirements ............................................ 15 9. RTCP Requirements ............................................ 16
10. Congestion Control .......................................... 16 10. Congestion Control .......................................... 16
11. Examples .................................................... 16 11. Examples .................................................... 17
11.1 Offer for specific media loopback type .................. 16 11.1 Offer for specific media loopback type .................. 17
11.2 Offer for choice of media loopback type ................. 17 11.2 Offer for choice of media loopback type ................. 17
11.3 Offer for choice of media loopback type with loopback 11.3 Offer for choice of media loopback type with loopback
primer ....................................................... 18 primer ....................................................... 18
11.4 Response to INVITE request rejecting loopback media ..... 19 11.4 Response to INVITE request rejecting loopback media ..... 19
11.5 Response to INVITE request rejecting loopback media with 11.5 Response to INVITE request rejecting loopback media with
loopback primer payload type ................................. 20 loopback primer payload type ................................. 20
12. Security Considerations ..................................... 20 12. Security Considerations ..................................... 21
13. Implementation Considerations ............................... 21 13. Implementation Considerations ............................... 21
14. IANA Considerations ......................................... 21 14. IANA Considerations ......................................... 22
14.1 SDP Attributes .......................................... 21 14.1 SDP Attributes .......................................... 22
14.2 MIME Types .............................................. 22 14.2 MIME Types .............................................. 23
15. Acknowledgements ............................................ 36 15. Acknowledgements ............................................ 36
16. Normative References ........................................ 36
1. Introduction 1. Introduction
The overall quality, reliability, and performance of VoIP, The overall quality, reliability, and performance of VoIP,
Real-time Text and Video over IP services rely on the performance Real-time Text and Video over IP services rely on the performance
and quality of the media path. In order to assure the quality of and quality of the media path. In order to assure the quality of
the delivered media there is a need to monitor the performance of the delivered media there is a need to monitor the performance of
the media transport. One method of monitoring and managing the the media transport. One method of monitoring and managing the
overall quality of VoIP, Real-time Text and Video over IP Services overall quality of VoIP, Real-time Text and Video over IP Services
is through monitoring the quality of the media in an active is through monitoring the quality of the media in an active
skipping to change at page 4, line 43 skipping to change at page 4, line 44
response from the answering entity for confirmation that the response from the answering entity for confirmation that the
request is accepted. request is accepted.
4. Answering Entity Behavior 4. Answering Entity Behavior
An answering entity compliant to this specification and receiving An answering entity compliant to this specification and receiving
an offer containing media descriptions with the "loopback" media an offer containing media descriptions with the "loopback" media
attributes, MUST acknowledge the request by including the received attributes, MUST acknowledge the request by including the received
"loopback" media attributes for each media description in its "loopback" media attributes for each media description in its
response. The server MAY reject the "loopback" request for response. The server MAY reject the "loopback" request for
specific media types as defined in section 5.4.1 of this specific media types as defined in section 5.5.1 of this
specification. specification.
An answering entity that is not compliant to this specification and An answering entity that is not compliant to this specification and
which receives an offer with the "loopback" media attributes MAY which receives an offer with the "loopback" media attributes MAY
ignore the attribute and treat the incoming offer as a normal ignore the attribute and treat the incoming offer as a normal
request. request.
5. SDP Constructs Syntax 5. SDP Constructs Syntax
Two new media attributes are defined: one indicates the type of Two new media attributes are defined: one indicates the type of
loopback and one indicates the mode of the loopback. loopback and the other indicates the mode of the loopback.
5.1 Loopback Type Attribute 5.1 Loopback Type Attribute
The loopback type is a property media attribute with the following The loopback type is a property media attribute with the following
syntax: syntax:
a=loopback:<loopback-type> a=loopback:<loopback-type>
Following is the Augmented BNF [RFC5234] for loopback-type: Following is the Augmented BNF [RFC5234] for loopback-type:
skipping to change at page 6, line 33 skipping to change at page 6, line 33
payload type (described in Section 8 of this document) is requested payload type (described in Section 8 of this document) is requested
by the loopback-source or included in the response by by the loopback-source or included in the response by
loopback-mirror. loopback-mirror.
<fmt> is a media format description. The format description has the <fmt> is a media format description. The format description has the
semantics as defined in section 5.14 of RFC 4566[RFC4566]. When semantics as defined in section 5.14 of RFC 4566[RFC4566]. When
loopback-mode is specified as loopback-source, the media format loopback-mode is specified as loopback-source, the media format
corresponds to the RTP payload types the source is willing to send. corresponds to the RTP payload types the source is willing to send.
When loopback-mode is specified as loopback-mirror, the media When loopback-mode is specified as loopback-mirror, the media
format corresponds to the RTP payload types the mirror is willing format corresponds to the RTP payload types the mirror is willing
to receive. The payload types specified in m= line for a to receive. The payload types specified in "m=" line for a
loopback-source specify the payloads the source is willing to loopback-source specify the payloads the source is willing to
receive. Similarly, for the loopback-mirror these payload types receive. Similarly, for the loopback-mirror these payload types
specify the payloads it is willing to send. specify the payloads it is willing to send. This separation of
payload types allow receivers that do not understand media loopback
to reject the call.
5.3 Generating the Offer for Loopback Session 5.3 Payload type mapping for loopback sessions
As specified in RFC 4566[RFC4566], the rtpmap attribute maps from
an RTP payload type number (as used in an "m=" line) to an encoding
name denoting the payload format to be used. For loopback sessions,
media formats are specified both in the "m=" line and the loopback-
mode attribute line as described in Section 5.2. This specification
extends the usage of rtpmap attribute to media formats specified in
the loopback-mode attribute line in addition to the "m=" line.
5.4 Generating the Offer for Loopback Session
If an offerer wishes to make a loopback request, it MUST include If an offerer wishes to make a loopback request, it MUST include
both the loopback-type and loopback-mode attribute in a valid SDP both the loopback-type and loopback-mode attribute in a valid SDP
offer: offer:
Example: m=audio 41352 RTP/AVP 0 8 100 Example: m=audio 41352 RTP/AVP 0 8 100
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source:0 8 100 a=loopback-source:0 8 100
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000 a=rtpmap:8 pcma/8000
skipping to change at page 7, line 40 skipping to change at page 8, line 7
Example: m=audio 41352 RTP/AVP 112 Example: m=audio 41352 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source:0 8 a=loopback-source:0 8
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
Example: m=audio 41352 RTP/AVP 112 Example: m=audio 41352 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source:0 8 a=loopback-source:0 8
a=rtpmap:112 rtploopback/8000 a=rtpmap:112 rtploopback/8000
5.4 Generating the Answer for Loopback Session 5.5 Generating the Answer for Loopback Session
If an answerer wishes to accept the loopback request it MUST If an answerer wishes to accept the loopback request it MUST
include both the loopback mode and loopback type attribute in the include both the loopback mode and loopback type attribute in the
answer. When a stream is offered with the loopback-source answer. When a stream is offered with the loopback-source
attribute, the corresponding stream in the response MUST be attribute, the corresponding stream in the response MUST be
loopback-mirror and vice versa, provided that answerer is capable loopback-mirror and vice versa, provided that answerer is capable
of supporting the requested loopback-type. of supporting the requested loopback-type.
For example, if the offer contains the loopback-source attribute: For example, if the offer contains the loopback-source attribute:
skipping to change at page 8, line 24 skipping to change at page 8, line 35
m=audio 41352 RTP/AVP 0 8 m=audio 41352 RTP/AVP 0 8
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 8 a=loopback-mirror:0 8
As previously stated if a stream is offered with multiple loopback As previously stated if a stream is offered with multiple loopback
type attributes, the corresponding stream MUST contain only one type attributes, the corresponding stream MUST contain only one
loopback type attribute selected by the answerer. loopback type attribute selected by the answerer.
For example, if the offer contains: For example, if the offer contains:
m=audio 41352 RTP/AVP 0 8 m=audio 41352 RTP/AVP 0 8 112
a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source:0 8 a=loopback-source:0 8
a=rtpmap:112 encaprtp/8000
The answer that is capable of supporting the offer and chooses to The answer that is capable of supporting the offer and chooses to
loopback the media using the rtp-media-loopback type MUST contain: loopback the media using the rtp-media-loopback type MUST contain:
m=audio 41352 RTP/AVP 0 8 m=audio 41352 RTP/AVP 0 8
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 8 a=loopback-mirror:0 8
As specified in section 7, if the loopback-type is As specified in section 7, if the loopback-type is
rtp-pkt-loopback, either the encapsulated RTP payload format or rtp-pkt-loopback, either the encapsulated RTP payload format or
skipping to change at page 9, line 12 skipping to change at page 9, line 28
m=audio 41352 RTP/AVP 112 m=audio 41352 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror:0 8 a=loopback-mirror:0 8
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
m=audio 41352 RTP/AVP 113 m=audio 41352 RTP/AVP 113
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror:0 8 a=loopback-mirror:0 8
a=rtpmap:113 rtploopback/8000 a=rtpmap:113 rtploopback/8000
5.4.1 Rejecting the Loopback Offer 5.5.1 Rejecting the Loopback Offer
An offered stream with loopback-source MAY be rejected if the An offered stream with loopback-source MAY be rejected if the
loopback-type is not specified, the specified loopback-type is not loopback-type is not specified, the specified loopback-type is not
supported, or the endpoint cannot honor the offer for any other supported, or the endpoint cannot honor the offer for any other
reason. The Loopback request may be rejected by setting the media reason. The Loopback request may be rejected by setting the media
port number to zero in the answer as per RFC 3264 [RFC3264]. port number to zero in the answer as per RFC 3264 [RFC3264].
5.5 Offerer Processing of the Answer 5.6 Offerer Processing of the Answer
The answer to a loopback-source MUST be loopback-mirror. The The answer to a loopback-source MUST be loopback-mirror. The
answer to a loopback-mirror MUST be loopback-source. The answer to a loopback-mirror MUST be loopback-source. The
loopback-mode line MUST contain at least one codec the answerer is loopback-mode line MUST contain at least one codec the answerer is
willing to send or receive depending on whether it is the loopback- willing to send or receive depending on whether it is the loopback-
source or the loopback-mirror. In addition, the "m=" line MUST source or the loopback-mirror. In addition, the "m=" line MUST
contain at least one codec that the answerer is willing to send or contain at least one codec that the answerer is willing to send or
receive depending on whether it is the loopback-mirror or the receive depending on whether it is the loopback-mirror or the
loopback-source. loopback-source.
If the answer does not contain a=loopback-mirror or If the answer does not contain a=loopback-mirror or
a=loopback-source, it is assumed that the loopback extensions are a=loopback-source, it is assumed that the loopback extensions are
not supported by the target UA. not supported by the target UA.
5.6 Modifying the Session 5.7 Modifying the Session
At any point during the loopback session, either participant may At any point during the loopback session, either participant may
issue a new offer to modify the characteristics of the previous issue a new offer to modify the characteristics of the previous
session. In case of SIP this is defined in section 8 of RFC 3264 session. In case of SIP this is defined in section 8 of RFC 3264
[RFC3264]. This also includes transitioning from a normal media [RFC3264]. This also includes transitioning from a normal media
processing mode to loopback mode, and vice a versa. processing mode to loopback mode, and vice a versa.
5.7 Priming the loopback pump 5.8 Priming the loopback pump
In certain scenarios it is possible that the media transmitted by In certain scenarios it is possible that the media transmitted by
the loopback-source is blocked by a network element until the the loopback-source is blocked by a network element until the
loopback-mirror starts transmitting packets. One example of this loopback-mirror starts transmitting packets. One example of this
scenario is the presence of an RTP relay in the path of the media. scenario is the presence of an RTP relay in the path of the media.
RTP relays exist in VoIP networks for purpose of NAT and Firewall RTP relays exist in VoIP networks for purpose of NAT and Firewall
traversal. If an RTP relay is present, the loopback-source's traversal. If an RTP relay is present, the loopback-source's
packets are dropped by the RTP relay until the loopback-mirror has packets are dropped by the RTP relay until the loopback-mirror has
started transmitting media and the media state within the RTP relay started transmitting media and the media state within the RTP relay
is established. This results in a chicken and egg scenario as the is established. This results in a chicken and egg scenario as the
looback-mirror cannot transmit any media until it receives the looback-mirror cannot transmit any media until it receives the
skipping to change at page 10, line 32 skipping to change at page 11, line 4
offer. This may be necessary if the loopback-mirror is aware of offer. This may be necessary if the loopback-mirror is aware of
NAT's, firewalls, or RTP relays on the path of the call. In this NAT's, firewalls, or RTP relays on the path of the call. In this
case the loopback-source MUST accept media corresponding to this case the loopback-source MUST accept media corresponding to this
payload type. After the first media packet is received from the payload type. After the first media packet is received from the
loopback-source, the loopback-mirror MUST terminate the loopback-source, the loopback-mirror MUST terminate the
transmission of media for this payload type and MUST start looping transmission of media for this payload type and MUST start looping
back media as defined by the other loopback attributes present in back media as defined by the other loopback attributes present in
the offer. the offer.
6. RTP Requirements 6. RTP Requirements
An answering entity that is compliant to this specification and An answering entity that is compliant to this specification and
accepting a media with rtp-pkt-loopback loopback-type MUST loopback accepting a media with rtp-pkt-loopback loopback-type MUST loopback
the incoming RTP packets using either the encapsulated RTP payload the incoming RTP packets using either the encapsulated RTP payload
format or the direct loopback RTP payload format as defined in format or the direct loopback RTP payload format as defined in
section 7 of this specification. section 7 of this specification.
An answering entity that is compliant to this specification and An answering entity that is compliant to this specification and
accepting a media with rtp-media-loopback loopback-type MUST accepting a media with the loopback type rtp-media-loopback MUST
transmit all received media back to the sender. The incoming media transmit all received media back to the sender. The incoming media
MUST be treated as if it were to be played (e.g. the media stream MUST be treated as if it were to be played (e.g. the media stream
MAY receive treatment from PLC algorithms). The answering entity MAY receive treatment from PLC algorithms). The answering entity
MUST re-generate all the RTP header fields as it would when MUST re-generate all the RTP header fields as it would when
transmitting media. The answering entity MAY choose to encode the transmitting media. The answering entity MAY choose to encode the
loopback media according to any of the media descriptions supported loopback media according to any of the media descriptions supported
by the offering entity. Furthermore, in cases where the same media by the offering entity. Furthermore, in cases where the same media
type is looped back, the answering entity MAY choose to preserve type is looped back, the answering entity MAY choose to preserve
number of frames/packet and bitrate of the encoded media according number of frames/packet and bitrate of the encoded media according
to the received media. to the received media.
skipping to change at page 11, line 19 skipping to change at page 11, line 35
The payload formats described in this section MUST be used by a The payload formats described in this section MUST be used by a
loopback-mirror when rtp-pkt-loopback is the specified loopback-mirror when rtp-pkt-loopback is the specified
loopback-type. Two different formats are specified here - an loopback-type. Two different formats are specified here - an
encapsulated RTP payload format and a direct loopback RTP payload encapsulated RTP payload format and a direct loopback RTP payload
format. The encapsulated RTP payload format should be used when format. The encapsulated RTP payload format should be used when
the incoming RTP header information needs to be preserved during the incoming RTP header information needs to be preserved during
the loopback operation. This is useful in cases where loopback the loopback operation. This is useful in cases where loopback
source needs to measure performance metrics in both directions. source needs to measure performance metrics in both directions.
However, this comes at the expense of increased packet size as However, this comes at the expense of increased packet size as
described in section 7.1. The direct loopback RTP payload format described in section 7.1. The direct loopback RTP payload format
should be used when bandwidth requirement prevent the use of should be used when bandwidth requirement prevents the use of
encapsulated RTP payload format. encapsulated RTP payload format.
To keep the implementation of loopback-mirrors simple it is
mandated that no payload format other than encapsulated or direct
loopback formats can be used in the packets generated by a
loopback-mirror. As described in RFC 3550 [RFC3550], sequence
numbers and timestamps in the RTP header are generated with initial
random values for security reasons. If this were not mandated and
the source payload is sequence number aware, the loopback-mirror
will be required to understand that payload format to generate
looped back packets that do not violate RFC 3550 [RFC3550].
Requiring looped back packets to be in one of the two formats means
loopback-mirror does not have to look into the actual payload
received before generating the loopback packets.
7.1 Encapsulated Payload format 7.1 Encapsulated Payload format
A received RTP packet is encapsulated in the payload section of the A received RTP packet is encapsulated in the payload section of the
RTP packet generated by a loopback-mirror. Each received packet RTP packet generated by a loopback-mirror. Each received packet
MUST be encapsulated in a different packet, the encapsulated packet MUST be encapsulated in a different packet, the encapsulated packet
MAY be fragmented only if required (for example: due to MTU MAY be fragmented only if required (for example: due to MTU
limitations). limitations).
7.1.1 Usage of RTP Header fields 7.1.1 Usage of RTP Header fields
skipping to change at page 16, line 11 skipping to change at page 16, line 36
The use of the loopback attribute is intended for monitoring of The use of the loopback attribute is intended for monitoring of
media quality of the session. Consequently the media performance media quality of the session. Consequently the media performance
information should be exchanged between the offering and the information should be exchanged between the offering and the
answering entities. An offering or answering entity that is answering entities. An offering or answering entity that is
compliant to this specification SHOULD support RTCP per [RFC3550] compliant to this specification SHOULD support RTCP per [RFC3550]
and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or
the server choose to support RTCP-XR, they SHOULD support RTCP-XR the server choose to support RTCP-XR, they SHOULD support RTCP-XR
Loss RLE report block, Duplicate RLE report block, Statistics Loss RLE report block, Duplicate RLE report block, Statistics
Summary report block, and VoIP Metric Reports Block per sections Summary report block, and VoIP Metric Reports Block per sections
4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the
server MAY support other RTCP-XR reporting blocks as defined by RFC server MAY support other RTCP-XR reporting blocks as defined by RFC
3611 [RFC3611]. 3611 [RFC3611].
10. Congestion Control 10. Congestion Control
All the participants in a loopback session SHOULD implement All the participants in a loopback session SHOULD implement
congestion control mechanisms as defined by the RTP profile under congestion control mechanisms as defined by the RTP profile under
which the loopback mechanism is implemented. For audio video which the loopback mechanism is implemented. For audio video
profiles, implementations SHOULD conform to the mechanism defined profiles, implementations SHOULD conform to the mechanism defined
in Section 2 of RFC 3551. in Section 2 of RFC 3551.
skipping to change at page 16, line 35 skipping to change at page 17, line 17
This section provides examples for media descriptions using SDP for This section provides examples for media descriptions using SDP for
different scenarios. The examples are given for SIP-based different scenarios. The examples are given for SIP-based
transactions and are abbreviated and do not show the complete transactions and are abbreviated and do not show the complete
signaling for convenience. signaling for convenience.
11.1 Offer for specific media loopback type 11.1 Offer for specific media loopback type
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=alice@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source:0 a=loopback-source:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
The client is offering to source the media and expects the server The client is offering to source the media and expects the server
to mirror the RTP stream per rtp-media-loopback loopback type. to mirror the RTP stream per rtp-media-loopback loopback type.
A server sends a response with SDP which looks like: A server sends a response with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=bob@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.biloxi.example.com
t=0 0 t=0 0
m=audio 49270 RTP/AVP 0 m=audio 49270 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 a=loopback-mirror:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
The server is accepting to mirror the media from the client at the The server is accepting to mirror the media from the client at the
media level. media level.
11.2 Offer for choice of media loopback type 11.2 Offer for choice of media loopback type
skipping to change at page 17, line 23 skipping to change at page 18, line 4
t=0 0 t=0 0
m=audio 49270 RTP/AVP 0 m=audio 49270 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 a=loopback-mirror:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
The server is accepting to mirror the media from the client at the The server is accepting to mirror the media from the client at the
media level. media level.
11.2 Offer for choice of media loopback type 11.2 Offer for choice of media loopback type
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=alice@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 112 113 m=audio 49170 RTP/AVP 0 112 113
a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source:0 a=loopback-source:0
a=rtpmap:0 pcum/8000 a=rtpmap:0 pcum/8000
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
a=rtpmap:113 rtploopback/8000 a=rtpmap:113 rtploopback/8000
The client is offering to source the media and expects the server The client is offering to source the media and expects the server
to mirror the RTP stream at either the media or rtp level. to mirror the RTP stream at either the media or rtp level.
A server sends a response with SDP which looks like: A server sends a response with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=box 2890844526 2890842807 IN IP4 host.biloxi.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=bob@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.biloxi.example.com
t=0 0 t=0 0
m=audio 49270 RTP/AVP 112 m=audio 49270 RTP/AVP 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror:0 a=loopback-mirror:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
The server is accepting to mirror the media from the client at the The server is accepting to mirror the media from the client at the
packet level using the encapsulated RTP payload format. packet level using the encapsulated RTP payload format.
11.3 Offer for choice of media loopback type with loopback primer 11.3 Offer for choice of media loopback type with loopback primer
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=alice@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 112 113 114 m=audio 49170 RTP/AVP 0 112 113 114
a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source:0 a=loopback-source:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
a=rtpmap:113 rtploopback/8000 a=rtpmap:113 rtploopback/8000
a=rtpmap:114 loopbkprimer/8000 a=rtpmap:114 loopbkprimer/8000
The client is offering to source the media and expects the server The client is offering to source the media and expects the server
to mirror the RTP stream at either the media or rtp level. The to mirror the RTP stream at either the media or rtp level. The
client also expects the server to source media until it receives client also expects the server to source media until it receives
packets from the server per media described with the loopbkprimer packets from the server per media described with the loopbkprimer
payload type. payload type.
A server sends a response with SDP which looks like: A server sends a response with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=user@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.biloxi.example.com
t=0 0 t=0 0
m=audio 49270 RTP/AVP 113 m=audio 49270 RTP/AVP 113
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror:0 114 a=loopback-mirror:0 114
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
a=rtpmap:113 rtploopback/8000 a=rtpmap:113 rtploopback/8000
a=rtmpa:114 loopbkprimer/8000 a=rtmpa:114 loopbkprimer/8000
The server is accepting to mirror the media from the client at the The server is accepting to mirror the media from the client at the
packet level using the direct loopback RTP payload format. The packet level using the direct loopback RTP payload format. The
server is also accepting to source media until it receives media server is also accepting to source media until it receives media
packets from the client. packets from the client.
11.4 Response to INVITE request rejecting loopback media 11.4 Response to INVITE request rejecting loopback media
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=user@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source:0 a=loopback-source:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
The client is offering to source the media and expects the server The client is offering to source the media and expects the server
to mirror the RTP stream at the media level. to mirror the RTP stream at the media level.
A server sends a response with SDP which looks like: A server sends a response with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=user@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.biloxi.example.com
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 a=loopback-mirror:0
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
NOTE: Loopback request may be rejected by either not including the NOTE: Loopback request may be rejected by either not including the
loopback mode attribute (for backward compatibility) or setting the loopback mode attribute (for backward compatibility) or setting the
media port number to zero, or both, in the response. media port number to zero, or both, in the response.
11.5 Response to INVITE request rejecting loopback media with loopback 11.5 Response to INVITE request rejecting loopback media with loopback
primer payload type primer payload type
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=alice 2890844526 2890842807 IN IP4 host.atlanta.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=alice@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.atlanta.example.com
t=0 0 t=0 0
m=audio 49170 RTP/AVP 0 100 m=audio 49170 RTP/AVP 0 100
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source:0 a=loopback-source:0
a=rtpmap:0 pcum/8000 a=rtpmap:0 pcum/8000
a=rtpmap:100 loopbkprimer/8000 a=rtpmap:100 loopbkprimer/8000
The client is offering to source the media and expects the server The client is offering to source the media and expects the server
to mirror the RTP stream at the media level. The client also to mirror the RTP stream at the media level. The client also
expects the server to source media until it receives packets from expects the server to source media until it receives packets from
the server using the loopbkprimer payload type. the server using the loopbkprimer payload type.
A server sends a response with SDP which looks like: A server sends a response with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 192.0.2.11 o=bob 2890844526 2890842807 IN IP4 host.biloxi.example.com
s=Example s=Example
i=An example session i=An example session
e=user@example.com e=bob@example.com
c=IN IP4 192.0.2.12/127 c=IN IP4 host.biloxi.example.com
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror:0 a=loopback-mirror:0
NOTE: Loopback request may be rejected by either not including the NOTE: Loopback request may be rejected by either not including the
loopback mode attribute (for backward compatibility) or setting the loopback mode attribute (for backward compatibility) or setting the
media port number to zero, or both, in the response. media port number to zero, or both, in the response.
12. Security Considerations 12. Security Considerations
skipping to change at page 36, line 7 skipping to change at page 36, line 32
defined at this time. defined at this time.
Author: Author:
Kaynam Hedayat. Kaynam Hedayat.
Change controller: IETF Audio/Video Transport working Change controller: IETF Audio/Video Transport working
group delegated from the IESG. group delegated from the IESG.
15. Acknowledgements 15. Acknowledgements
The authors wish to thank Nagarjuna Venna, Flemming Andreasen, Jeff The authors wish to thank Nagarjuna Venna, Muthu ArulMozhi Perumal,
Bernstein, Paul Kyzivat, and Dave Oran for their comments and Flemming Andreasen, Jeff Bernstein, Paul Kyzivat, and Dave Oran for
suggestions. their comments and suggestions.
16. Normative References 16. Normative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M. Johnston, A., Peterson, J., Sparks, R., Handley, M.
and E. Schooler, "SIP: Session Initiation Protocol", and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002. RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with the Session Description Protocol (SDP)", Model with the Session Description Protocol (SDP)",
 End of changes. 51 change blocks. 
68 lines changed or deleted 92 lines changed or added

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