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

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>

On Thu, Jul 6, 2023 at 1:43 PM Michael Ulitskiy <mulitskiy at acedsl.com>
wrote:
> 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.
>
>
That functionality is not implemented as of this time.

-- 
Joshua C. Colp
Asterisk Project Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20230706/eca16e16/attachment.html>