SIP Trunking HOLD problem

[vlevalois]

I have 1 SIP Trunk configured and working on a Mitel 3300 MCD 4.0 UR1 with the following SIP PEER PROFILE options:

SDP Options
Allow Peer To Use Multiple Active M-Lines: No
Enable Mitel Proprietary SDP: No
Force sending SDP in initial Invite message: No
Force sending SDP in initial Invite - Early Answer: Yes
NAT Keepalive: No
Prevent the Use of IP Address 0.0.0.0 in SDP Messages: Yes
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: Yes


Signaling and Header Manipulation Options
Session Timer: 90
Build Contact Using Request URI Address: No
Disable Reliable Provisional Responses: Yes
Enable sending '+' for E.164 numbers: No
Ignore Incoming Loose Routing Indication: No
Use P-Asserted Identity Header: No
Use P-Preferred Identity Header: No
Use Restricted Character Set For Authentication: No
Use To Address in From Header on Outgoing Calls: No


Any way I slice these options, I'm having the same problem, which is placing a call on HOLD from the IP station (and with MOH turned on with Embedded) causes the call to get lost. It doesn't disconnect right away. The caller does not hear MOH and the IP Phone (5360) can retrieve the call but there's no one there.

If I turn off MOH, the call gets held @ the SIP provider and the caller hears the provider's music, AND the call CAN be retrieved from hold. Problem is that this scenario doesn't work well for Dynamic Extension and transfers.

Topology: 192.168.253.x = phones and 3300 (DHCP reject from 192.168.254.1 and redirected to 253.x subnet, 3300 is DHCP there) - 192.168.254.4 is gateway/proxy for SIP trunk (Edgemarc 200A), with programmed route for use of separate Sonicwall router for VLAN routing.

Here's more info about the call from Maintenance Commands:

1) Link: Telcentri Profile: SIP ID: 10733ca8(158)-61
Started at TUE DEC 15 14:25:04 2009
Calling: 18185556066@192.168.254.4
Called: 18185551630@192.168.254.4
State: StateEstablished
MediaState: StateMediaAnswered (1,16)
Call-ID: fd23c92d7ed12e3125f3c82e098c5f52-6b59e@216.151.151.175
Media Audio sendrecv Remote IP:192.168.254.4:16580 Local IP:192.168.253.115:50244

Call placed on HOLD from the IP Phone:

1) Link: Telcentri Profile: SIP ID: 10733ca8(158)-61
Started at TUE DEC 15 14:25:04 2009
Calling: 18185556066@192.168.254.4
Called: 18185551630@192.168.254.4
State: StateEstablishedOutReqOfferWaitForInOffer
MediaState: StateMediaAnswered (4,0)
Call-ID: fd23c92d7ed12e3125f3c82e098c5f52-6b59e@216.151.151.175
Media Audio sendrecv Remote IP:192.168.254.4:16580 Local IP:192.168.253.115:50244

Call retrieved from HOLD on the IP Phone (dead air):

1) Link: Telcentri Profile: SIP ID: 10733ca8(158)-61
Started at TUE DEC 15 14:25:04 2009
Calling: 18185556066@192.168.254.4
Called: 18185551630@192.168.254.4
State: StateEstablishedOutReqOfferWaitForInOffer
MediaState: StateMediaAnswered (4,0)
Call-ID: fd23c92d7ed12e3125f3c82e098c5f52-6b59e@216.151.151.175
Media Audio sendrecv Remote IP:192.168.254.4:16580 Local IP:192.168.253.115:50244

Any assistance would be appreciated!

Vince

 

[slapin]

I have the same issue. The only difference is that I use a small Asterisk PBX as a SIP trunking gateway/proxy. I configured the same MOH as on the controller, so when a call is placed on hold, the remote party will hear it from the Asterisk box. I tried different options and it appeares to me like a system-wide problem. Apparently the problem is in implementation of MOH. In terms of SIP protocol it is like a blind transfer, the caller has to reconnect to different UA. When you turn MOH off it works slightly differently, UA just suspends media by sending empty SDP message. When you take a call from hold, the UA will renegotiates codecs while not changing existing connection. All feature besides basic calls is a grayish area in SIP. Different vendors have some minor differences, while following RFC, which causing issues like this.

 

[IrwinMFletcher]

The second output looks wrong. When you put the far end on Hold, the renegotiate (ReOffer) should point the media to the controller, not the phone which it appears to be doing. Also, that should also be SendOnly (depending on viewpoint) but not SendRvc.

Can you get SIP wireshark traces out of the 3300?

 

[vlevalois]

Correct. It seems like the HOLD command is not sending the call to the 3300's IP address which in this case is 192.168.253.10.

Do you know of any of the Sip Peer settings that would change this behavior? Is this normal of any SIP trunk on the 3300. I'm curious to know if it's normal for SIP trunks to hold at the provider vs. the controller.

