draft-ietf-mmusic-media-loopback-25.txt   draft-ietf-mmusic-media-loopback-26.txt 
MMUSIC Working Group H. Kaplan (ed.) MMUSIC Working Group H. Kaplan (ed.)
Internet-Draft Acme Packet Internet-Draft Acme Packet
Intended status: Proposed Standard K. Hedayat Intended status: Proposed Standard K. Hedayat
Expires: June 17, 2013 EXFO Expires: July 14, 2013 EXFO
N. Venna N. Venna
Saperix Saperix
P. Jones P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc. BlinkMind, Inc.
December 17, 2012 January 14, 2013
An Extension to the Session Description Protocol (SDP) An Extension to the Session Description Protocol (SDP)
and Real-time Transport Protocol (RTP) for Media Loopback and Real-time Transport Protocol (RTP) for Media Loopback
draft-ietf-mmusic-media-loopback-25 draft-ietf-mmusic-media-loopback-26
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 40 skipping to change at page 1, line 40
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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 17, 2013. This Internet-Draft will expire on July 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 14 skipping to change at page 3, line 14
3. Overview of Operation.........................................6 3. Overview of Operation.........................................6
3.1 SDP Offerer Behavior......................................6 3.1 SDP Offerer Behavior......................................6
3.2 SDP Answerer Behavior.....................................7 3.2 SDP Answerer Behavior.....................................7
4. New SDP Attributes............................................7 4. New SDP Attributes............................................7
4.1 Loopback Type Attribute...................................8 4.1 Loopback Type Attribute...................................8
4.2 Loopback Role Attributes: loopback-source and loopback- 4.2 Loopback Role Attributes: loopback-source and loopback-
mirror........................................................9 mirror........................................................9
5. Rules for Generating the SDP offer/answer....................10 5. Rules for Generating the SDP offer/answer....................10
5.1 Generating the SDP Offer for Loopback Session............10 5.1 Generating the SDP Offer for Loopback Session............10
5.2 Generating the SDP Answer for Loopback Session...........11 5.2 Generating the SDP Answer for Loopback Session...........11
5.3 Offerer Processing of the SDP Answer.....................13 5.3 Offerer Processing of the SDP Answer.....................12
5.4 Modifying the Session....................................13 5.4 Modifying the Session....................................13
5.5 Establishing Sessions Between Entities Behind NAT........13 5.5 Establishing Sessions Between Entities Behind NAT........13
6. RTP Requirements.............................................13 6. RTP Requirements.............................................14
7. Payload formats for Packet loopback..........................14 7. Payload formats for Packet loopback..........................14
7.1 Encapsulated Payload format..............................14 7.1 Encapsulated Payload format..............................14
7.2 Direct loopback RTP payload format.......................17 7.2 Direct loopback RTP payload format.......................17
8. SRTP Behavior................................................18 8. SRTP Behavior................................................18
9. RTCP Requirements............................................18 9. RTCP Requirements............................................18
10. Congestion Control..........................................19 10. Congestion Control..........................................19
11. Examples....................................................19 11. Examples....................................................19
11.1 Offer for specific media loopback type..................19 11.1 Offer for specific media loopback type..................19
11.2 Offer for choice of media loopback type.................20 11.2 Offer for choice of media loopback type.................20
11.3 Answerer rejecting loopback media.......................21 11.3 Answerer rejecting loopback media.......................21
skipping to change at page 9, line 34 skipping to change at page 9, line 34
loopback-source: This attribute specifies that the entity that loopback-source: This attribute specifies that the entity that
generated the SDP is the media source and expects the receiver of generated the SDP is the media source and expects the receiver of
the SDP message to act as a loopback-mirror. the SDP message to act as a loopback-mirror.
loopback-mirror: This attribute specifies that the entity that loopback-mirror: This attribute specifies that the entity that
generated the SDP will mirror (echo) all received media back to the generated the SDP will mirror (echo) all received media back to the
sender of the RTP stream. No media is generated locally by the sender of the RTP stream. No media is generated locally by the
looping back entity for transmission in the mirrored stream. looping back entity for transmission in the mirrored stream.
The "m=" line in the SDP MUST include all the payload types that The "m=" line in the SDP includes all the payload types that will
will be used during the loopback session. The complete payload be used during the loopback session. The complete payload space for
space for the session is specified in the "m=" line and the rtpmap the session is specified in the "m=" line and the rtpmap attribute
attribute is used to map from the payload type number to an is used to map from the payload type number to an encoding name
encoding name denoting the payload format to be used. denoting the payload format to be used.
5. Rules for Generating the SDP offer/answer 5. Rules for Generating the SDP offer/answer
5.1 Generating the SDP Offer for Loopback Session 5.1 Generating the SDP 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-role attributes in a valid SDP both the loopback-type and loopback-role attributes in a valid SDP
offer: offer:
Example: m=audio 41352 RTP/AVP 0 8 100 Example: m=audio 41352 RTP/AVP 0 8 100
skipping to change at page 11, line 21 skipping to change at page 11, line 21
Example: m=audio 41352 RTP/AVP 0 8 112 Example: m=audio 41352 RTP/AVP 0 8 112
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source a=loopback-source
a=rtpmap:112 rtploopback/8000 a=rtpmap:112 rtploopback/8000
5.2 Generating the SDP Answer for Loopback Session 5.2 Generating the SDP Answer for Loopback Session
As with the offer, an SDP answer for loopback MUST follow SDP As with the offer, an SDP answer for loopback MUST follow SDP
offer/answer rules for the direction attribute, but directions of offer/answer rules for the direction attribute, but directions of
"sendonly" or "recvonly" do not apply for loopback operation and "sendonly" or "recvonly" do not apply for loopback operation.
hence MUST NOT be used.
The port number and the address in the answer (m/c= lines) indicate The port number and the address in the answer (m/c= lines) indicate
where the answerer would like to receive the media stream. The where the answerer would like to receive the media stream. The
payload type numbers indicate the value of the payload types the payload type numbers indicate the value of the payload types the
answerer expects to send and receive. answerer expects to send and receive.
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 role and loopback type attributes in the include both the loopback role and loopback type attributes 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 will be
loopback-mirror and vice versa, provided the answerer is capable of loopback-mirror and vice versa, provided the answerer is capable of
supporting the requested loopback-type. 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:
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-source a=loopback-source
The answer that is capable of supporting the offer must contain the The answer that is capable of supporting the offer must contain the
skipping to change at page 13, line 25 skipping to change at page 13, line 20
5.4 Modifying the Session 5.4 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, as defined in Section 8 of RFC 3264 [RFC3264]. This also session, as defined in Section 8 of RFC 3264 [RFC3264]. This also
includes transitioning from a normal media processing mode to includes transitioning from a normal media processing mode to
loopback mode, and vice versa. loopback mode, and vice versa.
5.5 Establishing Sessions Between Entities Behind NAT 5.5 Establishing Sessions Between Entities Behind NAT
ICE/STUN/TURN provide a general solution to establishing media Interactive Connectivity Establishment (ICE) [RFC5245], Traversal
sessions between entities that are behind Network Address Using Relays around NAT (TURN) [RFC5766], and Session Traversal
Translators (NATs), as defined in [RFC5245]. Loopback sessions that Utilities for NAT (STUN) [RFC5389] provide a general solution to
involve one or more endpoints behind NATs SHOULD use these general establishing media sessions between entities that are behind
Network Address Translators (NATs). Loopback sessions that involve
one or more endpoints behind NATs can also use these general
solutions wherever possible. solutions wherever possible.
Furthermore, if the mirroring entity is behind a NAT, it MUST send If ICE is not supported, then in the case of loopback, the
some packets to the identified address/port(s) of the peer, in mirroring entity will not send RTP packets, and therefore will not
order to open the NAT pinhole. Using Interactive Connectivity automatically create the NAT pinhole in the way that other SIP
Establishment (ICE) [RFC5245] this would be accomplished with the sessions do. Therefore, if the mirroring entity is behind a NAT,
STUN connectivity check process, or through a TURN server it MUST send some packets to the identified address/port(s) of the
connection. If ICE is not supported, either [RFC6263] or Section peer, in order to open the NAT pinhole. Using ICE, this would be
10 of ICE [RFC5245] SHOULD be followed to open the pinhole and keep accomplished with the STUN connectivity check process, or through a
the NAT binding alive/refreshed. TURN server connection. If ICE is not supported, either [RFC6263]
or Section 10 of ICE [RFC5245] can be followed to open the pinhole
and keep the NAT binding alive/refreshed.
Note that for any form of NAT traversal to function, symmetric Note that for any form of NAT traversal to function, symmetric
RTP/RTCP [RFC4961] MUST be used. In other words both agents MUST RTP/RTCP [RFC4961] MUST be used, unless the mirror can control the
send packets from the source address and port they receive packets NAT(s) in its path to create explicit pinholes. In other words
on. both agents MUST send packets from the source address and port they
receive packets on, unless some mechanism is used to avoid that
need (e.g., by using Port Control Protocol).
6. RTP Requirements 6. RTP Requirements
A loopback source MUST NOT send multiple source streams on the same A loopback source MUST NOT send multiple source streams on the same
5-tuple, since there is no means for the mirror to indicate which 5-tuple, since there is no means for the mirror to indicate which
is which in its mirrored RTP packets. is which in its mirrored RTP packets.
A loopback mirror that is compliant to this specification and A loopback mirror that is compliant to this specification and
accepts media with rtp-pkt-loopback loopback type loops back the accepts media with rtp-pkt-loopback loopback type loops back the
incoming RTP packets using either the encapsulated RTP payload incoming RTP packets using either the encapsulated RTP payload
skipping to change at page 23, line 5 skipping to change at page 23, line 5
complete solution that would work under all scenarios. However, it complete solution that would work under all scenarios. However, it
is possible that the solution may not be light-weight enough for is possible that the solution may not be light-weight enough for
some implementations. In light of this concern, this section some implementations. In light of this concern, this section
clarifies which features of the loopback proposal MUST be clarifies which features of the loopback proposal MUST be
implemented for all implementations and which features MAY be implemented for all implementations and which features MAY be
deferred if the complete solution is not desired. deferred if the complete solution is not desired.
All implementations MUST at least support the rtp-pkt-loopback mode All implementations MUST at least support the rtp-pkt-loopback mode
for loopback-type, with direct media loopback payload encoding. In for loopback-type, with direct media loopback payload encoding. In
addition, for the loopback role, all implementations of an SDP addition, for the loopback role, all implementations of an SDP
offerer MUST at least be able to act as a loopback-source. offerer MUST at least be able to act as a loopback-source. These
requirements are intended to provide a minimal level of
interoperability between different implementations.
14. IANA Considerations 14. IANA Considerations
[Note to RFC Editor: Please replace "XXXX" with the appropriate RFC [Note to RFC Editor: Please replace "XXXX" with the appropriate RFC
number on publication] number on publication]
14.1 SDP Attributes 14.1 SDP Attributes
This document defines three new media-level SDP attributes. IANA This document defines three new media-level SDP attributes. IANA
has registered the following attributes: has registered the following attributes:
 End of changes. 13 change blocks. 
30 lines changed or deleted 37 lines changed or added

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