PJSIP Endpoint Matching

I’ve got a somewhat unusual trunk situation. It’s an OBi202 channel that registers with Asterisk:

Trunk -> pjsip Settings tab -> General tab -> Registration = Receive.

It works as expected in all regards except incoming calls come in as a SIP Guest:

<--- Received SIP request (848 bytes) from UDP:192.168.0.234:5062 --->
INVITE sip:[email protected]:5060 SIP/2.0
Call-ID: [email protected]
Content-Length: 314
CSeq: 8001 INVITE
From: <sip:[email protected]>;tag=SP37f7fd0d4ffff09e1
Max-Forwards: 70
To: <sip:[email protected]>
Via: SIP/2.0/UDP 192.168.0.234:5062;branch=z9hG4bK-775a7339;rport
User-Agent: OBIHAI/OBi202-3.2.2.5859
Contact: <sip:[email protected]:5062>
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Content-Type: application/sdp

v=0
o=- 76106878 1 IN IP4 192.168.0.234
s=-
c=IN IP4 192.168.0.234
t=0 0
m=audio 17110 RTP/AVP 0 8 18 104 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:104 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian

  == Setting global variable 'SIPDOMAIN' to '192.168.0.123'
<--- Transmitting SIP response (330 bytes) to UDP:192.168.0.234:5062 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.234:5062;rport=5062;received=192.168.0.234;branch=z9hG4bK-775a7339
Call-ID: [email protected]
From: <sip:[email protected]>;tag=SP37f7fd0d4ffff09e1
To: <sip:[email protected]>
CSeq: 8001 INVITE
Server: FPBX-14.0.4.5(16.99.99)
Content-Length:  0


-- Executing [87055512340@from-sip-external:1] NoOp("PJSIP/anonymous-00000008", "Received incoming SIP connection from unknown peer to 87055512340") in new stack

What is needed for Asterisk to identify the incoming SIP connection and not route the incoming call to the the anonymous context?

You need a peer (DID) that matches:-

Use the e164 context for that trunk perhaps? It will strip the +

It doesn’t matter what I put in:

Trunk → pjsip Settings tab → General tab → Context

The incoming call is always sent to the anonymous (from-sip-external) context.

When you put a context there that effectively resolves the calling party to one of your local endpoints, it will work?

Currently, do have an endpoint +13235554321
?

I have an Inbound route for 87055512340 which points to an extension. Incoming calls make it to that extension. It’s just that they get there via from-sip-external (anonymous) and require that ‘Allow SIP Guests’ to be set to YES.

My PJSIP endpoint is:

[obi202bt]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=g722,ulaw
aors=obi202bt
language=en
outbound_auth=obi202bt
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
trust_id_inbound=no
t38_udptl_nat=no
direct_media=no
rewrite_contact=yes
rtp_symmetric=yes
dtmf_mode=auto

[obi202bt] does not not match +13235554321

I have a number of trunks for DID’s. None of them use the DID number as the trunk name and incoming calls on those trunks get routed to:

Trunk -> pjsip Settings tab -> General tab -> Context

not

from-sip-external.

The problem appears to be related to this particular trunk receiving registration rather than sending registration.

I am guessing that in addition to the trunk under discussion, you also have an SPx on the same OBi configured as an extension. So pjsip can’t match by IP (both the same) or by username (you’re using that for caller ID). And FreePBX can’t (yet) tell pjsip to match on auth_username.

Try the pjsip_custom_post.conf workaround near the end of https://issues.freepbx.org/browse/FREEPBX-17803 (requires Asterisk restart).

If you still have trouble, post a detailed log.

The brute-force fix is to use chan_sip for the trunk; you can still use pjsip for the OBi extension(s).

1 Like

True, and it’s PJSIP also.

That looked so promising.

pjsip_custom_post.comf:

[global](+)
endpoint_identifier_order=auth_username,username,ip

FreePBX*CLI> pjsip show identifiers
Identifier Names:
name not specified
auth_username
username
ip
header
anonymous

Unfortunately, incoming calls on this trunk are still from an unknown peer.

I don’t understand what’s going on, because the INVITE wasn’t challenged so it has no auth_username. I suppose you could try setting Authentication Inbound for the trunk, but if it knows to authenticate when you set it, then it already knows which trunk it is! Conceivably, it will authenticate to resolve the ambiguity.

