draft-ietf-mmusic-media-loopback-22.txt   draft-ietf-mmusic-media-loopback-23.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: February 7, 2013 EXFO Expires: March 9, 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.
August 7, 2012 September 9, 2012
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-22 draft-ietf-mmusic-media-loopback-23
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 41 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 February 7, 2013. This Internet-Draft will expire on March 9, 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 22 skipping to change at page 3, line 22
5.1 Generating the SDP Offer for Loopback Session.............9 5.1 Generating the SDP Offer for Loopback Session.............9
5.2 Generating the SDP Answer for Loopback Session...........10 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....................................12 5.4 Modifying the Session....................................12
5.5 Establishing Sessions Between Entities Behind NAT........12 5.5 Establishing Sessions Between Entities Behind NAT........12
6. RTP Requirements.............................................13 6. RTP Requirements.............................................13
7. Payload formats for Packet loopback..........................13 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.......................16 7.2 Direct loopback RTP payload format.......................16
8. SRTP Behavior................................................17 8. SRTP Behavior................................................17
9. RTCP Requirements............................................17 9. RTCP Requirements............................................18
10. Congestion Control..........................................18 10. Congestion Control..........................................18
11. Examples....................................................18 11. Examples....................................................18
11.1 Offer for specific media loopback type..................18 11.1 Offer for specific media loopback type..................18
11.2 Offer for choice of media loopback type.................19 11.2 Offer for choice of media loopback type.................19
11.3 Answerer rejecting loopback media.......................20 11.3 Answerer rejecting loopback media.......................20
12. Security Considerations.....................................20 12. Security Considerations.....................................21
13. Implementation Considerations...............................21 13. Implementation Considerations...............................21
14. IANA Considerations.........................................22 14. IANA Considerations.........................................22
[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]..........................................22 number on publication]..........................................22
14.1 SDP Attributes..........................................22 14.1 SDP Attributes..........................................22
14.2 Media Types.............................................23 14.2 Media Types.............................................23
15. Acknowledgements............................................31 15. Acknowledgements............................................31
16. Normative References........................................31 16. Normative References........................................31
17. Informative References......................................32 17. Informative References......................................32
skipping to change at page 4, line 8 skipping to change at page 4, line 8
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
session. This type of "active monitoring" of services is a method session. This type of "active monitoring" of services is a method
of proactively 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, Text or Video over IP session. A way to achieve this goal is VoIP, Text or Video over IP session. A way to achieve this goal is
to request an endpoint to loop media back to the other endpoint and to request an endpoint to loop media back to the other endpoint and
to provide media statistics (e.g., RTCP and RTCP XR information). to provide media statistics (e.g., RTCP and RTCP-XR information).
Another method involves deployment of special endpoints that always Another method involves deployment of special endpoints that always
loop incoming media back for sessions. Although the latter method loop incoming media back for all sessions. Although the latter
has been used and is functional, it does not scale to support large method has been used and is functional, it does not scale to
networks and introduces new network management challenges. support large networks and introduces new network management
Further, it does not offer the granularity of testing a specific challenges. Further, it does not offer the granularity of testing
endpoint that may be exhibiting problems. a specific endpoint that may be exhibiting problems.
The extension defined in this document introduces new SDP media The extension defined in this document introduces new SDP media
types and attributes that enable establishment of media sessions types and attributes that enable establishment of media sessions
where the media is looped back to the transmitter. The SDP where the media is looped back to the transmitter. The SDP
offer/answer model [RFC3264] is used to establish a loopback offer/answer model [RFC3264] is used to establish a loopback
connection. Furthermore, this extension provides guidelines on connection. Furthermore, this extension provides guidelines on
handling RTP [RFC3550], as well as usage of RTCP [RFC3550] and RTCP handling RTP [RFC3550], as well as usage of RTP Control Protocol
XR [RFC3611] for reporting media related measurements. (RTCP) [RFC3550] and RTCP Extended Reports (RTCP-XR) [RFC3611] for
reporting media related measurements.
1.1 Use Cases Supported 1.1 Use Cases Supported
As a matter of terminology in this document, packets flow from one As a matter of terminology in this document, packets flow from one
peer acting as a "loopback source", to the other peer acting as a peer acting as a "loopback source", to the other peer acting as a
"loopback mirror", which in turn returns packets to the loopback "loopback mirror", which in turn returns packets to the loopback
source. In advance of the session, the peers negotiate to determine source. In advance of the session, the peers negotiate to determine
which one acts in which role, using the SDP offer/answer exchange. which one acts in which role, using the SDP offer/answer exchange.
The negotiation also includes details such as the type of loopback The negotiation also includes details such as the type of loopback
to be used. to be used.
skipping to change at page 5, line 10 skipping to change at page 5, line 11
encapsulated packet is returned to the loopback source. The encapsulated packet is returned to the loopback source. The
loopback source can generate statistics for one-way path loopback source can generate statistics for one-way path
performance up to the RTP level for each direction of travel by performance up to the RTP level for each direction of travel by
examining sequence numbers and timestamps in the encapsulating examining sequence numbers and timestamps in the encapsulating
outer RTP header and the encapsulated RTP packet payload. The outer RTP header and the encapsulated RTP packet payload. The
loopback source can also play back the returned media content for loopback source can also play back the returned media content for
evaluation. evaluation.
Because the encapsulating RTP packet header extends the packet Because the encapsulating RTP packet header extends the packet
size, it could encounter difficulties in an environment where the size, it could encounter difficulties in an environment where the
original RTP packet size is close to the path MTU size. The original RTP packet size is close to the path Maximum Transmission
encapsulating payload format therefore offers the possibility of Unit (MTU) size. The encapsulating payload format therefore offers
RTP-level fragmentation of the returned packets. The use of this the possibility of RTP-level fragmentation of the returned packets.
facility could affect statistics derived for the return path. In The use of this facility could affect statistics derived for the
addition, the increased bit rate required in the return direction return path. In addition, the increased bit rate required in the
may affect these statistics more directly in a restricted-bandwidth return direction may affect these statistics more directly in a
situation. restricted-bandwidth situation.
1.1.2 Direct Loopback 1.1.2 Direct Loopback
In the direct loopback case, the loopback mirror copies the payload In the direct loopback case, the loopback mirror copies the payload
of the incoming RTP packet into a new RTP packet, using a payload of the incoming RTP packet into a new RTP packet, using a payload
format specific to this use case and specified in Section 7.2. The format specific to this use case and specified in Section 7.2. The
loopback mirror returns the new packet to the packet source. There loopback mirror returns the new packet to the packet source. There
is no provision in this case for RTP-level fragmentation. is no provision in this case for RTP-level fragmentation.
This use case has the advantage of keeping the packet size the same This use case has the advantage of keeping the packet size the same
skipping to change at page 6, line 45 skipping to change at page 6, line 46
there is no further choice of encoding format - there is only one there is no further choice of encoding format - there is only one
format: whatever is indicated for normal media, since the "looping" format: whatever is indicated for normal media, since the "looping"
is performed at the codec level. When packet-level looping is is performed at the codec level. When packet-level looping is
performed, however, the mirror can either send back RTP in an performed, however, the mirror can either send back RTP in an
encapsulated format or direct-loopback format. The rest of this encapsulated format or direct-loopback format. The rest of this
document describes these loopback types, roles, and encoding document describes these loopback types, roles, and encoding
formats, and the SDP offer/answer rules for indicating them. formats, and the SDP offer/answer rules for indicating them.
3.1 SDP Offerer Behavior 3.1 SDP Offerer Behavior
An SDP offerer compliant to this memo and attempting to establish a An SDP offerer compliant to this specification and attempting to
media session with media loopback MUST include "loopback" media establish a media session with media loopback MUST include
attributes for each individual media description in the offer "loopback" media attributes for each individual media description
message. The offerer MUST look for the "loopback" media attributes in the offer message. The offerer MUST look for the "loopback"
in the media description(s) of the response from the answer for media attributes in the media description(s) of the response from
confirmation that the request is accepted. the answer for confirmation that the request is accepted.
3.2 SDP Answerer Behavior 3.2 SDP Answerer Behavior
An SDP answerer compliant to this specification and receiving an An SDP answerer compliant to this specification and receiving an
offer containing media descriptions with the "loopback" media 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
answer if it agrees to do the loopback. If the answerer does not answer if it agrees to do the loopback. If the answerer does not
want to do loopback or wants to reject the "loopback" request for want to do loopback or wants to reject the "loopback" request for
specific media descriptions, it MUST do so as defined in this specific media descriptions, it MUST do so as defined in this
skipping to change at page 7, line 40 skipping to change at page 7, line 41
"normal" RTP session, it would need to terminate the session upon "normal" RTP session, it would need to terminate the session upon
receiving such an answer. receiving such an answer.
4. New SDP Attributes 4. New SDP Attributes
Three new SDP media-level attributes are defined: one indicates the Three new SDP media-level attributes are defined: one indicates the
type of loopback, and the other two define the role of the agent. type of loopback, and the other two define the role of the agent.
4.1 Loopback Type Attribute 4.1 Loopback Type Attribute
This specification defines a new 'loopback' attribute, which This specification defines a new "loopback" attribute, which
indicates that the agent wishes to perform loopback, and the type indicates that the agent wishes to perform loopback, and the type
of loopack that the agent is able to do. The loopback-type is a of loopack that the agent is able to do. The loopback-type is a
value media attribute [RFC4566] with the following syntax: value media attribute [RFC4566] with the following 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:
attribute /= loopback-attr attribute /= loopback-attr
; attribute defined in RFC 4566 ; attribute defined in RFC 4566
skipping to change at page 9, line 39 skipping to change at page 9, line 40
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
direction mode is "sendrecv"; the "sendrecv" direction attribute direction mode is "sendrecv"; the "sendrecv" direction attribute
MAY be encoded in SDP or not, as per section 5.1 of [RFC3264], MAY be encoded in SDP or not, as per Section 5.1 of [RFC3264],
since it is implied by default. If either the loopback source or since it is implied by default. If either the loopback source or
mirror wish to disable loopback use during a session, the direction mirror wish to disable loopback use during a session, the direction
mode attribute "inactive" MUST be used as per [RFC3264]. The mode attribute "inactive" MUST be used as per [RFC3264]. The
direction mode attributes "recvonly" and "sendonly" are direction mode attributes "recvonly" and "sendonly" are
incompatible with the loopback mechanism and MUST NOT be indicated incompatible with the loopback mechanism and MUST NOT be indicated
when generating an SDP Offer or Answer. When receiving an SDP when generating an SDP Offer or Answer. When receiving an SDP
Offer or Answer, if "recvonly" or "sendonly" is indicated for Offer or Answer, if "recvonly" or "sendonly" is indicated for
loopback, the SDP-receiving agent SHOULD treat it as a protocol loopback, the SDP-receiving agent SHOULD treat it as a protocol
failure of the loopback negotiation and terminate the session failure of the loopback negotiation and terminate the session
through its normal means (e.g., by sending a SIP BYE if SIP is through its normal means (e.g., by sending a SIP BYE if SIP is
skipping to change at page 10, line 16 skipping to change at page 10, line 18
The port number and the address in the offer (m/c= lines) indicate The port number and the address in the offer (m/c= lines) indicate
where the offerer would like to receive the media stream(s). The where the offerer would like to receive the media stream(s). The
payload type numbers indicate the value of the payload the offerer payload type numbers indicate the value of the payload the offerer
expects to receive. However, the answer might indicate a subset of expects to receive. However, the answer might indicate a subset of
payload type numbers from those given in the offer. In that case, payload type numbers from those given in the offer. In that case,
the offerer MUST only send the payload types received in the the offerer MUST only send the payload types received in the
answer, per normal SDP offer/answer rules. answer, per normal SDP offer/answer rules.
If the offer indicates rtp-pkt-loopback support, the offer MUST If the offer indicates rtp-pkt-loopback support, the offer MUST
also contain either an encapsulated or direct loopback encoding also contain either an encapsulated or direct loopback encoding
format encoding name, or both, as defined in later sections of this format encoding name, or both, as defined in Sections 7.1 and 7.2
document. If the offer only indicates rtp-media-loopback support, of this document. If the offer only indicates rtp-media-loopback
then neither encapsulated nor direct loopback encoding formats support, then neither encapsulated nor direct loopback encoding
apply and they MUST NOT be in the offer. formats apply and they MUST NOT be in the offer.
If loopback-type is rtp-pkt-loopback, the loopback-mirror MUST send If loopback-type is rtp-pkt-loopback, the loopback-mirror MUST send
and the loopback-source MUST receive the looped back packets and the loopback-source MUST receive the looped back packets
encoded in one of the two payload formats (encapsulated RTP or encoded in one of the two payload formats (encapsulated RTP or
direct loopback) as defined in section 7. direct loopback) as defined in Section 7.
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 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
skipping to change at page 11, line 39 skipping to change at page 11, line 41
a=loopback-source a=loopback-source
a=rtpmap:112 encaprtp/8000 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 12345 RTP/AVP 0 8 m=audio 12345 RTP/AVP 0 8
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror a=loopback-mirror
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
direct loopback RTP payload format MUST be used for looped back direct loopback RTP payload format MUST be used for looped back
packets. packets.
For example, if the offer contains: For example, if the offer contains:
m=audio 41352 RTP/AVP 0 8 112 113 m=audio 41352 RTP/AVP 0 8 112 113
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-source a=loopback-source
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
skipping to change at page 12, line 19 skipping to change at page 12, line 19
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror a=loopback-mirror
a=rtpmap:112 encaprtp/8000 a=rtpmap:112 encaprtp/8000
m=audio 12345 RTP/AVP 0 8 113 m=audio 12345 RTP/AVP 0 8 113
a=loopback:rtp-pkt-loopback a=loopback:rtp-pkt-loopback
a=loopback-mirror a=loopback-mirror
a=rtpmap:113 rtploopback/8000 a=rtpmap:113 rtploopback/8000
The previous examples used the 'encaprtp' and 'rtploopback' The previous examples used the 'encaprtp' and 'rtploopback'
encoding names, which will be defined in sections 7.1.3 and 7.2.3. encoding names, which will be defined in Sections 7.1.3 and 7.2.3.
5.3 Offerer Processing of the SDP Answer 5.3 Offerer Processing of the SDP Answer
If the received SDP answer does not contain an a=loopback-mirror or If the received SDP answer does not contain an a=loopback-mirror or
a=loopback-source attribute, it is assumed that the loopback a=loopback-source attribute, it is assumed that the loopback
extensions are not supported by the remote agent. This is not a extensions are not supported by the remote agent. This is not a
protocol failure, and instead merely completes the SDP offer/answer protocol failure, and instead merely completes the SDP offer/answer
exchange with whatever normal rules apply; the offerer MAY decide exchange with whatever normal rules apply; the offerer MAY decide
to end the established RTP session (if any) through normal means of to end the established RTP session (if any) through normal means of
the upper-layer signaling protocol (e.g., by sending a SIP BYE). the upper-layer signaling protocol (e.g., by sending a SIP BYE).
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 ICE/STUN/TURN provide a general solution to establishing media
sessions between entities that are behind NATs, as defined in sessions between entities that are behind Network Address
[RFC5245]. Loopback sessions that involve one or more endpoints Translators (NATs), as defined in [RFC5245]. Loopback sessions that
behind NATs SHOULD use these general solutions wherever possible. involve one or more endpoints behind NATs SHOULD use these general
solutions wherever possible.
Furthermore, if the mirroring entity is behind a NAT, it MUST send Furthermore, if the mirroring entity is behind a NAT, it MUST send
some packets to the identified address/port(s) of the peer, in some packets to the identified address/port(s) of the peer, in
order to open the NAT pinhole. Using ICE this would be order to open the NAT pinhole. Using Interactive Connectivity
accomplished with the STUN connectivity check process, or through a Establishment (ICE) [RFC5245] this would be accomplished with the
TURN server connection. If ICE is not supported, either [RFC6263] STUN connectivity check process, or through a TURN server
or Section 10 of ICE [RFC5245] SHOULD be followed to open the connection. If ICE is not supported, either [RFC6263] or Section
pinhole and keep the NAT binding alive/refreshed. 10 of ICE [RFC5245] SHOULD 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. In other words both agents MUST
send packets from the source address and port they receive packets send packets from the source address and port they receive packets
on. on.
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 MUST loopback the accepts media with rtp-pkt-loopback loopback type MUST loopback the
incoming RTP packets using either the encapsulated RTP payload 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.
A device that is compliant to this specification and performing the A device that is compliant to this specification and performing the
mirroring using the loopback type rtp-media-loopback MUST transmit mirroring using the loopback type rtp-media-loopback MUST transmit
all received media back to the sender, unless congestion feedback all received media back to the sender, unless congestion feedback
or other lower-layer constraints prevent it from doing so. The or other lower-layer constraints prevent it from doing so. The
incoming media MUST be treated as if it were to be played (e.g. the incoming media MUST be treated as if it were to be played; for
media stream MAY receive treatment from PLC algorithms). The example, the media stream MAY receive treatment from Packet Loss
mirroring entity MUST re-generate all the RTP header fields as it Concealment (PLC) algorithms. The mirroring entity MUST re-
would when transmitting media. The mirroring entity MAY choose to generate all the RTP header fields as it would when transmitting
encode the loopback media according to any of the media media. The mirroring entity MAY choose to encode the loopback media
descriptions supported by the offering entity. Furthermore, in according to any of the media descriptions supported by the
cases where the same media type is looped back, the mirroring offering entity. Furthermore, in cases where the same media type is
entity MAY choose to preserve number of frames/packet and bitrate looped back, the mirroring entity MAY choose to preserve number of
of the encoded media according to the received media. frames/packet and bitrate of the encoded media according to the
received media.
7. Payload formats for Packet loopback 7. Payload formats for Packet loopback
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 requirements prevent the use of should be used when bandwidth requirements prevent the use of
encapsulated RTP payload format. encapsulated RTP payload format.
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 separate encapsulating RTP packet; the MUST be encapsulated in a separate encapsulating RTP packet; the
encapsulated packet MUST be fragmented only if required (for encapsulated packet MUST be fragmented only if required (for
example: due to MTU limitations). example: due to MTU limitations).
7.1.1 Usage of RTP Header fields 7.1.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.1.3 defines the name binding). SDP; Section 7.1.3 defines the name binding).
Marker (M) bit: If the received RTP packet is looped back in Marker (M) bit: If the received RTP packet is looped back in
multiple encapsulating RTP packets, the M bit is set to 1 in every multiple encapsulating RTP packets, the M bit is set to 1 in every
fragment except the last packet, otherwise it is set to 0. fragment except the last packet, otherwise it is set to 0.
Extension (X) bit: Defined by the RTP Profile used. Extension (X) bit: Defined by the RTP Profile used.
Sequence Number: The RTP sequence number SHOULD be generated by the Sequence Number: The RTP sequence number SHOULD be generated by the
loopback-mirror in the usual manner with a constant random offset loopback-mirror in the usual manner with a constant random offset
as described in RFC 3550 [RFC3550]. as described in RFC 3550 [RFC3550].
skipping to change at page 15, line 25 skipping to change at page 15, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | R | CC |M| PT | sequence number | | F | R | CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| transmit timestamp | | transmit timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers | | contributing source (CSRC) identifiers |
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Encapsulating RTP Packet Payload Header
The 12 octets after the receive timestamp are identical to the The 12 octets after the receive timestamp are identical to the
encapsulated RTP header of the received packet except for the first encapsulated RTP header of the received packet except for the first
2 bits of the first octet. In effect, the received RTP packet is 2 bits of the first octet. In effect, the received RTP packet is
encapsulated by creating a new outer RTP header followed by 4 new encapsulated by creating a new outer RTP header followed by 4 new
bytes of a receive timestamp, followed by the original received RTP bytes of a receive timestamp, followed by the original received RTP
header and payload, except that the first two bits of the received header and payload, except that the first two bits of the received
RTP header are overwritten as defined here. RTP header are overwritten as defined here.
Receive Timestamp: 32 bits Receive Timestamp: 32 bits
The Receive timestamp denotes the sampling instant for when the The Receive timestamp denotes the sampling instant for when the
last octet of the received media packet that is being encapsulated last octet of the received media packet that is being encapsulated
by the loopback-mirror is received from the loopback-source. The by the loopback-mirror is received from the loopback-source. The
same clock rate MUST used by the loopback-source. The initial same clock rate MUST be used by the loopback-source. The initial
value of the timestamp SHOULD be random for security reasons (see value of the timestamp SHOULD be random for security reasons (see
Section 5.1 of RFC 3550 [RFC3550]). Section 5.1 of RFC 3550 [RFC3550]).
Fragmentation (F): 2 bits Fragmentation (F): 2 bits
First Fragment (00) /Last Fragment (01) /No Fragmentation(10)/ First Fragment (00) /Last Fragment (01) /No Fragmentation(10)/
Intermediate Fragment (11). This field identifies how much of the Intermediate Fragment (11). This field identifies how much of the
received packet is encapsulated in this packet by the loopback- received packet is encapsulated in this packet by the loopback-
mirror. If the received packet is not fragmented, this field is mirror. If the received packet is not fragmented, this field is
set to 10; otherwise the packet that contains the first fragments set to 10; otherwise the packet that contains the first fragments
skipping to change at page 16, line 38 skipping to change at page 16, line 42
sent to the mirror, in looped-back packets. Therefore, the sent to the mirror, in looped-back packets. Therefore, the
loopback source SHOULD only send one payload type per loopback RTP loopback source SHOULD only send one payload type per loopback RTP
session, if direct mode is used. session, if direct mode is used.
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 the Payload Type (PT): The assignment of an RTP payload type for the
encapsulating packet format is outside the scope of this document; encapsulating packet format is outside the scope of this document;
it is either specified by the RTP profile under which this payload it is either specified by the RTP profile under which this payload
format is used or more likely signaled dynamically out-of-band format is used or more likely signaled dynamically out-of-band
(e.g., using SDP; section 7.2.3 defines the name binding). (e.g., using 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.
Extension (X) bit: Defined by the RTP Profile used. Extension (X) bit: Defined by the RTP Profile used.
Sequence Number: The RTP sequence number SHOULD be generated by the Sequence Number: The RTP sequence number SHOULD be generated by the
loopback-mirror in the usual manner with a constant random offset, loopback-mirror in the usual manner with a constant random offset,
as per [RFC3550]. as per [RFC3550].
Timestamp: The RTP timestamp denotes the sampling instant for when Timestamp: The RTP timestamp denotes the sampling instant for when
skipping to change at page 18, line 9 skipping to change at page 18, line 14
9. RTCP Requirements 9. RTCP Requirements
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 agent that is answering entities. An offering or answering agent 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 offerer or and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the offerer or
answerer choose to support RTCP-XR, they SHOULD support RTCP-XR answerer choose to support RTCP-XR, they SHOULD support RTCP-XR
Loss RLE report block, Duplicate RLE report block, Statistics Loss Run Length Encoding (RLE) report block, Duplicate RLE report
Summary report block, and VoIP Metric Reports Block per sections block, Statistics Summary report block, and VoIP Metric Reports
4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The offerer and the Block per Sections 4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611].
answerer MAY support other RTCP-XR reporting blocks as defined by The offerer and the answerer MAY support other RTCP-XR reporting
RFC 3611 [RFC3611]. blocks as defined by RFC 3611 [RFC3611].
10. Congestion Control 10. Congestion Control
All the participants in a media-level loopback session SHOULD All the participants in a media-level loopback session SHOULD
implement congestion control mechanisms as defined by the RTP implement congestion control mechanisms as defined by the RTP
profile under which the loopback mechanism is implemented. For profile under which the loopback mechanism is implemented. For
audio video profiles, implementations SHOULD conform to the audio video profiles, implementations SHOULD conform to the
mechanism defined in Section 2 of RFC 3551 [RFC3551]. mechanism defined in Section 2 of RFC 3551 [RFC3551].
For packet-level loopback types, the loopback source SHOULD For packet-level loopback types, the loopback source SHOULD
skipping to change at page 22, line 30 skipping to change at page 22, line 34
Contact name: Kaynam Hedayat Contact name: Kaynam Hedayat
Email address: kaynam.hedayat@exfo.com Email address: kaynam.hedayat@exfo.com
Telephone number: +1-978-367-5611 Telephone number: +1-978-367-5611
Attribute name: loopback Attribute name: loopback
Type of attribute: Media level. Type of attribute: Media level.
Subject to charset: No. Subject to charset: No.
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 RFC XXXX for syntax. of RFC XXXX for syntax.
Contact name: Kaynam Hedayat Contact name: Kaynam Hedayat
Email address: kaynam.hedayat@exfo.com Email address: kaynam.hedayat@exfo.com
Telephone number: +1-978-367-5611 Telephone number: +1-978-367-5611
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
 End of changes. 30 change blocks. 
66 lines changed or deleted 70 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/