asterisk users - Jul 2023 - Setting codec on originating (calling) channel with chan_pjsip (SIP_CODEC_INBOUND equivalent)

Hello,

Anyone? I have hard time to believe this is not possible with chan_pjsip.

Anyway, may I ask how people handle the following scenario which I 
imagine should be quite common:

- I have internal extensions talk to each other using g722. so their 
codec setting (with chan_sip now) is "allow=g722,ulaw"
- I have carriers trunks that handle ulaw only (allow=ulaw)
- calls between internal extensions naturally happen over g722 as its 
their preferred codec
- for external calls I now set SIP_CODEC_INBOUND=ulaw to influence codec 
selection on calling channel and the calls set up using ulaw end-to-end

Can somebody please advise how to achieve the same with chan_pjsip?

Thanks,

Michael

On 6/30/23 09:30, Michael Ulitskiy wrote:
>
> Hello,
>
> I finally got to look at chan_sip to chan_pjsip migration again. This 
> time I’m having problems with influencing codec selection on 
> originating (calling) channel. It looks like PJSIP_MEDIA_OFFER only 
> works on outbound (called) channel and has no affect on calling 
> channel. My experiments and function documentation (which says “Media 
> and codec offerings to be set on an outbound SIP channel prior to 
> dialing.”) seem to confirm it.
> So PJSIP_MEDIA_OFFER is supposed to be (and it works) chan_pjsip’s 
> equivalent of ${SIP_CODEC_OUTBOUND}, but what is chan_pjsip’s 
> equivalent of ${SIP_CODEC_INBOUND}? Or, in other words, what are we 
> supposed to do to influence /calling/ channel codec selection from 
> dialplan?
> I’m working with asterisk 20.3.0.
>
> Thank you,
> Michael
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230705/5355bfc8/attachment.html>

Hello Michael,

you are referring to the following behavior - did I get it correctly?:

outbound broken: asterisk offers g722 / g711 to provider (callee), 
callee answers g711. Asterisk now transcodes between caller and callee 
(g722 <-> g711).

inbound works: call from provider: g711 -> asterisk drops g722 and 
passes g711 to internal callee -> no transcoding.


As far as I know, there is no working solution as of now. I discussed 
this problem years ago already here but unfortunately nothing usable 
happened so far (which I would know off). The priority is not high 
enough. I need a solution, too. I understand that this behavior is a 
nogo if you have a lot of calls because transcoding is expensive.


Thanks
Michael



On 05.07.23 at 17:58 Michael Ulitskiy wrote:
> Hello,
> 
> Anyone? I have hard time to believe this is not possible with chan_pjsip.
> 
> Anyway, may I ask how people handle the following scenario which I 
> imagine should be quite common:
> 
> - I have internal extensions talk to each other using g722. so their 
> codec setting (with chan_sip now) is "allow=g722,ulaw"
> - I have carriers trunks that handle ulaw only (allow=ulaw)
> - calls between internal extensions naturally happen over g722 as its 
> their preferred codec
> - for external calls I now set SIP_CODEC_INBOUND=ulaw to influence codec 
> selection on calling channel and the calls set up using ulaw end-to-end
> 
> Can somebody please advise how to achieve the same with chan_pjsip?
> 
> Thanks,
> 
> Michael
>

Hello,

After I have re-read the "PJSIP Advanced Codec negotiation" document,
it
occurred to me that the desired behavior should actually happen 
automatically, just due to the codec negotiation logic, but it looks 
like asterisk doesn't actually follow the described logic which is 
likely a bug.

Can you please follow with me through a simple sip call and see if I'm 
missing something or asterisk actually doesn't do what it's supposed to
do?

Here's the codec negotiation config:
CLI> pjsip show endpoint A
  ...
  codec_prefs_incoming_answer        : prefer:pending, 
operation:intersect, keep:all, transcode:allow
  codec_prefs_incoming_offer         : prefer:pending, 
operation:intersect, keep:all, transcode:allow
  codec_prefs_outgoing_answer        : prefer:pending, 
operation:intersect, keep:all, transcode:allow
  codec_prefs_outgoing_offer         : prefer:pending, operation:union, 
keep:all, transcode:allow

All endpoints have the same default config above.

Let's go over simplest scenario: A calls B.
A is configured with g722 and ulaw (allow=!all,g722,ulaw) and B is 
configured with ulaw and alaw (allow=!all,ulaw,alaw)

1. codec_prefs_incoming_offer: A sends INVITE to asterisk with codecs in 
SDP g722,g729,g711u,g711a:
...
m=audio 2266 RTP/AVP 9 18 0 8 101.
a=rtpmap:9 G722/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8

   - according to Advanced Codec Negotiation logic now we have:
     - pending=g722,g729,ulaw,alaw
     - configured=g722,ulaw
     Applying operation "intersect" the resulting resolved topology is
"g722,ulaw" which is sent to the core

2. codec_prefs_outgoing_offer: Outgoing channel driver receives the 
offer from the core
     - pending=g722,ulaw
     - configured=ulaw,alaw
     Applying operation "union" the resulting resolved topology should
be "g722,ulaw,alaw" which should be sent
     to B in the outgoing INVITE. What I see is actually sent in 