Otherwise, post the relevant lines from a verbose log at the start of a call and maybe there will be a clue.

I changed Authentication from Outbound to Both, but there’s still no challenge:

<--- Received SIP request (848 bytes) from UDP:192.168.1.140:5062 --->
INVITE sip:[email protected]:5060 SIP/2.0
Call-ID: [email protected]
Content-Length: 314
CSeq: 8001 INVITE
From: <sip:[email protected]>;tag=SP31b5e06c77bef5679
Max-Forwards: 70
To: <sip:[email protected]>
Via: SIP/2.0/UDP 192.168.1.140:5062;branch=z9hG4bK-d5cf8c98;rport
User-Agent: OBIHAI/OBi202-3.2.2.5859
Contact: <sip:[email protected]:5062>
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,PRACK,REFER,UPDATE
Content-Type: application/sdp

v=0
o=- 78707646 1 IN IP4 192.168.1.140
s=-
c=IN IP4 192.168.1.140
t=0 0
m=audio 17164 RTP/AVP 0 8 18 104 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:104 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian

  == Setting global variable 'SIPDOMAIN' to '192.168.1.115'
<--- Transmitting SIP response (330 bytes) to UDP:192.168.1.140:5062 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.140:5062;rport=5062;received=192.168.1.140;branch=z9hG4bK-d5cf8c98
Call-ID: [email protected]
From: <sip:[email protected]>;tag=SP31b5e06c77bef5679
To: <sip:[email protected]>
CSeq: 8001 INVITE
Server: FPBX-14.0.4.5(16.99.99)
Content-Length:  0


-- Executing [8705551234@from-sip-external:1] NoOp("PJSIP/anonymous-00000000", "Received incoming SIP connection from unknown peer to 8705551234") in new stack

The only change in pjsip*.conf files was in pjsip.endpoint.conf:

auth=obi202bt

was added to the obi202bt block.

The Authentication setting affects SIP REGISTER’s, not SIP INVITE’s.

That doesn’t look right to me and doesn’t match the hint provided with the setting.

That makes no sense to me. If you have a typical SIP trunk (to a provider), then I believe that setting Authentication Incoming is equivalent to insecure=invite being off in a chan_sip trunk, i.e. it will challenge incoming INVITE. Authentication control on REGISTER seems strange (I’ve never seen a server that would accept a REGISTER request without challenging it).

I agree, Stewart.

If you use Inbound (or Both) which challenges REGISTER’s, the username setting is forced to the trunk name.

Well, I don’t understand what is going on but thought about a possible workaround:

Assuming that calls to/from the extension and outbound calls on the trunk are both ok, try adding a dummy trunk with no registration or authentication and with the OBi IP address in SIP Server (and perhaps also in Match). With luck, after not matching the username it will match the IP address and accept it as onymous.

Damn, you’re good, Stewart!

A minimal PJSIP trunk (obi202btx) configured as you described (no Advanced tab settings needed) gets the job done and inbound calls are now routed to from-pstn as expected and ‘Allow SIP Guests’ can be set to No.

Thank you!

@tm1000

Andrew,

Can you shed some light on what’s going on here? Should a bug report be filed with FreePBX or Asterisk?

I don’t understand the issue to be honest there’s a lot of back and forth here. What exactly do you think freepbx should do. If it’s change any of the defaults in trunk settings we are against that because they are the asterisk defaults and those are the chan_sip defaults. Hints for settings are also taken from the asterisk wiki.

The help for Trunk -> pjsip Settings tab -> General tab -> Authentication says:

Usually, this will be set to ‘Outbound’, which authenticates calls going out, and allows unauthenticated calls in from the other server. If you select ‘None’, all calls from or to the specified SIP Server are unauthenticated. Setting this to ‘None’ may be insecure!

However, this setting determines whether REGISTER’s are authenticated (not INVITE’s). INVITE’s are never authenticated (at least when the Registration option is set to Receive).

When using Registration=Receive, it appears it’s not possible for incoming calls to be matched with the correct endpoint and they always end up going to the anonymous context (from-sip-external). Stewart’s work-around of having a dummy trunk configured for no registration plus manual SIP Server and SIP Server Port settings to collect (match) the incoming call and route it to the desired context is extremely clever, but not a very pretty long-term/permanent fix.

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