asterisk users - Oct 2019 - Asterisk not using common codec between (SIP) endpoints

On 03.10.19 15:08, Administrator TOOTAI wrote:
> Before calling the gatreway add
>
> same = n,set(SIP_CODEC=alaw)
>
> [...]
>
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

On Thu, Oct 3, 2019, at 11:10 AM, Andreas Wehrmann
wrote:
> 
> On 03.10.19 15:08, Administrator TOOTAI wrote:
> 
> > Before calling the gatreway add
> >
> > same = n,set(SIP_CODEC=alaw)
> >
> > [...]
> >
> 
> 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...
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: www.digium.com & www.asterisk.org

On 03/10/2019 16:24, Joshua C. Colp wrote:
> 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
>
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