NO JOY Lost Trunk Registration

[john p]

Over the weekend, both my Vitelity & Vestalink tunks have lost registration to my Pi2 PIAF. It had been solid for months. From the console, I can ping Vitelity normally but get no response fom Vestalink. I've tried restarting Asterisk & the server, with no effect. Below is a sanitized summary of the Asterisk log.

Any ideas greatly appreciated.

Connected to Asterisk 11.9.0 currently running on Pi-PBX (pid = 3132)
Pi-PBX*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
inbound28.vitelity.net:5060 N xxx 120 Request Sent
sms.intelafone.com:5060 N xxx 120 Request Sent
2 SIP registrations.
[2015-05-25 06:32:39] NOTICE[3163]: chan_sip.c:15182 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2015-05-25 06:32:39] NOTICE[3163]: chan_sip.c:15182 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2015-05-25 06:32:39] NOTICE[3163]: chan_sip.c:15182 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2015-05-25 06:32:39] NOTICE[3163]: chan_sip.c:15182 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #2)
[2015-05-25 06:33:11] WARNING[3163]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[2015-05-25 06:33:11] WARNING[3163]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[2015-05-25 06:33:11] WARNING[3163]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
[2015-05-25 06:33:11] WARNING[3163]: chan_sip.c:4176 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
Pi-PBX*CLI>

 

[john p]

To follow up, I verified U-Verse gateway & local router behind it settings correct. Also replaced Pi2 with backup unit (known working when removed) with same problem.

 

[atsak]

To follow up, I verified U-Verse gateway & local router behind it settings correct. Also replaced Pi2 with backup unit (known working when removed) with same problem.

Is the U-Verse gateway an ADSL product or their FTTN (whatever it's called)? Their ADSL gateway was terrible. What "local router" is in use?

 

[john p]

Gateway is Pace 3801 (FTTN) & local router, in DMZ, is a DD-WRT Linksys. I've had this problem before & Vitelity had me change the trunk name to one of their test names. Doing so this time resulted in immediate trunk registration. No change in VesaLink but this seems to indicate it is their problem.

 

[atsak]

OK have you tried rebooting the router and modem, just to see?

 

[john p]

Yep. No effect. I've concluded the issue is with the 2 trunk providers since changing the specific Vitelity trunk to a test trunk they had provided last year when I had the same issue resulted in successful registration and calling. I've opened tickets with both & am awaiting feedback.

 

[atsak]

I disagree with your conclusion - the odds of two providers having exactly the same problem are astronomically high with no other reports of similar issues. More likely an intermediary internet peering partner that is common between the two is having a problem or there's something going on with your internet connection - a reboot should have fixed that though. Having said that they may be able to work around it with you, which is an equally pleasing outcome in the end.

 

[john p]

I am not certain what is happening but note that when I changed the specific Vitelity trunk (i.e., from, for example, inbound1.vitelity.net to inbound-test.vitelity.net), registration was immediately successful and has been maintained. I'm not sure I see how a problem in the internet would have the different effect to trunks in the same domain & note both trunks are pingable. Also, this has been a recurring issue with Vitelity, 2~3 times per year.

 

[john p]

I just got more confused. VestaLink said everything was the same on their end so I modified the config for 1 of the Grandstream SIP phones normally regist4ering to the PBX to point to sms.intelafone.com & it registered & handled calls fine. This makes me think it is a PBS issue on my end but I don't know what to try.

 

[john p]

Following up, Vestalink says they don't support PBX but setting look fine. For now, I've disabled trunk & will see if time heals or new ideas occur.

 

[john p]

FYI SIP trunk settings

username=(redacted)
type=peer
secret=(redacted)
port=5060
qualify=off
insecure=port,invite
host=sms.intelafone.com
fromuser=(redacted)
fromdomain=sms.intelafone.com
disallow=all
context=from-trunk
allow=ulaw

 

[billsimon]

John, turn on sip debugging and see what packets are sent and received to these providers. At the Asterisk console: sip set debug on

 

[john p]

Thanks for the suggestion. Tonight, after the trunk was disabled for about 5 hours, I reenabled it & it immediately registered. Below is asanitized excerpt from the log with sip debug on. Any insights appreciated but note all trunks seem to be registered & operating properly at this time.

Log Excerpt

--- (7 headers 0 lines) ---
Really destroying SIP dialog '[email protected]:5060' Method: NOTIFY
[2015-05-25 21:29:12] NOTICE[3149]: chan_sip.c:15106 sip_reregister: -- Re-registration for [email protected]
[2015-05-25 21:29:12] NOTICE[3149]: chan_sip.c:15106 sip_reregister: -- Re-registration for [email protected]
REGISTER 11 headers, 0 lines
Reliably Transmitting (no NAT) to 52.10.35.17:5060:
REGISTER sip:sms.intelafone.com SIP/2.0
Via: SIP/2.0/UDP 99.10.217.148:5060;branch=z9hG4bK5ae40982
Max-Forwards: 70
From: <sip:[email protected]>;tag=as35332c35
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 105 REGISTER
User-Agent: FPBX-2.11.0(11.9.0)
Authorization: Digest username="xxxx", realm="sms.intelafone.com", algorithm=MD5, uri="sip:sms.intelafone.com", nonce="VWPa0lVj2abLXLIdXTM0LzuLnFJvME9t", response="45676d2a73fef23c35399def3ed0522e"
Expires: 120
Contact: <sip:[email protected]:5060>
Content-Length: 0


---

<--- SIP read from UDP:52.10.35.17:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 99.10.217.148:5060;branch=z9hG4bK5ae40982;rport=5060
From: <sip:[email protected]>;tag=as35332c35
To: <sip:[email protected]>;tag=fdeda933d9da749cdd8f22d478d2ac40.971b
Call-ID: [email protected]
CSeq: 105 REGISTER
Contact: <sip:[email protected]:5060>;expires=120
Server: kamailio (4.1.4 (x86_64/linux))
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
[2015-05-25 21:29:12] NOTICE[3149]: chan_sip.c:23595 handle_response_register: Outbound Registration: Expiry for sms.intelafone.com is 120 sec (Scheduling reregistration in 105 s)
[2015-05-25 21:29:12] NOTICE[3149]: chan_sip.c:23595 handle_response_register: Outbound Registration: Expiry for sms.intelafone.com is 120 sec (Scheduling reregistration in 105 s)
Really destroying SIP dialog '[email protected]' Method: REGISTER