PJSIP - Multiple Outbound Registration to Same IP

Dear Community,

I’ve been struggling to configure properly the following environment via pjsip channel:

Asterisk to Provider A, Account A (REG/AUTH A)
Asterisk to Provider A, Account B (REG/AUTH A)

There are only Outbound credentials
No Inbound registration credentials are provided

When Inbound calls are received (Provider DID calls to Asterisk), Asterisk always sends the call to the same “Endpoint Context”, its like that, it doesn’t make a difference between Accounts

And when using LINE=yes parameter in Registration section, the call is sent to the correct Context, but the BNUM gets stripped to nothing

I can provide further information in order to debug properly
Any idea will be greatly appreciated

Warm Regards

Without “line=yes” there is no differentiation, so it would be needed. You’d also need to specify what “BNUM” means and provide a SIP trace.

When you to configure line=yes the asterisk put a dynamic “string” in register, when other side send invite to your asterisk, this string needs include in packet

line=yes may not be enough. You need to make sure that the service provider actually supports that. When they support that and they offer something like which is frequently described as a “trunk”, you may need to check whether you also need to evaluate other SIP headers like P-Called-Party-ID. And if the service provide is really big, you may have to deal with some DNS related issues. I know of one big player that allows communication only with the server (out of many) where you have registered your box, but it is allowed to register to several of their proxies at the same time…

From the OPs description, they do return the line= part of the Contact URI. Strictly speaking everyone should.

What he is saying is they then don’t provide the mysterious BNUM value. I’m wondering if they were presenting the called number in the request URI, rather than strictly following the RFC and sending the Contact URI, but the additional URI parameter has forced them to use the Contact URI properly.

The OP should see if they can arrange to use one account, which is likely to be a better solution.

Failing that, they need to capture a complete INVITE request and look to see if it contains a “BNUM”. If it does, and they can highlight it, we can probably find a way of extracting it and will know what one is.

Depending on the target provider, another option would be to use different transports for the different accounts. They may differentiate between port numbers.

Rough pjsip example, would need more actual config, but since you’ve gotten this far then I have faith you’ll piece the rest together.

[transport-udp-acc1]
type=transport
protocol=udp
bind=0.0.0.0:5081

[transport-udp-acc2]
type=transport
protocol=udp
bind=0.0.0.0:5082

then define the different transports for the endpoints

[yeet-acc1]
type=endpoint
transport=transport-udp-acc1

[yeet-acc2]
type=endpoint
transport=transport-udp-acc2

I think transport is only used outbound. Inbound chan_pjsip matches regardless of the transport used.

I’ve never heard of a “BNUM”, but that probably doesn’t mean a lot. Anyway, I am running routinely several accounts of the same provider on my devices. The only thing I need to do is to evaluate some SIP headers except for line=yes for the registration. For convenience, there is only a single entry point in my dialplans.

Dear Community,

Thanks for all the answers,
Ill try to get better at using the LINE parameter, and if nothing works, i will test using different ports per Account (I have 30 right now. . .)

Currently, I’m facing the following “issue” when using LINE parameter
When there is a value in: contact_user (Registration section), the Destination Number (BNumber) received from the ProviderA gets overwritten by contact_user value.

Example:
ProviderA sends call to Asterisk (SRC: 123456, DST: 987654)
Asterisk sends call to BLeg modifying the original destination number to the value of “contact_user” (SRC: 123456, DST: Account1)

When I remove the value of “contact_user” parameter, Asterisk sends the Registration request of the account with s@ ProviderA_IP:5060, so, ProviderA sends the calls to DST Number: s

Any updates or fixes found will be shared down below
Warm Regards

That should happen whenever you use REGISTER, not just with the Line option. Do they duplicate the dialled number in, say, the To header?

If it is in the To header, this is how FreePBX handles it:

David,

Here are some SIP trace examples,
SIP Registrar from Asterisk to Provider

Reply from Provider

Call example (DID Provider to Asterisk)

As you can see, Destination Number from Provider is OK, but asterisk insists on reading the number that is being sent on INVITE: sip:s@ host:5060

Thats why i mentioned that maybe i need further research about LINE configuration, to start reading SIP TO instead.

Asterisk CLI:

[2022-09-14 12:03:00.648] NOTICE[125010]: res_pjsip_session.c:3963 new_invite: ALEG: Call (UDP:hidden.57:5060) to extension ‘s’ rejected because extension not found in context ‘IN_PROVIDERA’.

Warm Regards

That’s what a SIP UAS should do. The code from FreePBX should work.

Dear David,

Thanks a lot for the clarification,
Under that concept, ill try to capture the SIP TO header via dialplan and replace the extension as it should be

Once fixed ill close the topic (Hope so)
Warm Regards

Updates:

Since I’m receiving s@host in the INVITE line,

I’ve modified the dialplan to “overwrite” the OUTBOUND leg Destination number “s” to the INBOUND SIP TO header:
Inbound INVITE
SIP To: sip:s@ Host:Port;line=string

${CUT(CUT(PJSIP_HEADER(read,To),:,2) ,@,-1)}

Gets stripped down to: NUM
Outbound INVITE
SIP To: sip:NUM@ Host:Port

Hope this helps somebody
Warm Regards

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