SOLVED Extensions/Contacts cycling between register and deleted

Joined
May 16, 2011
Messages
94
Reaction score
0
My extension will register and then a few seconds delete. This is happening on the trunk as well. Extensions are on a different network behind a Sonicwall. I have moved the server to a public IP to eliminate this side's firewall. Still the same thing. I am using PJSIP UDP. Here is a bit of the asterisk cli.Less than half the phones are even trying to register. Phones are all behind Sonicwalls.

== Endpoint 331 is now Reachable
-- Contact 331/sip:[email protected]:15258 is now Reachable. RTT: 571.627 msec
== Contact 571/sip:[email protected]:15283 has been deleted
== Endpoint 571 is now Unreachable
== Contact 214/sip:[email protected]:14605 has been deleted
== Endpoint 214 is now Unreachable
== Endpoint 301 is now Unreachable
-- Contact 301/sip:[email protected]:15284 is now Unreachable. RTT: 0.000 msec
[2018-12-19 14:43:13] WARNING[7519]: res_pjsip_outbound_registration.c:1229 handle_registration_response: Fatal response '400' received from 'sip:us-east-nj.sip.flowroute.com' on registration attempt to 'sip:[email protected]', stopping outbound registration
-- Added contact 'sip:[email protected]:15082' to AOR '123' with expiration of 60 seconds
-- Contact 123/sip:[email protected]:15082 is now Unreachable. RTT: 0.000 msec
-- Added contact 'sip:[email protected]:14793' to AOR '512' with expiration of 60 seconds
-- Contact 512/sip:[email protected]:14793 is now Unreachable. RTT: 0.000 msec
== Endpoint 531 is now Reachable
-- Contact 531/sip:[email protected]:15295 is now Reachable. RTT: 1537.436 msec
-- Added contact 'sip:[email protected]:14802' to AOR '112' with expiration of 60 seconds
-- Contact 112/sip:[email protected]:14802 is now Unreachable. RTT: 0.000 msec
-- Added contact 'sip:[email protected]:14976' to AOR '221' with expiration of 60 seconds
== Contact 101/sip:[email protected]:15105 has been deleted
== Endpoint 101 is now Unreachable
== Contact 341/sip:[email protected]:5060 has been deleted
== Endpoint 341 is now Unreachable
== Contact 661/sip:[email protected]:14598 has been deleted
== Endpoint 661 is now Unreachable
== Endpoint 221 is now Reachable
-- Contact 221/sip:[email protected]:14976 is now Reachable. RTT: 1530.648 msec
-- Added contact 'sip:[email protected]:15259' to AOR '521' with expiration of 60 seconds
-- Added contact 'sip:[email protected]:14790' to AOR '523' with expiration of 60 seconds
== Endpoint 523 is now Reachable
-- Contact 523/sip:[email protected]:14790 is now Reachable. RTT: 1539.154 msec
-- Contact 521/sip:[email protected]:15259 is now Unreachable. RTT: 0.000 msec
== Endpoint 301 is now Reachable
-- Contact 301/sip:[email protected]:15284 is now Reachable. RTT: 29.463 msec
== Endpoint 113 is now Reachable
-- Contact 113/sip:[email protected]:14789 is now Reachable. RTT: 35.360 msec
-- Added contact 'sip:[email protected]:14812' to AOR '712' with expiration of 60 seconds
-- Added contact 'sip:[email protected]:15105' to AOR '101' with expiration of 60 seconds
== Endpoint 101 is now Reachable
-- Contact 101/sip:[email protected]:15105 is now Reachable. RTT: 532.716 msec
-- Contact 712/sip:[email protected]:14812 is now Unreachable. RTT: 0.000 msec
-- Added contact 'sip:[email protected]:14591' to AOR '211' with expiration of 60 seconds
== Endpoint 513 is now Reachable
-- Contact 513/sip:[email protected]:15101 is now Reachable. RTT: 35.671 msec
== Endpoint 322 is now Reachable
-- Contact 322/sip:[email protected]:15269 is now Reachable. RTT: 30.854 msec
pbx1*CLI> pjsip show contacts
Contact: <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>
==========================================================================================
Contact: 101/sip:[email protected]:15105 8e37759daa Avail 532.716
Contact: 112/sip:[email protected]:14802 a0c96f75d8 Unavail nan
Contact: 113/sip:[email protected]:14789 16523520a6 Avail 35.360
Contact: 121/sip:[email protected]:35901 cf04f486dc Avail 49.656
Contact: 122/sip:[email protected]:15252 ca1c28a6b8 Avail 37.873
Contact: 123/sip:[email protected]:15082 521ff4e615 Unavail nan
Contact: 211/sip:[email protected]:14591 0cc9e4dbb9 NonQual nan
Contact: 221/sip:[email protected]:14976 c4dda61195 Avail 1530.648
Contact: 301/sip:[email protected]:15284 9638c11b86 Avail 29.463
Contact: 3011/sip:[email protected]:27767 be1f0cd3c5 Unavail nan
Contact: 331/sip:[email protected]:15258 f58b999d4d Avail 34.991
Contact: 512/sip:[email protected]:14793 48bc8ad124 Unavail nan
Contact: 521/sip:[email protected]:15259 4603a5ea5c Unavail nan
Contact: 522/sip:[email protected]:15274 9c899d02f2 Avail 27.930
Contact: 523/sip:[email protected]:14790 ec4553845b Avail 1539.154
Contact: 531/sip:[email protected]:15295 f7c6f5ff5b Avail 1537.436
Contact: 541/sip:[email protected]:15293 1898e4ff25 Avail 535.222
Contact: 711/sip:[email protected]:15098 810ab5f69b Unavail nan
Contact: 7111/sip:[email protected]:23613 5f060e0137 Unavail nan
Contact: 712/sip:[email protected]:14812 d3526d1fe1 Unavail nan
Contact: 999/sip:[email protected]:9683 fc106d73d7 Avail 1.783
Contact: Flowroute/sip:[email protected] 4ed1eb52bb Avail 451.534
Objects found: 22
== Contact 322/sip:[email protected]:15269 has been deleted
== Endpoint 322 is now Unreachable
== Contact 513/sip:[email protected]:15101 has been deleted
== Endpoint 513 is now Unreachable
== Endpoint 123 is now Reachable
-- Contact 123/sip:[email protected]:15082 is now Reachable. RTT: 1537.910 msec
-- Contact 211/sip:[email protected]:14591 is now Unreachable. RTT: 0.000 msec
pbx1*CLI>
 

