Sticky or Hidden registration data?

configuration
trunk
Tags: #<Tag:0x00007f7021918d48> #<Tag:0x00007f7021918b68>

(Matthew Mellen) #1

Sorry for the rambling… This problem has got me flustered.

I have a FreePBX 15.0.16.75 setup running. It’s been running for the past few years with two sip trunks provided by Fusion (Formerly Broadvox). After a few hiccups with their registration process and FQDN issues, It was working decent. I have a few remote extensions in which a connection is made over a hardware VPN. Three of these extensions were solely setup to use Sip Trunk A. They had their own ring group etc… These 3 started to suffer, and I thought it was the internet causing issues with the VPN as pings to the location were rather erratic. Rather than fight the ISP more, I decided to just deploy a local PBX for this location and setup an IAX trunk. In my mind, only the IAX trunk connections would suffer (inter PBX routing), which is seldom if ever used.

Easy setup and deployment, but I’m seeing strange behavior with the two separate trunks provided by Fusion. Two completely separate user and pass, but the same registration server. I’ve removed the Trunk and routes completely from PBX A and put said registration into PBX B. Worked fine after a fwconsole restart on PBX A. Everything works as it should. However… Throughout the day, registration will revert back to PBX A (where no routes are setup). This is a simple fix, fwconsole restart in both PBX brings the registration back.

When I contact the provider about this, they blame the PBX setup. Also, since I’ve generally resolved the issue by issuing the fwconsole restart command, they only see the one registration for the correct PBX external IP.

Sorry for the ramble… I guess my question here would be: Is there a configuration file somewhere that I can check for stale registration data?


#2

Outbound and Inbound Routes do not affect trunks; they will still register without any routes. You need to either Disable or delete the trunks. Possibly, there is a bug associated with Disable.

You should be able to see trunk registration entries for pjsip in /etc/asterisk/pjsip.registration.conf and for legacy chan_sip in /etc/asterisk/sip_additional.conf. If you delete a trunk then do an fwconsole restart, the entries should be gone.

Other tools that may be useful are the Asterisk commands
pjsip set logger on
sip set debug on
which will cause all SIP traffic (including registrations) to be included in the regular Asterisk log.

Or, you can run tcpdump to capture traffic to a file, that you would later analyze with Wireshark.


(Matthew Mellen) #3

Thanks for the reply!

The trunks are indeed deleted from PBX A. That’s what’s most confusing. I checked the sip_additional.conf file and the only registration data in there is for the correct trunk associated with PBX A.

currently running egrep to find any instance of the BTN that shouldnt be registered on PBX A


(Matthew Mellen) #4

It almost looks like the SIP provider is sending requests to register the incorrect BTN over to PBX A? Sip Debug shows this, without any prior attempts to register the incorrect BTN:

<— SIP read from UDP:64.190.248.6:5060 —>
INVITE sip:WRONG_BTN#@PBX_A_External:5060 SIP/2.0
Via: SIP/2.0/UDP 64.190.248.6;rport;branch=regdata
Max-Forwards: 69
From: “WIRELESS CALLER” sip:XXXXXXXXX@64.190.248.6;tag=regdata
To: sip:WRONG_BTN#@PBX_A_External:5060
Call-ID: regdata
CSeq: 26575618 INVITE
Contact: sip:XXXXXXXXX@64.190.248.6:5060
User-Agent: Broadvox Fusion
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 271
P-Asserted-Identity: “WIRELESS CALLER” sip:XXXXXXXXX@64.190.248.6

I’ve stripped identifying information obviously…