Details…
Core 2.8.1.2 FreePBX
DAHDi Config 2.8.0.1 Digium
Feature Code Admin 2.8.0.1 FreePBX
FreePBX ARI Framework 2.8.0.6 FreePBX
FreePBX FOP Framework 2.8.0.6 FreePBX
FreePBX Framework 2.8.1.4 FreePBX
FreePBX Localization Updates 2.8.1.1 FreePBX
System Dashboard 2.8.0.3 FreePBX
Voicemail 2.8.0.0 FreePBX
System as a single SIP trunk through a company called 2talk. The customer has not ported their copper based numbers yet so there is a port forward setup by the existing telco onto the temporary pilot number on the voip trunk.
Trunk is behind NAT, VOIP traffic prioritised. Numbers and all equipment is based in New Zealand.
FreePBX operates fine with the exception of one problematic number.
Problem…
When the problematic local number is dialed it rings three or four times, then there is a ‘blip’ sound and then silence before the call is terminated.
This number is an out of hours answering service and will need to be setup with a Time Control, but for now even direct dialing of this number fails.
A trace on the SIP traffic has shown that there is a 489 bad event logged just before the call termination. This is the key event from that trace and I have obfuscated some details for security ( 111.222.333.444 is the FreePBX, 06912345 is the problem number )
U 111.222.333.444:5060 -> 202.180.76.164:5060
SIP/2.0 489 Bad event…
Via: SIP/2.0/UDP 202.180.76.164:5060;branch=z9hG4bK10de82fb;received=202.180.76.164;rport=5060…
From: “2talkpbx” sip:[email protected];tag=as5a5fb700…
To: sip:[email protected]:5060;tag=as5158b cc1…
Call-ID: [email protected]…
CSeq: 102 NOTIFY…
Server: FPBX-2.8.1(1.8.8.0)…
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH…
Supported: replaces, timer…
Content-Length: 0…
This seems to be saying that the 2Talk server is reporting a ‘bad event’ that has occured in it’s negociation with the phone system where the problem number, but that this doesn’t necessairily mean there is an issue with the FreePBX.
I have been told that the problematic number is hosted on an ‘all-copper’ system.
Investigation so far…
Testing has shown that the number failure is consistent - dial the number directly or from a ring group and if fails just the same. I can dial the problem number from a mobile or alternate land line and it works.
I found a forum post at http://forums.digium.com/viewtopic.php?f=1&t=72507&p=140036 which seems to suggest a similar situation ( admittedly it’s a couple a years old in terms of versions ). The following quote from the link…
“What I’m actually saying is that Asterisk (source code for 1.6.1.0) only recognizes Refer events in NOTIFY requests. It shouldn’t be getting others, because it will not have subscribed to them. You need to stop your equipment issuing unsolicited NOTIFYs, if you don’t want Asterisk to reject them.”
…seems to suggest that in my specific case the phone equipment at the problematic number end of things could be spitting out a response which the 2talk systems dutifully report back but which the FreePBX system doesn’t know how to respond to.
Questions…
Does my suggestion regarding the unhandled response sound like a feasible event to generate this sort of response? If so what is the best way to pin this down?
Whats the best approach to tracing SIP traffic at the ‘local’ end? Wireshark or similar?
Is there anything I can alter at the FreePBX end to mitigate this issue?
Any other tips or ideas on how to investigate this issue further would be very welcome.
Many Thanks
Paul.