Attachments

  • Capture.JPG
    Capture.JPG
    29 KB · Views: 4
Joined
May 16, 2011
Messages
94
Reaction score
0
FYI - This situation is the result of HiFormance pulling the plug. We are trying to recreate the PBX locally.
 

tbrummell

Guru
Joined
Jan 8, 2011
Messages
1,275
Reaction score
339
Have you tried stopping IPTables to make sure it's not throttling the connections? (Don't leave it that way obviously) What is the Qualify Frequency set at? Have you tried switching a phone to TCP and see if that resolves things? What if you put a phone/SIP CLient *outside* of the Sonicwall, say, your cell phone? Tell us what you have tried.
You could also switch to chan_sip since it's 100x more reliable yet.
 
Joined
May 16, 2011
Messages
94
Reaction score
0
Follow up.
I moved the PBX inside the end user facility. The disconnects stopped. Maybe a bandwidth issue or SONICWALLs. In caps because I scream the name in vain!
When the PBX was here I had it behind our Sonicwall. The end user also has a Sonicwall. VPN between the two locations is not acceptable. Using Firewall Rules and NAT policies allows the PBX to talk with the Trunk provider and the end user extensions. I also tried moving the PBX outside our firewall directly on the internet. A bit scary. It did not solve the issue.
So I picked up the PBX and brought it to their facility. After adjusting their Sonicwall and IPTables, I eventually got the PBX to talk with the Trunk provider and their internal extensions. I noticed two things:
1.) Their remote extensions will not connect. Most of these are not behind Sonicwalls; just ISP routers (Comcast, Verizon, Google).
2.) Intermittently inbound calls from the Trunk provider failed to reach the PBX. I have seen this issue forever with virtually all our PBXes and believed it to be an anomaly with the PBX software or its configuration.
It turns out it is the Sonicwalls not passing UDP packets inbound despite all the rules and NAT policies being correct. Dell and I worked on this for 8 hours on Friday with no success. Packet monitors show the remote extensions having all their UDP packets inbound to the Sonicwall blocked. The Trunk UDP are intermittently blocked. I suspect intermittently blocked because when the PBX sends out a register request it opens a hole in the Sonicwall to the Trunk provider. The UDP timeout by default on the Sonicwall is 30 seconds. The timeout on the PJSIP trunk by default is 3600 seconds and I have Qualify Frequency at 60 seconds.. I adjusted the Sonicwall to 350 seconds. Hopefully this will prevent the intermittent inbound call issue.

Regarding tbrummell suggestions:
1.) IPTables restarted many times and rules were verified.
2.) Qualify Frequency is at 60 seconds
3.) Switching the remote phones to TCP gets them to register :) but I get no audio either way on a call :-(. Do you know why this would be? Apparently the Sonicwall rule works for TCP but not UDP. We have adjust the rule to be Any service passed.

I will speak again to Sonicwall tomorrow. Hopefully they have a resolution. If not time to abandon Sonicwall. I have units behind Watchguard without this issue.
 

tbrummell

Guru
Joined
Jan 8, 2011
Messages
1,275
Reaction score
339
Uggg, Sonicwall. Complaints about SIP and them all over the web. Rip it out, drop in a pfSense (or similar) and be done with it. :)

Since TCP works but loses audio, it has to be Sonicwall's handling of the NAT UDP. They have a SIP ALG right? Can it be disabled? I think I read somewhere it has to be done at a command line interface, can't be done in the UI.
 

islandtech

Wassamassaw
Joined
Jan 11, 2009
Messages
677
Reaction score
137
After years of fighting ISP routers, Sonicwall, pfSense, Astaro, and consumer grade routers I settled on Ubiquiti Edgemax line of routers.
 

Members online

No members online now.

Forum statistics

Threads
25,782
Messages
167,509
Members
19,202
Latest member
pbxnewguy
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top