Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-media-loopback-04.txt

From: [email-masked]
Date: Tue, 01 Aug 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: An Extension to the Session Description Protocol (SDP) for Media Loopback
	Author(s)	: K. Hedayat, et al.
	Filename	: draft-ietf-mmusic-media-loopback-04.txt
	Pages		: 21
	Date		: 2006-8-1
	
The wide deployment of Voice over IP (VoIP), Real-time Text and 
Video over IP services has introduced new challenges in managing 
and maintaining voice/real-time Text/video quality, reliability, 
and overall performance.  In particular, media delivery is an area 
that needs attention.  One method of meeting these challenges is 
monitoring the media delivery performance by looping media back to 
the transmitter.  This is typically referred to as "active 
monitoring" of services.   Media loopback is especially popular in 
ensuring the quality of transport to the edge of a given VoIP, 
Real-time Text or Video over IP service.  Today in networks that 
deliver real-time media, short of running 'ping' and 'traceroute' 
to the edge, service providers are left without the necessary tools 
to actively monitor, manage, and diagnose quality issues with their 
service.  The extension defined herein adds new SDP media 
attributes which enables establishment of media sessions where the 
media is looped back to the transmitter. Such media sessions will 
serve as monitoring and troubleshooting tools by providing the 
means for measurement of more advanced VoIP, Real-time Text and 
Video Over IP performance metrics.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-loopback-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-media-loopback-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-media-loopback-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 2 Aug 2006 00:46:38 -0400

Hi Kaynam,
I read the latest draft and I've got some comments. 

1) This appears to revert to a previous draft version, which encapsulated
the received RTP.  I thought based on previous comments, that draft-03
changed to not encap, but rather sent the same RTP back with a different
ssrc.  What's the reason for the change in 04 back again?

2) Section 7.2 says "The RTP header in the encapsulated packet MUST be
followed by the payload header defined in this section."  That confuses me
greatly.  The RTP header in the _encapsulated_ packet is the one sent by the
loopback-source, and put into the payload of the response RTP packet.  So
are you saying the mirror takes the received RTP packet, sticks the header
defined in section 7.2 after the RTP header of the received one but before
its original payload, and encaps that whole thing in another RTP packet as
the payload??  

3) Section 7.2 goes on to say "The 12 octets after the receive timestamp are
identical to the RTP header in the received packet except for the first 4
bits of the first octet."  So is this 7.2 header in addition to the
encapsulated header of the received RTP, or does it replace it?  I think an
example showing the received RTP packet and its mirror might help me a lot.
:)

4) Encapsulating the original RTP packet into another will obviously make
the responding RTP a different size.  While 12 additional bytes, or whatever
it will be based on your answer to 2 and 3 above, may not seem like much,
it's an additional 9.6Kbps for 10ms ptimes, and that may just be enough to
make its behavior different; especially if it goes through a policer or
really small links.  Fundamentally it's not the same as the equivalent codec
would be in a real call.  

5) Sections 7.1/7.2 say both receive and transmit timestamps generated by
the mirror must be based on the same clock used by the source.  Do you mean
same wallclock (e.g., NTP), or same sampler rate (e.g., 8kHz)?  I assume
just based on the same sampling rate clock, right?  So you can figure out
1-way jitter, but not 1-way delay.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Aug 2006 18:22:29 -0400

I haven't looked at this for several revs of the draft - its quite a bit 
different than the last time I looked.

I can't understand the description of the use of media formats in m-line 
vs in the loopback-source/loopback-mirror lines. But from looking at the 
examles, it seems that the use in the m-lines is inconsistent with 3264. 
When using rtp-pkt-loopback the might be:

offer:     m=audio 49170 RTP/AVP 0 112
answer:    m=audio 49170 RTP/AVP 112

which normally would have 112 being both sent and received, while here 
it means that the offerer sends 0 and receives 112, while the answerer 
receives 0 and sends 112.

Also, the use of rtp-start-loopback with a *different* m-line, but with 
the same port, also seems very strange.

How about the following approach as an alternative:

- the m-line in the offer and the answer reflect what is to happen 
initially (what rtp-start-loopback was previously used for). Normal 
directionality attributes can control whether it is done at all, one 
way, or two way. (I'm not sure two way makes much sense.)

- a=loopback-source/loopback-mirror negotiate what is to be done when 
loopback begins. The formats in m-line and these lines might have 
nothing in common.

	Paul