[asterisk-users] Possible malformed G729B - SID (VAD/DTX)frames from carrier endpoint ?

[Steve Underwood]

  On 09/06/2010 11:18 PM, Jeff Brower wrote:
> Steve-
>
>>    On 09/05/2010 04:08 AM, Vikram Ragukumar wrote:
>>> Hello,
>>>
>>> We are in the process of debugging a voice quality issue for a client of
>>> ours that is a VoIP services provider. The client uses a softphone that
>>> runs on a pjsip stack.
>>>
>>> When placing a call using the softphone, it negotiates the use of G729
>>> codec with the remote endpoint (ptime = 20ms). The endpoint transmits RTP
>>> packets with encoded G729 payload. VAD/DTX is enabled. We see that the
>>> last frame transmitted by the carrier side endpoint, before the beginning
>>> of a period of discontinuous transmission has 20 bytes of payload. We have
>>> verified that VAD/DTX is used by the carrier side endpoint by noting that
>>> there exist successive RTP packets that differ by 1 in their sequence
>>> number but have a timestamp difference>   160 and MARK bits are set in the
>>> RTP header.
>>>
>>> Our understanding is that for G729B, the SID frame that is transmitted
>>> before a period of discontinuous transmission has a size of 2 bytes.
>>> However we see that ALL RTP packets sent by the carrier side end point has
>>> a length of 20 bytes.
>>>
>>> Has anybody else seen this behavior from a carrier side endpoint ? Is
>>> there an RFC or document that specifies
>> Your understanding is correct. You need to infer from the length of the
>> last frame being 2 bytes that it is a SID frame, and SID frames should
>> only ever occur as the last frame in an RTP packet. If the SDP
>> negotiation has agreed to used the annex B (CNG/DTX/VAD) option for
>> G.729 you would normally expect to see a SID frame at the end of
>> transmission. If the SDP negotiation has agree to do CNG/DTX/VAD by
>> another means (which it can do) you won't see those SID frames. Even
>> when annex B is used, I think some systems may miss out the SID frames.
>> The use of proper annex B processing requires additional patent licence
>> payments, and I suspect some people try to fudge things to save a little
>> cost.
> We have Kamailio + rtpproxy running between the endpoints.  Do you think it's reasonable to convert the first
> malformed SID frame (10 bytes) to 2 bytes, and then strip the following malformed SID frames until we see the
> talkspurt marker bit is set?  We could do that... I'm wondering if anyone has seen such malformed SID frames before.
>
> As a couple of additional notes, between us and the remote endpoint there appears to be using an ALOE Systems
> (formerly MERA systems) MSiP system.  So far the SDP negotiations we've tried (e.g. a=fmtp:18 annexb=no) have not
> convinced the remote endpoint to disable VAD.
What makes you think there is a SID with the wrong length, rather than 
no SID? Do the first 2 of the 10 bytes look like SID?

I expect if you have annexb set to no, then some other form of VAD is 
active, and suppressing transmission.

Steve