IPO 9.1 Sip trunk issues with Sonic (Metaswitch) Platform

[seo1]

We have an IP500v2 on 9.1.200.91 directly connected from the WAN port to a sonic router. When Check OOS is checked on, the trunk goes out of service. When unchecked, the trunk channels go idle, and traffic looks to go through. The calling end hears a steady busy tone, but the system registers the call 100 Trying, 180 Ringing then 200 OK. I see the system route the call to VM, but all I hear on the calling end is busy.

Any assistance would be much appreciated. Here is the monitor log of an incoming call:

16:33:05 1654738mS PRN: Monitor Status IP 500 V2 9.1.2.0 build 91
16:33:05 1654738mS PRN: LAW=U PRI=0, BRI=0, ALOG=0, VCOMP=32, MDM=0, WAN=0, MODU=0 LANM=0 CkSRC=0 VMAIL=1(VER=2 TYP=3) 1-X=0 CALLS=0(TOT=5)
16:33:07 1656224mS SIP Rx: UDP 50.1.xxx.132:5060 -> 184.23.xxx.xxx:5060
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 50.1.110.132:5060;branch=z9hG4bK+b60c52cda44a7e3db 1f04cebfa641c371+sip+1+cb5ad96c
From: "SAN FRANCSCOCA" <sip:[email protected]:5060>;tag=50.1.xxx.13 2+1+32f55bab+6e4c6de6
To: <sip:[email protected]>
CSeq: 490165621 INVITE
Expires: 180
Content-Length: 190
Call-Info: <sip:50.1.xxx.xxx:5060>;method="NOTIFY;Event=telep hone-event;Duration=2000"
Supported: resource-priority, 100rel
Contact: <sip:[email protected] :5060>
Content-Type: application/sdp
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event
Call-ID: 0gQAAC8WAAACBAAALxYAAI1C8g+9URuy/[email protected]
Organization: Metaswitch Networks
Max-Forwards: 69
Accept: application/sdp, application/dtmf-relay

v=0
o=- 28980188862895 28980188862895 IN IP4 50.1.xxx.xxx
s=-
c=IN IP4 50.1.xxx.xxx
t=0 0
m=audio 60628 RTP/AVP 0 8 2 18 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=ptime:20
16:33:07 1656227mS SIP Call Rx: 17
INVITE sip:[email protected]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 50.1.xxx.132:5060;branch=z9hG4bK+b60c52cda44a7e3db 1f04cebfa641c371+sip+1+cb5ad96c
From: "SAN FRANCSCOCA" <sip:[email protected]:5060>;tag=50.1.xxx.13 2+1+32f55bab+6e4c6de6
To: <sip:[email protected]>
CSeq: 490165621 INVITE
Expires: 180
Content-Length: 190
Call-Info: <sip:50.1.xxx.132:5060>;method="NOTIFY;Event=telep hone-event;Duration=2000"
Supported: resource-priority, 100rel
Contact: <sip:[email protected] :5060>
Content-Type: application/sdp
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event
Call-ID: 0gQAAC8WAAACBAAALxYAAI1C8g+9URuy/[email protected]
Organization: Metaswitch Networks
Max-Forwards: 69
Accept: application/sdp, application/dtmf-relay

v=0
o=- 28980188862895 28980188862895 IN IP4 50.1.xxx.132
s=-
c=IN IP4 50.1.xxx.132
t=0 0
m=audio 60628 RTP/AVP 0 8 2 18 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=ptime:20
16:33:07 1656228mS CMCallEvt: 0000000000000000 0.1021.0 -1 BaseEP: NEW CMEndpoint f1965b4c TOTAL NOW=1 CALL_LIST=0
16:33:07 1656228mS Sip: SIP Line (17): sip_trunk_config_items 00000001, voip.flags 00000949
16:33:07 1656228mS Sip: SIPDialog f19642b4 created, dialogs 1
16:33:07 1656229mS Sip: SIP Line (17): License, Valid 1, Available 10, Consumed 0
16:33:07 1656230mS Sip: SIPTrunkEndpointDialogOwner::SetRemoteAddressForRe quest from 50.1.xxx.132:5060 to 50.1.xxx.132:5060
16:33:07 1656231mS Sip: SIPTrunkEndpointDialogOwner::SetRemoteAddressForRe sponse from 50.1.xxx.132:5060 to 50.1.xxx.132:5060
16:33:07 1656232mS SIP Call Tx: 17
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 50.1.xxx.132:5060;branch=z9hG4bK+b60c52cda44a7e3db 1f04cebfa641c371+sip+1+cb5ad96c
From: "SAN FRANCSCOCA" <sip:[email protected]:5060>;tag=50.1.110.13 2+1+32f55bab+6e4c6de6
Call-ID: 0gQAAC8WAAACBAAALxYAAI1C8g+9URuy/[email protected]
CSeq: 490165621 INVITE
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INFO,NOTIFY,UPDATE
Supported: timer
Server: IP Office 9.1.2.0 build 91
To: <sip:[email protected]>;tag=0a5b2ea4836bfbf 5
Content-Length: 0

[havel3]

Route the call to a extension and see if it rings and if you can have a connection.
If that works then send it to VM and make a trace without the SIP options and post it here.
If it doesn't work make a trace of that call, SIP included and post it here.

[zakabog]

When Check OOS is checked on, the trunk goes out of service. When unchecked, the trunk channels go idle, and traffic looks to go through.

Check OOS means "Check if this trunk is out of service" if you uncheck that then the PBX just assumes that the trunk is up and goes along it's merry way sending data. Do you have an IP to IP trunk or does your IP Office register to the SIP carrier? Are you able to make calls out? I would suggest doing as havel3 suggested and setup the incoming call route to point to an extension and see if you can answer it with two way audio. Otherwise you might have an issue with your SIP trunk setup.

Usually when I see Sonicwall and SIP trunk together I think "That's going to be an issue." Unless you're knowledgeable enough with Sonicwalls to know all of the settings required to pass VoIP traffic, then just expect there to be problems.