[Home]

Summary:ASTERISK-11322: [asterisk-dev] [patch] Choosing common codec and select "free" codec for transcoding
Reporter:Andrey Sofronov (andrey sofronov)Labels:
Date Opened:2008-01-29 11:17:42.000-0600Date Closed:2011-06-07 14:08:23
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.4.17-sipcodec.diff.gz
( 1) asterisk-1.4.17-sipcodec2.diff
Description: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.

I've posted the patch to asterisk-dev maillist.

Thank you guys!
Comments:By: Jason Parker (jparker) 2008-01-29 11:57:10.000-0600

Why is this marked as private?
By: Andrey Sofronov (andrey sofronov) 2008-01-30 09:43:44.000-0600

It's just a small mistake...
By: Andrey Sofronov (andrey sofronov) 2008-01-31 03:25:57.000-0600

Uploaded updated patch
By: Joshua C. Colp (jcolp) 2008-02-29 12:27:22.000-0600

I am strongly against this patch as it is. Making the SIP stuff a global header and then accessing things using it outside of chan_sip is a big no-no.
By: Leif Madsen (lmadsen) 2008-10-07 13:11:39

I'm closing this bug for now as it has been open for much too long with no movement. Since Josh doesn't like the approach here, and there needs to be a lot of work in terms of codec negotiation anyways, I'm suspending this issue for now. Please re-open in the future should it be necessary. Thanks!