draft-ietf-mmusic-media-loopback-01.txt   draft-ietf-mmusic-media-loopback-02.txt 
K. Hedayat K. Hedayat
Internet Draft Brix Networks Internet Draft Brix Networks
Expires: December 27,2005 P. Jones Expires: May 11, 2006 P. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
A. Roychowdhury A. Roychowdhury
Flextronics Software Systems Flextronics Software Systems
C. SivaChelvan C. SivaChelvan
Cisco Systems, Inc. Cisco Systems, Inc.
N. Stratton N. Stratton
BroadVoice BroadVoice
June 27, 2005 November 7, 2005
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-01.txt draft-ietf-mmusic-media-loopback-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
to the analog interface and after the decoder so that the RTP to the analog interface and after the decoder so that the RTP
packets are subsequently re-encoded prior to transmission back to packets are subsequently re-encoded prior to transmission back to
the sender. the sender.
rtp-start-loopback: In certain scenarios it is possible that the rtp-start-loopback: In certain scenarios it is possible that the
media transmitted by the offering entity is blocked by a network media transmitted by the offering entity is blocked by a network
element until the answering entity starts transmitting packets. element until the answering entity starts transmitting packets.
One example of this scenario is the presence of an RTP relay in the One example of this scenario is the presence of an RTP relay in the
path of the media. RTP relays exist in VoIP networks for purpose path of the media. RTP relays exist in VoIP networks for purpose
of NAT and Firewall traversal. If an RTP relay is present the of NAT and Firewall traversal. If an RTP relay is present the
offering entitys packets are dropped by the RTP relay until the offering entitys packets are dropped by the RTP relay until the
answering entity has started transmitting media and the media state answering entity has started transmitting media and the media state
within the RTP relay is established. This loopback attribute is within the RTP relay is established. This loopback attribute is
used to specify the media type for transmitting media packets by used to specify the media type for transmitting media packets by
the answering entity prior to the loopback process for the purpose the answering entity prior to the loopback process for the purpose
of setting media state within the network. In the presence of this of setting media state within the network. In the presence of this
loopback attribute the answering entity will transmit media, loopback attribute the answering entity will transmit media,
according to the description that contains this attribute, until it according to the description that contains this attribute, until it
receives media from the offering entity. After the first media receives media from the offering entity. After the first media
packet is received from the offering entity, the answering entity packet is received from the offering entity, the answering entity
MUST terminate the transmission of rtp-start-loopback media and MUST terminate the transmission of rtp-start-loopback media and
skipping to change at page 6, line 31 skipping to change at page 6, line 31
loopback-source: This attribute specifies that the sender is the loopback-source: This attribute specifies that the sender is the
media source and expects the receiver to act as a loopback-mirror. media source and expects the receiver to act as a loopback-mirror.
loopback-mirror: This attribute specifies that the receiver will loopback-mirror: This attribute specifies that the receiver will
mirror (echo) all received media back to the sender of the RTP mirror (echo) all received media back to the sender of the RTP
stream. No media is generated locally by the reciver for stream. No media is generated locally by the reciver for
transmission in the mirrored stream. transmission in the mirrored stream.
The loopback mode attribute does not apply to rtp-start-loopback The loopback mode attribute does not apply to rtp-start-loopback
attribute and MAY be omitted. If the loopback mode attribute is attribute and MUST be ignored if received by the answering entityt.
present with the rtp-start-loopback attribute it MUST be ignored by
the answering entity.
5.3 Generating the Offer for Loopback Session 5.3 Generating the Offer for Loopback Session
If an offerer wishes to make a loopback request, it MUST include If an offerer wishes to make a loopback request, it MUST include
both the loopback-type and loopback-mode attribute in a valid SDP both the loopback-type and loopback-mode attribute in a valid SDP
offer: offer:
Example: a=loopback:rtp-media-loopback Example: a=loopback:rtp-media-loopback
a=loopback-source a=loopback-source
skipping to change at page 8, line 6 skipping to change at page 8, line 6
a=loopback:rtp-media-loopback rtp-pkt-loopback a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-source a=loopback-source
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:
a=loopback:rtp-media-loopback a=loopback:rtp-media-loopback
a=loopback-mirror a=loopback-mirror
5.4.1 Rejecting the Loopback Offer 5.4.1 Rejecting the Loopback Offer
An offered stream with loopback-source MAY be rejected, if the An offered stream with loopback-source MAY be rejected if the
loopback-type is not specified, the specified loopback-type is not loopback-type is not specified, the specified loopback-type is not
supported, or the endpoint cannot honor the offer for any other supported, or the endpoint cannot honor the offer for any other
reason. The Loopback request may be rejected by setting the media reason. The Loopback request may be rejected by setting the media
port number to zero, according to RFC 3264 [RFC3264], in the port number to zero in the answer as per RFC 3264 [RFC3264].
answer.
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. In addition, answer to a loopback-mirror MUST be loopback-source. In addition,
the "m=" line MUST contain at least one codec that the answerer is the "m=" line MUST contain at least one codec that the answerer is
willing to both send and receive. willing to both send and receive.
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 or contains any other standard mode attributes,
skipping to change at page 9, line 4 skipping to change at page 8, line 43
An answering entitity that is compliant to this specification and An answering entitity that is compliant to this specification and
accepting a media with rtp-pkt-loopback loopback-type MUST accepting a media with rtp-pkt-loopback loopback-type MUST
re-generate all of the RTP header fields as it does when re-generate all of the RTP header fields as it does when
transmitting other media. However, the answering entity MUST transmitting other media. However, the answering entity MUST
maintain the timing information of the received RTP packets when maintain the timing information of the received RTP packets when
generating the RTP timestamp for the transmit packets. Maintaining generating the RTP timestamp for the transmit packets. Maintaining
the timing information of the RTP packets enables the offerer to the timing information of the RTP packets enables the offerer to
re-construct the incoming media and take account for impairments re-construct the incoming media and take account for impairments
from gaps in the media due to packet loss. Note that RTP Sequence from gaps in the media due to packet loss. Note that RTP Sequence
numbers are re-generated by the UAS and will not provide packet numbers are re-generated by the answering entity and will not
loss information to the receiver of the loopback media. provide packet loss information to the receiver of the loopback
media.
An answering entity that is compliant to this specification and An answering entity that is compliant to this specification and
accepting a media with rtp-media-loopback loopback-type MUST accepting a media with rtp-media-loopback loopback-type MUST
transmit all received media back to the sender . The incoming media transmit all received media back to the sender . The incoming media
MUST be treated as if it were to be played (e.g. the media stream MUST be treated as if it were to be played (e.g. the media stream
MAY receive treatment from PLC algorithms). The answering entity MAY receive treatment from PLC algorithms). The answering entity
MUST re-generate all the RTP header fields as it would when MUST re-generate all the RTP header fields as it would when
transmitting media. The UAS MAY choose to encode the loopback media transmitting media. The answering entity MAY choose to encode the
according to any of the media descriptions supported by the UAC. loopback media according to any of the media descriptions supported
Furthermore, in cases where the same media type is looped back, the by the offering entity. Furthermore, in cases where the same media
UAS MAY choose to preserve number of frames/packet and bitrate of type is looped back, the answering entity MAY choose to preserve
the encoded media according to the received media. number of frames/packet and bitrate of the encoded media according
to the received media.
7. RTCP Requirements 7. 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 entity that is answering entities. An offering or answering entity that is
compliant to this specification SHOULD support RTCP per [RFC3550] compliant to this specification SHOULD support RTCP per [RFC3550]
and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or and RTCP-XR per RFC 3611 [RFC3611]. Furthermore, if the client or
the server choose to support RTCP-XR, they SHOULD support RTCP-XR the server choose to support RTCP-XR, they SHOULD support RTCP-XR
Statistics Summary Report Block and VoIP Metric Reports Block per Loss RLE report block, Duplicate RLE report block, Statistics
sections 4.6 and 4.7 of RFC 3611 [RFC3611]. The client and the Summary report block, and VoIP Metric Reports Block per sections
4.1, 4.2, 4.6, and 4.7 of RFC 3611 [RFC3611]. The client and the
server MAY support other RTCP-XR reporting blocks as defined by RFC server MAY support other RTCP-XR reporting blocks as defined by RFC
3611 [RFC3611]. 3611 [RFC3611].
8. Examples 8. Examples
This section provides examples for media descriptions using SDP for This section provides examples for media descriptions using SDP for
different scenarios. The examples are given for SIP based different scenarios. The examples are given for SIP-based
transactions and are abbreviated and do not show the complete transactions and are abbreviated and do not show the complete
signaling for convenience. signaling for convenience.
8.1 Offer for specific media loopback type 8.1 Offer for specific media loopback type
A client sends an INVITE request with SDP which looks like: A client sends an INVITE request with SDP which looks like:
v=0 v=0
o=user1 2890844526 2890842807 IN IP4 126.16.64.4 o=user1 2890844526 2890842807 IN IP4 126.16.64.4
s=Example s=Example
skipping to change at page 15, line 6 skipping to change at page 15, line 6
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, STD 1, July 2003. Applications", RFC 3550, STD 1, July 2003.
[RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R., [RFC3611] Almeroth, K., Caceres, R., Clark, A., Cole, R.,
Duffield, N., Friedman, T., Hedayat, K., Sarac, K. Duffield, N., Friedman, T., Hedayat, K., Sarac, K.
and M. Westerlund, "RTP Control Protocol Extended and M. Westerlund, "RTP Control Protocol Extended
Reports (RTCP XR)", RFC 3611, STD 1, November 2003. Reports (RTCP XR)", RFC 3611, STD 1, November 2003.
[RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax [RFC2234] Crocker, P. Overell, "Augmented ABNF for Syntax
Specification: ABNF, RFC 3611, STD 1, November 1997. Specification: ABNF, RFC 3611, STD 1, November 1997.
Authors' Addresses Authors' Addresses
Kaynam Hedayat Kaynam Hedayat
Brix Networks Brix Networks
285 Mill Road 285 Mill Road
Chelmsford, MA 01824 Chelmsford, MA 01824
US US
Phone: +1 978 367 5611 Phone: +1 978 367 5611
skipping to change at page 16, line 13 skipping to change at page 16, line 13
EMail: chelliah@cisco.com EMail: chelliah@cisco.com
URI: http://www.cisco.com/ URI: http://www.cisco.com/
Nathan Stratton Nathan Stratton
BroadVoice BroadVoice
900 Chelmsford Street 900 Chelmsford Street
Tower Three Tower Three
Lowell, MA 01851 Lowell, MA 01851
US US
Phone: +1 978 418 7320 Phone: +1 410 908 7587
EMail: nstratton@broadvoice.com EMail: nathan@robotics.net
URI: http://www.broadvoice.com/ URI: http://www.broadvoice.com/
IPR Disclosure Acknowledgement IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
 End of changes. 13 change blocks. 
23 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/