draft-ietf-mmusic-media-loopback-26.txt   draft-ietf-mmusic-media-loopback-27.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
N. Venna N. Venna
Saperix Saperix
P. Jones P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BlinkMind, Inc. BlinkMind, Inc.
January 14, 2013 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-26 draft-ietf-mmusic-media-loopback-27
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 3, line 8 skipping to change at page 3, line 8
Table of Contents Table of Contents
1. Introduction..................................................3 1. Introduction..................................................3
1.1 Use Cases Supported.......................................4 1.1 Use Cases Supported.......................................4
2. Terminology...................................................6 2. Terminology...................................................6
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...................................7
4.2 Loopback Role Attributes: loopback-source and loopback- 4.2 Loopback Role Attributes: loopback-source and loopback-
mirror........................................................9 mirror........................................................8
5. Rules for Generating the SDP offer/answer....................10 5. Rules for Generating the SDP offer/answer.....................9
5.1 Generating the SDP Offer for Loopback Session............10 5.1 Generating the SDP Offer for Loopback Session.............9
5.2 Generating the SDP Answer for Loopback Session...........11 5.2 Generating the SDP Answer for Loopback Session...........10
5.3 Offerer Processing of the SDP Answer.....................12 5.3 Offerer Processing of the SDP Answer.....................12
5.4 Modifying the Session....................................13 5.4 Modifying the Session....................................12
5.5 Establishing Sessions Between Entities Behind NAT........13 5.5 Establishing Sessions Between Entities Behind NAT........12
6. RTP Requirements.............................................14 6. RTP Requirements.............................................13
7. Payload formats for Packet loopback..........................14 7. Payload formats for Packet loopback..........................13
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.......................16
8. SRTP Behavior................................................18 8. SRTP Behavior................................................17
9. RTCP Requirements............................................18 9. RTCP Requirements............................................18
10. Congestion Control..........................................19 10. Congestion Control..........................................18
11. Examples....................................................19 11. Examples....................................................18
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.................19
11.3 Answerer rejecting loopback media.......................21 11.3 Answerer rejecting loopback media.......................20
12. Security Considerations.....................................21 12. Security Considerations.....................................21
13. Implementation Considerations...............................22 13. Implementation Considerations...............................22
14. IANA Considerations.........................................23 14. IANA Considerations.........................................22
14.1 SDP Attributes..........................................23 14.1 SDP Attributes..........................................22
14.2 Media Types.............................................24 14.2 Media Types.............................................23
15. Acknowledgements............................................32 15. Acknowledgements............................................31
16. Normative References........................................32 16. Normative References........................................31
17. Informative References......................................33 17. Informative References......................................32
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 real-time VoIP, Text and Video over IP Services overall quality of real-time VoIP, 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 7, line 13 skipping to change at page 7, line 13
the offerer may choose to only request loop back for some media the offerer may choose to only request loop back for some media
descriptions/streams but not others. For example it might wish to descriptions/streams but not others. For example it might wish to
request loopback for a video stream but not audio, or vice-versa. request loopback for a video stream but not audio, or vice-versa.
The offerer will look for the "loopback" media attributes in the The offerer will look for the "loopback" media attributes in the
media description(s) of the response from the SDP answer for media description(s) of the response from the SDP answer for
confirmation that the request is accepted. confirmation that the request is accepted.
3.2 SDP Answerer Behavior 3.2 SDP Answerer Behavior
If an SDP answerer compliant to this specification receives an In order to accept a loopback offer (that is, an offer containing
offer containing media descriptions with the "loopback" media "loopback" in the media description), an SDP answerer includes the
attributes and it wants to accept such for the purposes of media- "loopback" media attribute in each media description for which it
loopback, it MUST acknowledge the request by including the received desires loopback.
"loopback" media attribute(s) for each media description in its
answer that it accepts looping back for. If the answerer does not
want to do loopback or wants to reject the "loopback" request for
specific media descriptions, it MUST do so as defined in this
section.
An answerer can reject an offered stream (either with loopback- An answerer can reject an offered stream (either with loopback-
source or loopback-mirror) if the loopback-type is not specified, source or loopback-mirror) if the loopback-type is not specified,
the specified loopback-type is not supported, or the endpoint the specified loopback-type is not supported, or the endpoint
cannot honor the offer for any other reason. The loopback request cannot honor the offer for any other reason. The loopback request
is rejected by setting the stream's media port number to zero in is rejected by setting the stream's media port number to zero in
the answer as defined in RFC 3264 [RFC3264], or by rejecting the the answer as defined in RFC 3264 [RFC3264], or by rejecting the
entire offer (i.e., by rejecting the session request entirely). entire offer (i.e., by rejecting the session request entirely).
Note that an answerer that is not compliant to this specification Note that an answerer that is not compliant to this specification
skipping to change at page 10, line 9 skipping to change at page 9, line 31
The "m=" line in the SDP includes all the payload types that will The "m=" line in the SDP includes all the payload types that will
be used during the loopback session. The complete payload space for be used during the loopback session. The complete payload space for
the session is specified in the "m=" line and the rtpmap attribute the session is specified in the "m=" line and the rtpmap attribute
is used to map from the payload type number to an encoding name is used to map from the payload type number to an 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 includes both
both the loopback-type and loopback-role attributes in a valid SDP 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
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-source a=loopback-source
a=rtpmap:0 pcmu/8000 a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000 a=rtpmap:8 pcma/8000
a=rtpmap:100 G7221/16000/1 a=rtpmap:100 G7221/16000/1
Since media loopback requires bidirectional RTP, its normal Since media loopback requires bidirectional RTP, its normal
skipping to change at page 11, line 19 skipping to change at page 10, line 42
a=loopback-source a=loopback-source
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
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 follows 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. "sendonly" or "recvonly" do not apply for loopback operation.
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 An answerer includes both the loopback role and loopback type
include both the loopback role and loopback type attributes in the attributes in the answer to indicate that it will accept the
answer. When a stream is offered with the loopback-source loopback request. When a stream is offered with the loopback-source
attribute, the corresponding stream in the response will 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
 End of changes. 12 change blocks. 
37 lines changed or deleted 32 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/