Different Codec Negotiation Orders for different numbers using the same endpoint

Asterisk Asterisk SIP
1

In Asterisk using PJSIP, I have the following endpoint for an SBC (only relevant snippet of pjsip.conf is shown):

[my-sbc]
type=endpoint
disallow=all
allow=g722
allow=alaw
allow=ulaw

The goal is that by default, codec negotiation order should be g722, alaw, and then ulaw. This works great, but on that same SBC, I would like to have two different numbers, where the first number indeed uses this order, but the second number (say, +4912345) should have a different negotiation order; it should never use g722 and instead always use alaw, then ulaw.

How can I solve this? I tried the following in extensions.conf, but according to my contact from the SBC, the order is still as specified in the pjsip.conf when testing:

[sip-incoming-my-sbc]
exten => +4912345,1,Set(DISALLOW=all)
exten => +4912345,2,Set(ALLOW=alaw)
exten => +4912345,3,AGI(myscript.agi)
3

I’m not sure if this can be done, but we have to know what myscript.agi did with those variables. I doubt that they mean anything to Asterisk. Did you get this from an LLM?

4

I imagine that you’d need to use PJSIP_MEDIA_OFFER - Asterisk Documentation but you are setting it on the wrong channel for the outbound leg, and I’m not sure how useful it is on the inbound leg, before the call is answered.

5

Thank you for your suggestion and apologies for my late reply, but it took time to search for a different approach.

Did you get this from an LLM?

Yes, and upon reading the documentation, this indeed makes no sense, so please disregard.

I imagine that you’d need to use PJSIP_MEDIA_OFFER - Asterisk Documentation but you are setting it on the wrong channel for the outbound leg, and I’m not sure how useful it is on the inbound leg, before the call is answered.

I tried your approach, but as you suspected, it did not work.

My new approach would be as follows (if a new thread is a better idea, please let me know): I have now set up a second endpoint/trunk; the first endpoint I used was on port 5740, and the new one is on 5741. Both endpoints are indeed reachable; my pjsip.conf looks essentially like this, where SBC_HOST is the host (both ports are on this host):

[my-sbc-1]
type=endpoint
disallow=all
allow=g722
aors=my-sbc-1
context=sip-incoming-my-sbc-1

[my-sbc-1]
type=aor
contact=sip:${SBC_HOST}:5740
qualify_frequency=30

[my-sbc-1]
type=identify
endpoint=my-sbc-1
match=${SBC_HOST}

[my-sbc-2]
type=endpoint
disallow=all
allow=alaw
aors=my-sbc-2
context=sip-incoming-my-sbc-2

[my-sbc-2]
type=aor
contact=sip:${SBC_HOST}:5741
qualify_frequency=30

[my-sbc-2]
type=identify
endpoint=my-sbc-2
match=${SBC_HOST}

And I assumed that the following extensions.conf would work:

;Specification for g722
[sip-incoming-my-sbc-1]
exten => +4912345,1,AGI(myscript.agi)

;Specification for alaw
[sip-incoming-my-sbc-2]
exten => +4912346,1,AGI(myscript.agi)

However, when I call +4912346, I see in my logs that this number is not found in sip-incoming-my-sbc-1, so my assumption that Asterisk searches through the entire extensions.conf is incorrect. Do you have any suggestions how I might solve this? I tried the following and then, the number is reachable, but the codec is g722 instead of alaw (presumably because it first goes through sip-incoming-my-sbc-1 which is associated with g722):

;Specification for g722
[sip-incoming-my-sbc-1]
exten => +4912345,1,AGI(myscript.agi)
exten => +4912346,1,Goto(sip-incoming-my-sbc-2,+4912346,1)

;Specification for alaw
[sip-incoming-my-sbc-2]
exten => +4912346,1,AGI(myscript.agi)
6

This won’t work. You can’t have two “identify” types matching the same IP address. How are they supposed to know which endpoint is supposed to be used?

7

I see, that makes sense, thank you.

Can my setup (two trunks on different ports using the same IP that should correspond to different endpoints depending on the dialed number) work, or would I absolutely have to use different IPs such that I can use different identify types?

8

The remote side would have to use different source ports. If that’s what you are referring to, then the “match=” option does support specifying a port.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.