Level(3) SIP Trunk -- Option Ping Dies

Hi,

I am now in week seven of trying to get Level(3) SIP trunking to work consistently. They tell us that under our standard config, our server periodically stops responding to option pings (same as “qualify”?) and the trunk will go offline as a result, then inexplicably, it will return to service anywhere from 5 to 25 minutes later.

We tried turning on qualify (not a default for their trunks) and the behavior got worse, except that it was “their end” that stopped replying to our qualify.

I observed during testing that when both sides turn off option ping / qualify–we can get 100 simultaneous channels to remain open for 30+ minutes. But, if either side turns qualify/option-ping back on, within 5 minutes, the trunk dies and all calls drop.

When one of my engineers tests with Level(3), he says that the presence nor absence of qualify/option-ping has no effect and the trunk just periodically dies.

I am hoping someone here has some experience with Level(3) SIP trunking?

Here are some relevant details:

Connection from FreePBX server is direct to public IP on Level(3) circuit, with a bridging firewall in betweeen–but we have already tried removing the firewall and the exact same behaviors occur so we have ruled out the firewall.

FreePBX Distro: 2.11.0.10
Asterisk 11.4.0 built by root @ jenkins-el6-64.schmoozecom.net on a x86_64 running Linux on 2013-06-02 15:27:41 UTC

From sip_additional.conf:

[Level3in]
username=REDACTED
secret=REDACTED
type=friend
nat=auto
insecure=port,invite
host=4.55.60.142
allow=all
context=from-trunk
dtmfmode=auto
canreinvite=yes
port=5070
qualify=no

[Level3Out]
type=peer
dtmfmode=auto
context=from-pstn
host=4.55.60.142

From sip_general_additional.conf:

accept_outofcall_messages=yes
auth_message_requests=no
outofcall_message_context=dpma_message_context
vmexten=*97
faxdetect=yes
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
useragent=FPBX-2.11.0(11.4.0)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
session-timers=refuse
callevents=yes
jbenable=no
registertimeout=20
defaultexpiry=120
minexpiry=60
maxexpiry=3600
checkmwi=10
notifyringing=yes
notifyhold=yes
rtpkeepalive=15
rtpholdtimeout=300
srvlookup=no
allowguest=yes
registerattempts=0
rtptimeout=30
g726nonstandard=no
videosupport=no
maxcallbitrate=384
canreinvite=yes
nat=no

All of our other SIP trunks work just fine, regardless of whether they use qualify or not.

Is more information needed, or can someone point me in the right direction?

Thanks!

I have exactly the same problem as yourself and I’ll be very interested to see how your situation plays out.

We have intermittent responses to SIP OPTIONS which results in the signalling group being taken down until they start (randomly) responding again.

I’m also now in the 8th week of this being unresolved.

I’ll be keeping a close eye on your thread!

This must not be Level 3 LI service. We use LI on the wholesale without any issues but it IP authenticates.

I would like to see clearer information. If you do a wire shark are you saying that the remote end stops responding to SIP messages?

Are you sure your firewall is not timing out the xlate?