We've been asked to do a trace at the 3300 to see what there is, it's just a little time consuming and requires setup, port mirroring, etc. I'll see what we can do.

Thank you.

 

[fissure]

we have observed in the past, using SIP trunks from a SIP provider on a Mitel 3300, that it is the SIP provider's music on hold which is heard, and not any setup on the Mitel (which would match with the call holding at the provider vs. the controller?)

 

[IrwinMFletcher]

No, sorry, nothing comes to mind. It's guess work without the traces.

I'm guessing that the Reoffer was denied by the SIP SP. How that was handled (either by the SIP SP or the 3300) will cause the problems. Again, the traces will tell.

 

[vlevalois]

Thanks. I wonder if any of that can be changed within the Mitel, i.e. customize the way it treats the call when placed on hold from a SIP trunk. From all indications it's not behaving the way it should, still the provider says they have plenty of IP PBX's using SIP trunks that source their own MOH.

 

[IrwinMFletcher]

As I said, without the traces it's guess work. Most likely there is a setting/configuration.

 

[vlevalois]

OK, capture attached.

192.168.253.10 = Mitel 3300 with MCD 4.0 UR1
192.168.254.4 = Edgemarc 200A SIP Gateway/Router to Telcentris SIP trunk
192.168.253.115 = Mitel 5360 IP Phone
192.168.254(and 253).30 = Sonicwall TZ190

I established an outbound SIP trunk call to (818) 406-3001 then placed the call on hold at the phone (got no MOH) then retrieved from hold, then hung up.

Let me know what you think.

Thanks!

 

[vlevalois]

Sorry bad link, try this one.

 

[IrwinMFletcher]

I'm not a SIP expert, but here's my take. The call is established, that's fine, then when the 3300 side wants to go on hold, it sends out an empty Invite. This should trigger the far end to send out an Offer (sendreceive) to which the 3300 can indicate it's desire to switch to sendonly from the MOH source. Check with the SIP SP and see what they do when they get an empty Invite, and why.

"Force sending SDP in initial Invite message" might do something.

 

[vlevalois]

The SP saw the same thing on their end but I did not hear of them needing to trigger an Offer (sendrcv). I'll have to call them to get their take on the trace.

If I turn MOH off, the call is held at the SP with their music source. So somehow they are interpreting it as a hold, even though it's an empty Invite. The same can't be said when MOH is on.

Enabling "Force sending SDP in initial Invite message" doesn't change a thing btw.

 

[IrwinMFletcher]

Here, I found this. It's about the same problem, see what the SP makes of it.

http://old.nabble.com/SIP-SDP-"hold-and-resume"-td14798770.html

 

[vlevalois]

Great, thanks! I've shared it the the SP to see what they have to say.

 

[Mitelpassion]

can you run a trace but answer the incoming call on an analoge device?

are you using compression?

Looks like the SP is asking to use G729a as the codec. not sure if they are fexable after the call has been initiated.

so here's my thinking. if an IP phone takes the call, the call is G729a cause the phone does the compression. once you place the call on hold and I expect transfer to do the same, the codec switches to G711 because MOH is deemed a TDM device which requires DSP compression resources and licenses.

so using an analog phone to answer will put confirm my theory or rubbish it. it's worth a go.

OR, I could be way of on my assessed theory

 

[Mitelpassion]

also where was the trace captured from, the phone's port or the controller's port?

 

[vlevalois]

The trace was set at the 3300 port with a hub. I'll have to try establishing a call from an analog port and placing it on hold with the feature code to see what happens.

Also, we lose the call when embedded Express Messenger answers then tries to transfer the call. Sounds all related since it's trying to place it on hold while it transfers.

Odly, when we point the SIP trunk to the Nupoint in MAS, DTMF doesn't work, just weird but prob a SIP trunk to SIP station issue.

No compression is being used. According to the SP, they are using G.711 and the SIP trunk / IP Phones are all in the same zone, i.e. G.711. I'll have to double check with the SP that indeed they are @ G.711.

Wouldn't "Renegotiate SDP To Enforce Symmetric Codec" correct this issue anyway?

 

[IrwinMFletcher]

All calls are G711 according to the trace.

For the DTMF, do the same call that you are trying, but press some digits while in the call (on the SIP side) and see if they are in the stream with a trace. Keep in mind that you won't fail a call because of RFC4733 incompatibility. The SDP just states what you *want* to hear as digits, if the sender feels that it isn't important enough it won't send them. So make sure that they are sending them.

 

[vlevalois]

Attached is a capture of an inbound SIP trunk call to the MAS Nupoint and DTMF digits being sent from my cell phone with Verizon and nothing happening on the Nupoint AA.

RTP traffic is included on this one as well.

 

[vlevalois]

Here's a capture of an outbound SIP Trunk call to a cell phone, placed on hold and left to expire for a recall. The event of being recalled is much shorter than what's programmed in the 3300 (180 secs) which leads me to believe that the SP is sending its own expiration timer.