Asterisk Not Using Common Codec Between (SIP) Endpoints

Home » Asterisk Users » Asterisk Not Using Common Codec Between (SIP) Endpoints
Asterisk Users 4 Comments

Hi

Le 03/10/2019 à 13:13, Andreas Wehrmann a écrit :

[…]

Before calling the gatreway add

same = n,set(SIP_CODEC=alaw)

[…]


Daniel

4 thoughts on - Asterisk Not Using Common Codec Between (SIP) Endpoints

  • Hey there,

    that doesn’t work as it seems to be implemented for chan_sip only;
    I’m using chan_pjsip; sorry if I didn’t explain myself properly.

    Anyway, in my case that would not really be an acceptable solution anyway, because I need the called party to be able to pick from the range of codecs presented to it because the codec chosen by the destination might change (my example is a simplified version).

    I don’t think putting the burden of worrying about audio codecs on the dialplan writer is a good idea, since this should be dealt with automatically with respect to what is configured and negotiated. This is also because in the systems I have to work with, the ‘engineers’
    usual provide the configuration (endpoints, NAT config and the like)
    while the technicians implement the dialplan (or the business logic so to speak) according to customer needs. They (the technicians) usually don’t know (much) about codecs or how the channels techs work exactly…

    Thanks, Andy

  • In PJSIP there is the PJSIP_MEDIA_OFFER dialplan function[1] but ultimately codec negotiation is not written or implemented in the way you need. There are some hints provided internally for outgoing legs but the result is still ultimately independent. That is: Each leg is negotiated from Asterisk to the endpoint, not endpoint to endpoint via Asterisk. This works for the vast majority of users as they have media flowing through Asterisk (by choice or via use of features) and are fine with transcoding (generally using codecs which aren’t that costly or low channel count).

    Asterisk 16 has some of the foundational work to improve this through the implementation of streams but noone has worked on extending the codec negotiation support.

    [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+17+Function_PJSIP_MEDIA_OFFER


    Joshua C. Colp Digium – A Sangoma Company | Senior Software Developer
    445 Jan Davis Drive NW – Huntsville, AL 35806 – US
    Check us out at: http://www.digium.com & http://www.asterisk.org

  • Hey Joshua,

    do you think it might be possible to achieve this by writing a supplement for the PJ part?

    What happens when the other side answers, but before the incoming call is answered. Is there a place in the code where, at that point, I have information about both channels and could theoretically influence the answer for the incoming call?

    All the best, Andy

  • PJSIP is only part of the equation, the information still has to transition across the core.

    Nope. That information is not currently exchanged or available, which is part of the problem.


    Joshua C. Colp Digium – A Sangoma Company | Senior Software Developer
    445 Jan Davis Drive NW – Huntsville, AL 35806 – US
    Check us out at: http://www.digium.com & http://www.asterisk.org