[asterisk-dev] Patch: SIP: choosing common codec and select "free"codec for transcoding

[Andrey Sofronov]

Thanks, I've reported. I can help in testing or coding....

On Jan 29, 2008 6:55 PM, asterisk <Asterisk at isgcom.com> wrote:

>  Very Nice!   This has been a big issues with asterisk.   I look forward
> to seeing it in the Bug tracker..
>
>
>
> Doug
>
>
>
>
>  ------------------------------
>
> *From:* asterisk-dev-bounces at lists.digium.com [mailto:
> asterisk-dev-bounces at lists.digium.com] *On Behalf Of *Andrey Sofronov
> *Sent:* Tuesday, January 29, 2008 11:39 AM
> *To:* asterisk-dev at lists.digium.com
> *Subject:* [asterisk-dev] Patch: SIP: choosing common codec and select
> "free"codec for transcoding
>
>
>
> Hello all!
>
> In my network there are a lot of hardware VoIP gateways and softphones and
> I have to make then work. Most of all hardware VoIP gateways support G.711,
> G.723 and G.729 codecs and the softphones support G.711, GSM, iLBC etc
> codecs. All endpoints are SIP peers. All traffic should pass through my
> asterisk server(s). In "vanilla" asterisk there is a limitation - it is
> unable to select a common codec for 2 peers using some algorithm (less
> bandwidth etc) or if jointcapability = 0 select codecs for both endpoints
> that could be transcoded "for free".
>
> *1st example*:
>
> sip.conf
>
> [210]
> disallow=all
> allow=alaw,ulaw,g723,g729
> ...
>
> [220]
> disallow=all
> allow=alaw,ulaw,g723,g729
> ...
>
> [255]
> disallow=all
> allow=gsm
> ...
>
> 210 calls 220:
> sip show channels
> Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format
> Hold     Last Message
> 10.xx.xx.xx     220         10aa3d3754b  00102/00000  0x8 (alaw)
> No       Init: INVITE
> 10.xx.xx.xx     210         a983a543-52  00101/00939  0x8 (alaw)
> No       Rx: INVITE
>
> Works, but alaw is a high-bandwidth codec!
>
> 210 calls 255:
> sip show channels
> Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format
> Hold     Last Message
> 10.xx.xx.xx    255         504c907f5b7  00102/00000  0x2 (gsm)
> No       Init: INVITE
> 10.xx.xx.xx     210         5f84a543-9c  00101/00943  0x8 (alaw)
> No       Rx: INVITE
>
> Works here...
>
> *2nd example*:
>
> sip.conf
>
> [210]
> disallow=all
> allow=g729,alaw,ulaw,g723
> ...
>
> [220]
> disallow=all
> allow=g729,alaw,ulaw,g723
> ...
>
> [255]
> disallow=all
> allow=gsm
> ...
>
> 210 calls 220:
> sip show channels
> Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format
> Hold     Last Message
> 10.xx.xx.xx     220         572052d8348  00102/00000  0x100 (g729)
> No       Tx: ACK
> 10.xx.xx.xx     210         0486a543-2e  00101/00946  0x100 (g729)
> No       Rx: ACK
>
> Good work - g729 pass-through!
>
> 210 calls 255:
> WARNING[8424]: chan_sip.c:3001 sip_call: No audio format found to offer.
> Cancelling call to 255
>
> All codecs are same, but their order was changed.
>
> It's a simple example, just to point a problem.
>
> I'm not a professional C/C++ programmer, but the feature was necessary so
> I created a small patch (for asterisk 1.4.17).
>
> In brief:
> 1) set sip_pvt->prefcodec = 0!
> 2) Thanks to 1) asterisk continues execution and calls
> ast_channel_make_compatible function.
> 3) In "ast_channel_make_compatible" we recalculate peers' codec
> capabilities and sip_pvt->prefs.
>
> Result - the order of the codecs in "allow=" parameter does not matter
> anymore. Asterisk will select most efficient codec for pass-through and if
> jointcapability = 0 will select free and ecomonic codec for transcoding.
>
> My patch is not excellent (maybe even awful, but i'm not a programmer and
> it works for me fine!) but if anybody get an idea, you can make it better.
> Also it would be nice to implement that feature as configuration parameter.
>
> Please see patch in attachment! Thanks!
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20080131/c783cf2d/attachment-0001.htm