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

 

[IrwinMFletcher]

There was no streaming in the Nupoint trace.

 

[IrwinMFletcher]

In the Nupoint trace however, the second Invite from 192.168.254.4 (the SIP gateway) doesn't include telephone events. The original offer does. As I mentioned, they probably figure that the dialing is complete and don't want to waste resources on DTMF detectors on their side. Not a good idea. In SIP you always need them because you never know what is on the far end (e.g this could be in turn TDM trunked to the PSTN and dialing into an automated bank teller).

 

[vlevalois]

By contrast, sending the DID to the Embedded Express Messenger works fine with DTMF, although the xfer doesn't complete due to the hold issue...

 

[IrwinMFletcher]

I'm not sure what you mean by that, do you mean you can navigate EMEM prompts using DTMF from the cell phone?

 

[vlevalois]

Correct. DTMF works in the EMEM, not in the MAS Nupoint.

 

[IrwinMFletcher]

EMEM works since it has TDM DTMF tone detectors in place. It's detecting the in-band tones.

 

[vlevalois]

So the HOLD issue is still an ongoing problem and we've found so far is that the provider does not support empty invites, which the 3300 is sending when a call is placed on hold. See trace below:


<<<<<<<<<<<<<<<sip header stop<<<<<<<<<<<<<<<<<<<<

21:15:52.183046 192.168.253.10.5060 > 192.168.254.4.5060:
>>>>>>>>>>>>>>>sip header start>>>>>>>>>>>>>>>>>>>
INVITE sip:192.168.254.4:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.253.10:5060;branch=z9hG4bK2974000944-91302802
Route: <sip:18184921630@192.168.254.4;lr>
Max-Forwards: 26
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REFER,REGISTER,UPDATE
Alert-Info:<

http://www.notused.com>;info=alert-internal

Supported: timer,replaces,100rel
From: "V.Levalois" <sip:18184921630@192.168.253.10>;tag=0_2965360944-91302797
To: <sip:18187346066@192.168.254.4>;tag=899f912ead2ac529de4687c15c202c07
Call-ID: 2965360944-91302795@192.168.253.10
CSeq: 4 INVITE
Contact: "V.Levalois" <sip:18184921630@192.168.253.10:5060;transport=udp>
Content-Length: 0

Why would this be? I've also tried setting Suppress Use of SDP Inactive Media Streams but no change.

Any more direction would be appreciated.

Vince

 

[T8keiteasy]

Hi everyone, I have the same problem with a sip gsm gateway.
Has a ticket been raised at mitel support ?
Regards

Now, it's about French users too !!!

 

[T8keiteasy]

I have raised a ticket regarding this problem.

Now, it's about French users too !!!

 

[vlevalois]

It would appear that this issue may be resolved with MCD 4.1. According to the latest SIP Trunk interop instructions for Paetec Communications (SIP CoE 08-4940-00035):


Music on Hold and
Ringback on Transfer

Playing Music on Hold and Ring Back tone during transfer from the Mitel 3300 ICP to PSTN user will not work due the fact that BroadWorks does not support (SendOnly) flag in the SDP. The ringback on the transfer scenario is provided by the 3300 in an audio stream. Since the PSTN user still thinks the call is on hold, Broadsoft interrupts the RTP stream and doesn't allow the ringback to be heard by the PSTN side.

Recommendation: Contact Mitel Product with regards to DCR
MN314000. This DCR adds a new option in the SIP Peer profile
to not signal the far end peer that the call is placed on hold. This will allow the 3300 to stream both MOH and ringback tones during a transfer. Scheduled for MCD Release 4.1.

---

If this is correct then it would solve the MOH problem and truly treat the SIP Trunk as any other trunk, hence, have more control over it locally.

 

[M1tel]

I have completed many installs with SIP these are the only settings to turn to yes in SIP

Use P-Asserted Indentity Header

Disable Reliable provisional responses

force sending SDP in initial Invite message

prevent the use of ip address 0.0.0.0 in SDP messages

allow peer to use multiple active m-lines


Set all else to no

 

[vlevalois]

I've tested this specific SIP Peer Profile configuration and there's no change in the behavior when a SIP trunk is placed on hold with MOH on in the 3300.

The caller does not heard MOH and the extension cannot retrieve the call after placing it on hold, both ends disconnect after a few seconds.

Furthermore, DTMF digits are not recognized by the NuPoint when a call is established from the SIP Trunk.

 

[M1tel]

In class of service is the music on hold source local set to yes

 

[vlevalois]

The only MOH related COS setting is Music on Hold on Transfer, which is set to No.

In the "Misc Assignment" form Music Source is set to External and appropriate Music Source Port - Location ID is set. MOH works fine with PRI trunks.

 

[M1tel]

Class of service option on trunks and sets local music source must be set to yes

 

[vlevalois]

Sorry, yes, Local MOH source is set to yes on both the COS for the station and for the SIP trunk, no change.

 

[DutchMark]

Hi this problem is solved in MCd4.1 SP1 "avoid signaling hold to the peer"
My SIP providers also didn't supported MOH, after changing to option to Yes i had local moh.

 

[vlevalois]

True, to a certain extent. There's some configuration on the peer's part depending on how they treated requests from the 3300 when a call was placed on hold.

The one we are working with for example, had to modify their response in order to make it work. In addition, we're still having issues using the MBG as the proxy instead of using their router, which I know is ideal, but in some instances not possible due to single static IPs with some internet connections.

We're close though. Bandwidth.com is good on outbound with MBG but not on inbound. Getting a 403 Forbidden from the MBG and not sure why...

 

[vlevalois]

So now nearly 6 months later, we have these Telcentris SIP Trunks working through the MBG with HOLD, etc.!

This was all related to the way the carrier's softswitch handled SDP messages from the Mitel.

We ended up using the same setup as Bandwidth.com where we're authenticating with the public IP address of the MBG, so no registration on the trunks.

Cheers!