draft-ietf-mmusic-media-loopback-12.txt   draft-ietf-mmusic-media-loopback-13.txt 
Internet Draft K. Hedayat Internet Draft K. Hedayat
Expires: June 30, 2010 EXFO Expires: October 8, 2010 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.
January 30, 2010 April 8, 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-12 draft-ietf-mmusic-media-loopback-13
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 2, line 40 skipping to change at page 2, line 40
ensuring the quality of transport to the edge of a given VoIP, ensuring the quality of transport to the edge of a given VoIP,
Real-time Text or Video over IP service. Today in networks that Real-time Text or Video over IP service. Today in networks that
deliver real-time media, short of running 'ping' and 'traceroute' deliver real-time media, short of running 'ping' and 'traceroute'
to the edge, service providers are left without the necessary tools to the edge, service providers are left without the necessary tools
to actively monitor, manage, and diagnose quality issues with their to actively monitor, manage, and diagnose quality issues with their
service. The extension defined herein adds new SDP media service. The extension defined herein adds new SDP media
attributes which enables establishment of media sessions where the attributes which enables establishment of media sessions where the
media is looped back to the transmitter. Such media sessions will media is looped back to the transmitter. Such media sessions will
serve as monitoring and troubleshooting tools by providing the serve as monitoring and troubleshooting tools by providing the
means for measurement of more advanced VoIP, Real-time Text and means for measurement of more advanced VoIP, Real-time Text and
Video Over IP performance metrics. Video over IP performance metrics.
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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 ..................................... 20
13. Implementation Considerations ............................... 21 13. Implementation Considerations ............................... 21
14. IANA Considerations ......................................... 21 14. IANA Considerations ......................................... 21
14.1 SDP Attributes .......................................... 21 14.1 SDP Attributes .......................................... 21
14.2 MIME Types .............................................. 22 14.2 MIME Types .............................................. 22
15. Acknowledgements ............................................ 35 15. Acknowledgements ............................................ 36
16. Normative References ........................................ 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
session. This type of "active monitoring" of services is a method session. This type of "active monitoring" of services is a method
of pro-actively managing the performance and quality of VoIP based of proactively managing the performance and quality of VoIP based
services. services.
The goal of active monitoring is to measure the media quality of a The goal of active monitoring is to measure the media quality of a
VoIP, Real-time Text or Video over IP session. A way to achieve VoIP, Real-time Text or Video over IP session. A way to achieve
this goal is to request an endpoint to loop media back to the other this goal is to request an endpoint to loop media back to the other
endpoint and to provide media statistics (e.g., RTCP and RTCP XR endpoint and to provide media statistics (e.g., RTCP and RTCP XR
information). Another method involves deployment of special information). Another method involves deployment of special
endpoints that always loop incoming media back for sessions. endpoints that always loop incoming media back for sessions.
Although the latter method has been used and is functional, it does Although the latter method has been used and is functional, it does
not scale to support large networks and introduces new network not scale to support large networks and introduces new network
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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.4 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. If a stream is offered with loopback-source or answer. When a stream is offered with the loopback-source
loopback-mirror attributes, the corresponding stream MUST be attribute, the corresponding stream in the response MUST be
loopback-mirror or loopback-source respectively, provided that loopback-mirror and vice versa, provided that answerer is capable
answerer is capable of supporting the requested loopback-type. of supporting the requested loopback-type.
For example, if the offer contains: 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:0 8 a=loopback-source:0 8
The answer that is capable of supporting the offer MUST contain: The answer that is capable of supporting the offer MUST contain the
loopback-mirror 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-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 112 m=audio 41352 RTP/AVP 0 8
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
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
skipping to change at page 9, line 29 skipping to change at page 9, line 30
5.5 Offerer Processing of the Answer 5.5 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 or contains any other standard mode attributes, a=loopback-source, it is assumed that the loopback extensions are
it is assumed that the loopback extensions are not supported by the not supported by the target UA.
target UA.
5.6 Modifying the Session 5.6 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.7 Priming the loopback pump
skipping to change at page 12, line 23 skipping to change at page 12, line 23
CC and CSRC fields are used as described in RFC 3550 [RFC3550]. CC and CSRC fields are used as described in RFC 3550 [RFC3550].
7.1.2 RTP Payload Structure 7.1.2 RTP Payload Structure
The RTP header in the encapsulated packet MUST be followed by the The RTP header in the encapsulated packet MUST be followed by the
payload header defined in this section. If the received RTP packet payload header defined in this section. If the received RTP packet
has to be looped back in multiple packets due to fragmentation, the has to be looped back in multiple packets due to fragmentation, the
RTP header in each packet MUST be followed by the payload header RTP header in each packet MUST be followed by the payload header
defined in this section. The header is devised so that the defined in this section. The header is devised so that the
loopback-source can usefully decode looped back packets in the loopback-source can decode looped back packets in the presence of
presence of moderate packet loss [RFC3550]. moderate packet loss [RFC3550].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| receive timestamp | | receive timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | R | CC |M| PT | sequence number | | F | R | CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| transmit timestamp | | transmit timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 46 skipping to change at page 13, line 46
The following is an example SDP fragment for encapsulated RTP. The following is an example SDP fragment for encapsulated RTP.
m=audio 41352 RTP/AVP 112 m=audio 41352 RTP/AVP 112
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
7.2 Direct loopback RTP payload format 7.2 Direct loopback RTP payload format
The direct loopback RTP payload format can be used in scenarios The direct loopback RTP payload format can be used in scenarios
where the 16 byte overhead of the encapsulated payload format is where the 16 byte overhead of the encapsulated payload format is
significant. This payload format MUST not be used in cases where significant. This payload format MUST not be used in cases where
the MTU on the loopback path is less than the MTU on the transmit the MTU on the loopback path will cause fragmentation of looped
path. When using this payload format, the receiver MUST loop back back RTP packets. When using this payload format, the receiver
each received packet in a separate RTP packet. MUST loop back each received packet in a separate RTP packet.
7.2.1 Usage of RTP Header fields 7.2.1 Usage of RTP Header fields
Payload Type (PT): The assignment of an RTP payload type for this Payload Type (PT): The assignment of an RTP payload type for this
packet format is outside the scope of this document; it is either packet format is outside the scope of this document; it is either
specified by the RTP profile under which this payload format is specified by the RTP profile under which this payload format is
used or more likely signaled dynamically out-of-band (e.g., using used or more likely signaled dynamically out-of-band (e.g., using
SDP; section 7.2.3 defines the name binding). SDP; section 7.2.3 defines the name binding).
Marker (M) bit: Set to the value in the received packet. Marker (M) bit: Set to the value in the received packet.
skipping to change at page 14, line 45 skipping to change at page 15, line 5
portion of the packet received from the loopback-source. portion of the packet received from the loopback-source.
7.2.3 Usage of SDP 7.2.3 Usage of SDP
The payload type number for the payload loopback stream can be The payload type number for the payload loopback stream can be
negotiated using a mechanism like SDP. There is no static payload negotiated using a mechanism like SDP. There is no static payload
type assignment for the stream, so dynamic payload type numbers type assignment for the stream, so dynamic payload type numbers
MUST be used. The binding to the name is indicated by an rtpmap MUST be used. The binding to the name is indicated by an rtpmap
attribute. The name used in this binding is "rtploopback". attribute. The name used in this binding is "rtploopback".
The following is an example SDP fragment for encapsulated RTP. The following is an example SDP fragment for direct loopback RTP
format.
m=audio 41352 RTP/AVP 112 m=audio 41352 RTP/AVP 112
a=rtpmap:112 rtploopback/8000 a=rtpmap:112 rtploopback/8000
8. Payload format for Priming the Loopback Pump 8. Payload format for Priming the Loopback Pump
The sole purpose of the payload format described in this section is The sole purpose of the payload format described in this section is
to prime the loopback pump in cases where the loopback process to prime the loopback pump in cases where the loopback process
cannot start because of intermediate devices in the network as cannot start because of intermediate devices in the network as
described in Section 5.7. described in Section 5.7.
skipping to change at page 21, line 48 skipping to change at page 22, line 4
Purpose of attribute: The 'loopback' attribute is used to Purpose of attribute: The 'loopback' attribute is used to
indicate the type of media loopback. indicate the type of media loopback.
Allowed attribute values: The parameters to 'loopback' may be Allowed attribute values: The parameters to 'loopback' may be
one or more of "rtp-pkt-loopback" and one or more of "rtp-pkt-loopback" and
"rtp-media-loopback". See section 5 "rtp-media-loopback". See section 5
of this document for syntax. of this document for syntax.
Contact name: Kaynam Hedayat Contact name: Kaynam Hedayat
<kaynam.hedayat@exfo.com>. <kaynam.hedayat@exfo.com>.
Attribute name: "loopback-source". Attribute name: "loopback-source".
Type of attribute: Media level.
Type of attribute: Media level.
Subject to charset: No. Subject to charset: No.
Purpose of attribute: The 'loopback-source' attribute Purpose of attribute: The 'loopback-source' attribute
specifies that the sender is the media specifies that the sender is the media
source and expects the receiver to act source and expects the receiver to act
as a loopback-mirror. as a loopback-mirror.
Allowed attribute values: The parameter to 'loopback-source' is Allowed attribute values: The parameter to 'loopback-source' is
a media format ("<fmt>") description a media format ("<fmt>") description
as defined in RFC 4566 Section 5.14. as defined in RFC 4566 Section 5.14.
Contact name: Kaynam Hedayat Contact name: Kaynam Hedayat
 End of changes. 17 change blocks. 
23 lines changed or deleted 25 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/