Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-toffset-00.txt

From: [email-masked]
Date: Tue, 22 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 Audio/Video Transport Working Group of the IETF.

	Title		: Transmission Time offsets in RTP streams
	Author(s)	: D. Singer
	Filename	: draft-ietf-avt-rtp-toffset-00.txt
	Pages		: 15
	Date		: 2006-8-22
	
   This document describes a method to inform RTP clients when RTP
   packets are transmitted at a time other than their 'nominal'
   transmission time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-00.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-avt-rtp-toffset-00.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-avt-rtp-toffset-00.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.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Aug 2006 12:11:43 +0100

Dave,

> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-toffset-00.txt

In the introduction, it's mentioned that retransmission timestamps  
will be  different to the original timestamp, but I'd expect them to  
have the same?

Section 3 mentions middleboxes that might edit the toffset field. I  
agree that this is a possibility, but I'd suggest this draft stay  
silent on the subject. More interesting is the behaviour if more than  
one toffset is present in the packet: do they sum?

In section 4, it might be useful to clarify that "may be sent after  
the reception report" means it goes later in the compound packet,  
rather than being sent as a separate RTCP packet.

Otherwise this looks good.

Cheers,
Colin

---

From: Dave Singer <[email-masked]>
Date: Fri, 25 Aug 2006 11:58:47 -0700

>will be  different to the original timestamp, but I'd expect them to 

the timestamp will be the same, yes.  The actual transmission time is 
very different, is what I was trying to say.

>silent on the subject. More interesting is the behaviour if more 
>than one toffset is present in the packet: do they sum?

This is my only open question. Do we allow middleboxes to add them, 
and then they sum?

>rather than being sent as a separate RTCP packet.

Thanks, yes.

-- 
David Singer
Apple Computer/QuickTime

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 25 Aug 2006 13:54:25 -0700

> This is my only open question. Do we allow middleboxes to add them,

Allowing intermediate nodes to sum would result in inaccurate report
(RTCP) of extended inter-arrival jitter introduced by the network. The
resultant delay (offset) due to events at the intermediate nodes should
anyways be interpreted as network introduced delay at the terminating
receiver.

I fail to see how multiple toffset value can be of any benefit to the
terminating receiver. Allowing this would create more mess and it will
lead to tougher interpretation in future. Some nodes may append
additional toffset and some may try to replace the existing toffset and
so on...

I prefer to add something close to the below statements.

Intermediate nodes (like a traffic smoothing proxy) MUST not modify the
value of this field. Intermediate nodes in the IP path MUST not add this
field. Only an RTP stream originator can add this field to the RTP
header. RTP stream originators include RTP mixers and media gateways
which perform transcoding.

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

---

From: Ron Frederick <[email-masked]>
Date: Fri, 25 Aug 2006 16:31:44 -0700

> which perform transcoding.

This sounds good to me. It makes sense that an RTP mixer and/or 
translator might want to provide this value, as it would be 
resychronizing one or more streams and then possibly introducing a 
completely different delay between "sampling instant" and the transmit 
time of its new RTP stream. In such a case, though, the mixer must make 
sure to remove any toffset value it receives when forwarding RTCP 
information, providing only its own value for this field (if any).
-- 
Ron Frederick
[email-masked]