[xiph-rtp] Re: Speex -02 feedback and m bit question.

Phil Kerr phil at plus24.com
Thu Apr 14 15:25:34 PDT 2005


Jean-Marc Valin wrote:

>Hi,
>
>I haven't see the thread on the avt list, can you send me the link?
>  
>
http://www.ietf.org/mail-archive/web/avt/current/msg05323.html

>I'm not sure how the CNG is supposed to work. What I called cng in the
>current draft is only about doing cng in the case of discontinuous
>transmission (perhaps it could be renamed dtx_cng), so that when no
>packets are sent, the decoder knows whether it should generate comfort
>noise or just put zeros.
>  
>
Ok, this does sound like it can be handled by the standard RTP comfort 
noise handling.

>I don't know what the p bit is, so I can't comment on it. Same about the
>"ITU related text".
>
>	Jean-Marc
>
>Le jeudi 14 avril 2005 à 23:00 +0100, Phil Kerr a écrit :
>  
>
>>Hi Greg/Jean-Marc,
>>
>>You have probably seen Colin Perkins' feedback on the AVT list regarding 
>>the -02 Speex draft.  Having it move to WG status for the next revision 
>>is great news!
>>
>>One of Colin's questions:
>>
>>    
>>
>>>The use of the M bit in the RTP header to indicate comfort noise is  
>>>unusual. Can you comment why it was used in this way, rather than 
>>>being  used to indicate the first packet after the "silence" period, 
>>>as would  be typical? The unusual semantics are not necessarily 
>>>problematic, but  we I'd like to understand what benefit we gain from 
>>>the additional  complexity of atypical usage. 
>>>      
>>>
>> From the draft we specify:
>>
>>   The M bit indicates if the packet contains comfort noise.  This field
>>   is used in conjunction with the cng SDP attribute and is detailed
>>   further in section 5 below.  In normal usage this bit is set if the
>>   packet contains comfort noise.
>>
>>..
>>
>>      cng:   comfort noise generation - either 'on' or 'off'.  If off
>>      then silence frames will be silent; if 'on' then those frames will
>>      be filled with comfort noise.
>>
>>Should this really conform strictly to the RTP specs or is this a case 
>>where the RTP transportation needs to bend towards the encoder?
>>
>>I think his other points, fixing the p bit and moving the ITU related 
>>text to the speex.org site are fair and should pose no problems.
>>
>>Cheers
>>
>>Phil
>>
>>    
>>
>
>  
>



More information about the xiph-rtp mailing list