Re: [AVT] Some comments to subsection 8.1.1 indraft-ietf-avt-rtp-svc-08

Colin,

Thanks. And I agreed with you - I did not suggest the need of new
mechanisms below. What I suggested is just a small editorial
improvement. 

BR, YK 

>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@csperkins.org] 
>Sent: Friday, March 28, 2008 12:39 PM
>To: Wang Ye-Kui (Nokia-NRC/Tampere)
>Cc: roni.even@polycom.co.il; avt@ietf.org
>Subject: Re: [AVT] Some comments to subsection 8.1.1 
>indraft-ietf-avt-rtp-svc-08
>
>Ye-Kui,
>
>Synchronisation and timestamp mapping across sessions is a 
>standard part of RTP. Again, no new mechanisms are needed.
>
>Colin
>
>
>
>On 28 Mar 2008, at 10:26, <Ye-Kui.Wang@nokia.com> wrote:
>>
>> Roni,
>>
>> But we are talking about session multiplexing, not about a single 
>> stream.
>>
>> BR, YK
>>
>>> -----Original Message-----
>>> From: ext Even, Roni [mailto:roni.even@polycom.co.il]
>>> Sent: Friday, March 28, 2008 10:13 AM
>>> To: Wang Ye-Kui (Nokia-NRC/Tampere); csp@csperkins.org
>>> Cc: avt@ietf.org
>>> Subject: RE: [AVT] Some comments to subsection 8.1.1
>>> indraft-ietf-avt-rtp-svc-08
>>>
>>> YK,
>>> You are talking about a single stream and this is standard 
>RFC 3550. 
>>> If you want it some place add it to RFC 3984 but I would 
>say that no 
>>> payload mention it.
>>> Roni
>>>
>>>> -----Original Message-----
>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf 
>>>> Of
>>> Ye-
>>>> Kui.Wang@nokia.com
>>>> Sent: Friday, March 28, 2008 12:10 AM
>>>> To: csp@csperkins.org
>>>> Cc: avt@ietf.org
>>>> Subject: Re: [AVT] Some comments to subsection 8.1.1
>>> indraft-ietf-avt-rtp-
>>>> svc-08
>>>>
>>>>
>>>>
>>>>>> 1. In the following copied text, NTP timestamps of NAL units or 
>>>>>> operation point representations are mentioned. However, NAL
>>>>> units are
>>>>>> not directly assoicated with NTP timestamps, which are only
>>> directly
>>>>>> assoicated with RTCP SRs. The NTP timestamp for each NAL
>>>>> unit must be
>>>>>> defined.
>>>>>
>>>>> The RTCP SR packets define the mapping between the two timelines, 
>>>>> allowing you to directly derive the NTP timestamps from the RTP 
>>>>> timestamps in each session. This is the standard RFC 3550
>>>>> semantics:
>>>>> nothing specific to this format needs to be defined.
>>>>>
>>>>
>>>> By defining I meant adding something saying that the NTP
>>> timestamp is
>>>> derived for each packet (according to RFC 3550) and each NAL unit's
>>> NTP
>>>> timestamp is equal to the NTP timestamp of the packet the
>>> NAL unit is
>>>> carried in. This makes the description better, and I think it is
>>> aligned
>>>> with what you said above.
>>>>
>>>> BR, YK
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> avt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>
>
>
>--
>Colin Perkins
>http://csperkins.org/
>
>
>
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt