pjsip right solution for comfort noise generation?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Philipp-

>> I have some problems with devices making use of VAD. When connected to an
>> asterisk server, comfort noise is not generated since asterisk does not
>> support this. On the other hand it is not possible to disable VAD on the
>> endpoints.
>>
>> My question is whether it is possible to utilize pjsip to parse the rtp
>> stream from the endpoints, watch for the rtp-packet with the cng marker
> bit
>> and add rtp packets with comfort noise until the endpoints start
>> transmitting again while forwarding the parsed stream to the asterisk.
>>
>> In this case G711.u codec ist used.
>
> If you're using basic G711 then there is no concept of comfort noise -- all
> RTP packets contain "sound" (voice, noise,
> silence, tone, etc).
>
> It's possible that your endpoints are using "G711 Appendix II" or other
> non-standard implementation that includes VAD
> and CNG.  Do you know if that's the case?  If so, then you may want to
> re-think because G711 II implementations are
> not common -- which could explain your compatibility issues with Asterisk.
> If you need VAD/CNG to reduce bandwidth
> then I might suggest using a popular / widely used codec (such as G729) that
> has supoprt for VAD/CNG.
>
> -Jeff
>
> You are correct. The endpoints are using G711 with RTP Payload for Comfort
> Noise as described in RFC 3389. Even though switching to another codec would
> for sure be the best solution, in this scenario it is not possible. So since
> there is no way to change conditions at the endpoints and there are quite a
> few issues from people asking for RFC 3389 support in digiums mailing lists
> dating back to 2005, I thought it might be a better approach to get some
> kind of a proxy between those two which adds the comfort noise.

Well you could use something like Kamailio and rtpproxy, and process RTP packets as needed with an
application-specific extension to rtpproxy.  We do this for encryption (e.g. SRTP) and transcoding (e.g. G729 to
GSM-AMR).  Also at SIP level you may encounter situations where you have to "spoof" one end or the other to allow SIP
negotiation to succeed.  For example you may need to let Asterisk think that it's receiving basic G711 when actually
the your endpoint is sending G711-II.

Your scenario is more or less a transcode.

-Jeff




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux