Subject: Re: [AVT] WGLC on draft-ietf-avt-rtp-ipmr-04

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Aug 2009 16:18:43 +0100

On 16 Jun 2009, at 15:27, Elena Berlizova wrote:
> -----Original Message-----
> From: Elena Berlizova
> Sent: Monday, June 15, 2009 3:33 PM
> To: [email-masked]'
> Cc: 'Tom Taylor'; 'Roni Even'; Sergey Ikonin
> Subject: RE: [AVT] WGLC on draft-ietf-avt-rtp-ipmr-04
>
> Hi all,
>
> Addressing Colin's comments:
>
> The payload header includes flags (the "D" and "A" bits) to signal if
> DTX is allowed, and if the payload format is byte aligned. This is
> unusual. Previous payload formats generally signal such parameters  
> out-
> of-band, for example using an SDP offer/answer exchange. What's the
> rationale for this design, and is there a reason why out-of-band
> parameters cannot be used?
>
> 	[SI]-> When we developed payload format we tend to maximize
> flexibility of codec usage in real-time to allow rapid channel
> adaptation. Because of that we put all codec setting in-band to allow
> quick changing of it without re-negotiation. Now we think these two
> can be placed out-of-band. But some our customers already deployed
> this format and we need to keep interoperability with them.

You can perform rapid channel adaptation without signalling these in- 
band, by negotiating multiple payload types with the different options.

> The A bit in the payload header signals whether a byte-aligned mode is
> to be used. There doesn't seem to be any specification of how this
> differs from the non-byte-aligned mode.
>
>
> 	[SI]-> In sec 4.2 we have example of payload format in which the
> A=1. 	In this example all speech frames are padded with zero bits for
> byte 	alignment. This is the difference from non-byte-aligned mode.
>
>
> Section 3.5 indicates that the decoder "can calculate the frame size
> by its content" and notes that "there is a special service function
> that returns frame size without total decoding which may be used for
> this purpose". A function tied to a particular codec implementation is
> appropriate for a vendor codec, but not for a payload format that is
> to be registered in the standards tree. The draft needs to document
> how to determine the payload length. (This information might be added
> to the table on page 6).
>
>
> 	[SI]-> We can add some table to indicate frame size depending of  
> first bits and codec settings. But we afraid that table will be big
> enough and not clear for usage. Another option which we can do - to  
> add
> some function in c-code or pseudo-code that return frame size
> depending of frame content and codec settings.

Either would work, or you could reference the appropriate section of  
the codec specification. My point is that an independent  
implementation needs to be possible for this to be standards track, so  
the information has to be available.

-- 
Colin Perkins
http://csperkins.org/