RE: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt

Colin,

OK, I can see the problem and I agree that there is no use breaking
backwards compatibility. I will change the draft text for the next
revision accordingly.

Regards,
Ari

>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@csperkins.org] 
>Sent: 16 November, 2007 15:24
>To: Lakaniemi Ari (Nokia-NRC/Helsinki)
>Cc: avt@ietf.org
>Subject: Re: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt 
>
>Ari,
>
>On 16 Nov 2007, at 12:38, <ari.lakaniemi@nokia.com> wrote:
>> Thanks for the feedback. See some comments in-line.
>>
>>> Section 3.5 discusses RTP header usage, stating "In case the EV-VBR
>>> session consists multiple RTP sessions, the RTP sessions are further
>>> separated by using different payload type (PT) values for 
>each of the
>>> RTP streams" and "Each of the RTP sessions involved in the EV-VBR
>>> session SHALL use the same SSRC value". A better approach 
>would be to
>>> allow the usual choice of SSRC, and use a common RTCP CNAME to
>>> associate the streams, reusing the mechanism needed for lip-sync
>>> between audio and video.
>>
>> The intention is not to specify anything too exotic regarding the PT
>> and/or SSRC usage. My thinking here was that since the audio data
>> carried by the set of RTP streams originates from the same source, it
>> seemed logical to use the same SSRC value for each of the RTP  
>> streams -- which would also tie the streams together with the data  
>> present in the RTP header.
>>
>> Anyway, I realize the proposed SSRC handling is not fully in 
>line with
>> the RTP spec ("This identifier [SSRC] SHOULD be chosen randomly")  
>> and I
>> will change this part for the next revision if it is seen 
>problematic.
>> Do you see some unfavourable consequences with the proposed approach?
>
>Yes - one can no longer use standard RTP receiver code, using the  
>RTCP CNAME to group related streams (specified in RFC 3550), to  
>process this payload format. Instead, you have a special case, which  
>recognises this payload, and matches based on SSRC.
>
>> A related issue is the timestamp handling accross RTP sessions. Since
>> all the layers of a certain EV-VBR frame come from a single audio  
>> source and they will be combined back into a single frame in the  
>> receiving end prior to decoding, using the same timestamp value for  
>> the layers of the same encoded frame accross RTP sessions would  
>> simplify the data handling. Is this seen problematic?
>
>Again, it introduces a special case into the receiver code. Rather  
>than use the standard mechanism to synchronise streams, one has to  
>recognise this payload format, and do something different.
>
>We have standard mechanisms to time synchronise and group flows  
>across multiple RTP sessions. This payload format should use them,  
>rather than trying to reinvent the wheel in an incompatible way.
>
>Regards,
>Colin
>

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt