SIP Trunk Issue

[bluewhite4]

Have a customer who has been upgraded to 4.2 and now has purchased SIP trunks from Bandwidth.com

5 trunks have been setup, and are only used for long distance outbound calls. We have issues with every out bound call, where after being answered, the call disconnects after ~22 seconds.

With Wireshark traces, we can see that the 3300 never send the ACK of the call to Bandwidth's Edgewater, so Bandwidth assumes that the call never connects and sends a Bye message. The 3300 does respond to the bye. Anyone seen or heard of something similar? I've got Mitel researching this, but they can't think of a reason for the issue.

I can attached the SIP message trace.

[Mitel100]

Can you supply the SIP options you have enabled on the SIP trunk.

[bluewhite4]

Per Mitel's Bandwidth.com SIP Trunk guide:

SIP Peer Profile Label: Bandwidth
Network Element: ca7236c0-f25c-11df-9038-08000f4c1604
Registration User Name:
Address Type: IP Address: 192.168.1.2
Interconnect Restriction: 1
Maximum Simultaneous Calls: 5
Outbound Proxy Server:
SMDR Tag: 0
Trunk Service: 3
Zone: 1
Alternate Destination Domain Enabled: No
Alternate Destination Domain FQDN or IP Address:
Enable Special Re-invite Collision Handling: No
Private SIP Trunk: No
Route Call Using To Header: No
Default CPN:
CPN Restriction: No
Public Calling Party Number Passthrough: Yes
Use Diverting Party Number as Calling Party Number: No
User Name:
Password:
Confirm Password:
Authentication Option for Incoming Calls: No Authentication
Subscription User Name:
Subscription Password:
Subscription Confirm Password:
Allow Peer To Use Multiple Active M-Lines: No
Allow Using UPDATE For Early Media Renegotiation: No
Avoid Signaling Hold to the Peer: No
Enable Mitel Proprietary SDP: No
Force sending SDP in initial Invite message: No
Force sending SDP in initial Invite - Early Answer: No
Limit to one Offer/Answer per INVITE: No
NAT Keepalive: No
Prevent the Use of IP Address 0.0.0.0 in SDP Messages: No
Renegotiate SDP To Enforce Symmetric Codec: No
Repeat SDP Answer If Duplicate Offer Is Received: No
RTP Packetization Rate Override: No
RTP Packetization Rate: 20ms
Special handling of Offers in 2XX responses (INVITE): No
Suppress Use of SDP Inactive Media Streams: No
Allow Display Update: No
Build Contact Using Request URI Address: No
Disable Reliable Provisional Responses: Yes
Disable Use of User-Agent and Server Headers: No
Enable sending '+' for E.164 numbers: Yes
Force Max-Forward: 70 on Outgoing Calls: No
Ignore Incoming Loose Routing Indication: No
Use P-Asserted Identity Header: No
Use Restricted Character Set For Authentication: No
Use To Address in From Header on Outgoing Calls: No
Registration Period: 3600
Registration Period Refresh (%): 50
Session Timer: 90
Subscription Period: 3600
Subscription Period Minimum: 300
Subscription Period Refresh (%): 80
Allow Inc Subscriptions for Local Digit Monitoring: No
Allow Out Subscriptions for Remote Digit Monitoring: No
Force Out Subscriptions for Remote Digit Monitoring: No
Request Outbound Proxy to Handle Out Subscriptions: No
KPML Transport: default
KPML Port: 0

[Mitel100]

One thing thats might need to change is the following:

Force sending SDP in initial Invite message: No

Change this to Yes.

I can look at this further tomorrow.

[bluewhite4]

I actually had that set to yes prior to working with Mitel, and they yelled at me b/c the Bandwidth guide doesn't say to have it set that way. So to humor them, I changed it back. It doesn't make a difference either way however.

[bluewhite4]

Just as an update....

After working with Mitel and then Bandwidth we found the issue. The Bandwidth Edgewater is sitting in the DMZ of the customer's SonicWall Firewall. Seems that unannounced to us, there is/was a bug in the older SonicWall firewall where when you check-box to turn off the VOIP settings of the SonicWall, it actually turns them on. So the opposite was true as well, and once they were turned off, everything began to run smoothly.