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

[Steve Underwood]

  On 09/07/2010 12:03 AM, Jeff Brower wrote:
> Steve-
>
>>>>> 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?
> The first two bytes appear not to be a proper SID.  However, as Vikram mentioned time-stamps show an increase greater
> than ptime and MARK bit is set in the RTP header.  Then there are several consecutive packets (from 10 to 100) with
> this combination.  Once we see the first of these, possibly we could strip and generate a correct SID.
You can't generate a correct SID. The codec constructs the SID 
information from its working variables, and may send extra SID messages 
during the silence period, to update the model it sent in the original SID.
>> I expect if you have annexb set to no, then some other form of VAD is
>> active, and suppressing transmission.
> Yes... something in the middle... possibly the MSiP.
>
> -Jeff
>
>
Steve