Setting Codec On Originating (calling) Channel With Chan_pjsip (SIP_CODEC_INBOUND Equivalent)

Home » Asterisk Users » Setting Codec On Originating (calling) Channel With Chan_pjsip (SIP_CODEC_INBOUND Equivalent)
Asterisk Users 10 Comments

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

10 thoughts on - 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

    >

  • 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

    —

  • Hi Michael,

    Thanks for the reply.

    I was referring to the scenario you named as ‘outbound broken’. I didn’t get to look at inbound call behavior yet, as I got stuck with inability to avoid transcoding on outbound calls.

    To be more specific the scenario is as follows:

    1. a phone initiates a call offering g722,g711 to asterisk
    2. asterisk creates outbound call to carrier offering g711 only (carrier only supports g711)
    3. carrier accepts the call and outbound call leg is now running on g711
    4. asterisk accepts a phone’s call with g722 since it’s allowed on phone’s endpoint and was indicated as preferred in phone’s INVITE and now initial call leg is running on g722, resulting in transcoding

    This is very disappointing. Since developers announced their plans to drop chan_sip from future asterisk versions I was under impression that chan_pjsip has reached feature paritiy with chan_sip. What is needed is an ability to tell asterisk which codecs are allowed to be included in
    “200 OK” asterisk sends back to the phone. I guess we need to submit a feature request. How do we go about it these days?

    Thanks, Michael

    >

  • Well, I’m trying to migrate to chan_pjsip so that I don’t have to do that.

    It’s so surprising that the issue so seemingly obvious and trivial hasn’t been addressed yet that I wanted to query the collective wisdom of this list to verify my observations.

    Thanks for github pointer.

    Michael

    > https://github.com/asterisk/asterisk-feature-requests.

  • 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
    >

  • I suspect most people simply don’t care. Transcoding between ulaw and g722 is not CPU intensive and Direct Media doesn’t work when NAT is involved (which would the case for most people).

    —

  • Oh, that’s great. It wasn’t clear from that page, at least not for me. 🙁

    Having it clearly stated on the document would save me (and probably others) lots of time.

    Thanks for clarifying it. Any idea on the timeframe of implementation?

    *Michael Ulitskiy*
    Ace Innovative Networks, Inc. Main/SMS: 212-868-2366
    Direct/SMS: 212-812-1203
    https://www.aceinnovative.com
    >