outgoing INVITE is "ulaw,alaw":
...
m=audio 41506 RTP/AVP 0 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
...
     So this is the 1st point where codec negotiation doesn't work as 
expected

3. codec_prefs_incoming_answer: B replies with "200 OK" which contains
only ulaw codec:
...
m=audio 2226 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
...
    - pending: ulaw
    - configured: ulaw,alaw (it's result of step 2. it should be 
g722,ulaw,alaw but actually is ulaw,alaw as described in step 2)
    Applying operation "intersect" the resulting resolved topology is 
"ulaw" which is sent to the core

4. codec_prefs_outgoing_answer: asterisk replies "200 OK" back to A
    - pending: ulaw (from step 3)
    - configured: g722,ulaw (from step 1)
    Applying operation "intersect" the resulting resolved topology 
should be "ulaw". What I see is actually sent in
    "200 OK" is "g722,ulaw":
...
m=audio 43004 RTP/AVP 9 0 101.
a=rtpmap:9 G722/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
...

If I understand it correctly the result of codec negotiation in the 
above scenario should be ulaw in both call legs, thus avoiding 
transcoding, but actual asterisk behavior differs.

Am I missing something. What are your thoughts?

Thanks,

*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
https://www.aceinnovative.com
On 7/5/23 11:58, Michael Ulitskiy wrote:
>
> Hello,
>
> Anyone? I have hard time to believe this is not possible with chan_pjsip.
>
> Anyway, may I ask how people handle the following scenario which I 
> imagine should be quite common:
>
> - I have internal extensions talk to each other using g722. so their 
> codec setting (with chan_sip now) is "allow=g722,ulaw"
> - I have carriers trunks that handle ulaw only (allow=ulaw)
> - calls between internal extensions naturally happen over g722 as its 
> their preferred codec
> - for external calls I now set SIP_CODEC_INBOUND=ulaw to influence 
> codec selection on calling channel and the calls set up using ulaw 
> end-to-end
>
> Can somebody please advise how to achieve the same with chan_pjsip?
>
> Thanks,
>
> Michael
>
> On 6/30/23 09:30, Michael Ulitskiy wrote:
>>
>> Hello,
>>
>> I finally got to look at chan_sip to chan_pjsip migration again. This 
>> time I’m having problems with influencing codec selection on 
>> originating (calling) channel. It looks like PJSIP_MEDIA_OFFER only 
>> works on outbound (called) channel and has no affect on calling 
>> channel. My experiments and function documentation (which says “Media 
>> and codec offerings to be set on an outbound SIP channel prior to 
>> dialing.”) seem to confirm it.
>> So PJSIP_MEDIA_OFFER is supposed to be (and it works) chan_pjsip’s 
>> equivalent of ${SIP_CODEC_OUTBOUND}, but what is chan_pjsip’s 
>> equivalent of ${SIP_CODEC_INBOUND}? Or, in other words, what are we 
>> supposed to do to influence /calling/ channel codec selection from 
>> dialplan?
>> I’m working with asterisk 20.3.0.
>>
>> Thank you,
>> Michael
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230706/587e98bc/attachment.html>

FYI: i've created a feature request to add SIP_CODEC_INBOUND equivalent 
functionality to chan_pjsip:

https://github.com/asterisk/asterisk-feature-requests/issues/9

Let's see where it goes

*Michael Ulitskiy*
Ace Innovative Networks, Inc.
Main/SMS: 212-868-2366
Direct/SMS: 212-812-1203
https://www.aceinnovative.com
On 7/5/23 11:58, Michael Ulitskiy wrote:
>
> Hello,
>
> Anyone? I have hard time to believe this is not possible with chan_pjsip.
>
> Anyway, may I ask how people handle the following scenario which I 
> imagine should be quite common:
>
> - I have internal extensions talk to each other using g722. so their 
> codec setting (with chan_sip now) is "allow=g722,ulaw"
> - I have carriers trunks that handle ulaw only (allow=ulaw)
> - calls between internal extensions naturally happen over g722 as its 
> their preferred codec
> - for external calls I now set SIP_CODEC_INBOUND=ulaw to influence 
> codec selection on calling channel and the calls set up using ulaw 
> end-to-end
>
> Can somebody please advise how to achieve the same with chan_pjsip?
>
> Thanks,
>
> Michael
>
> On 6/30/23 09:30, Michael Ulitskiy wrote:
>>
>> Hello,
>>
>> I finally got to look at chan_sip to chan_pjsip migration again. This 
>> time I’m having problems with influencing codec selection on 
>> originating (calling) channel. It looks like PJSIP_MEDIA_OFFER only 
>> works on outbound (called) channel and has no affect on calling 
>> channel. My experiments and function documentation (which says “Media 
>> and codec offerings to be set on an outbound SIP channel prior to 
>> dialing.”) seem to confirm it.
>> So PJSIP_MEDIA_OFFER is supposed to be (and it works) chan_pjsip’s 
>> equivalent of ${SIP_CODEC_OUTBOUND}, but what is chan_pjsip’s 
>> equivalent of ${SIP_CODEC_INBOUND}? Or, in other words, what are we 
>> supposed to do to influence /calling/ channel codec selection from 
>> dialplan?
>> I’m working with asterisk 20.3.0.
>>
>> Thank you,
>> Michael
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230706/274a7275/attachment.html>