Mitel call transfer

[m1ck0]

Banging my head against a wall. Can anyone assist with call-transfer problems on Mitel 3300 ICP. Our client has built 2 SIP trunks from their Mitel 1/ to our Cisco ip-ip gateway and 2/ to our Nextone MSX SBC.
Initial setup call flows from 1/ SBC -> Cisco -> Mitel and 2/ SBC -> Mitel are good. Once Call is transfered off Mitel IVR we run into issues.
For calls 1/ thru cisco the transfered call stays up for 15secs before the cisco sends a BYE in both directions reporting 127.
For calls 2/ with out the cisco there is about 5secs of one-way speach (Mitel -> Nextone).
Been working on this for weeks with all sorts of gurus. Seems like the call is being transfered by the Mitel but in a way that neither the Cisco or the Nextone SBC understand. Any ideas would be greatly appreciated.

 

[mitelgear]

What release of software is the mitel 3300 on ?

 

[m1ck0]

mitelgear, I do not know. They recently upgraded so my guess would be a recent release. We have been trying to find a wrong process within the devices under our control and cannot see a wrong setting or behaviour.

I guess it would help to understand the Mitel sip process when a transfer happens. That way we may be able to compensate.

 

[slapin]

Take a look at this nice picture first.Make sure that all elements of the call flow support RFC3891.

Besides that it would be helpful to see SIP traffic captured in the network.

http://www.sip-communicator.org/index.php/Development/CallTransfer

RFC3261 - SIP Session Initiation Protocol

The 3300 ICP operates as a Back-to-Back User Agent.

It supports UDP, TCP, TLS transports.

Both SIP-URIs and TEL-URIs are accepted on incoming calls although only SIP-URI’s are used for outbound calls.

The Options method used for link management.

The configuration allows for Outbound Proxy Servers.

Sending REGISTER messages is supported but incoming requests for registration are not.

RFC3262 - Reliability of Provisional Responses in Session Initiation Protocol

RFC4566 - Session Description Protocol

Supports G.711 A-law, µ-law, G.729a.

RFC3264 - An Offer/Answer model with SIP

RFC2976 - SIP INFO Method

RFC3311 - SIP UPDATE Method

RFC2833 - RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

RFC3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

Configuration allows for sending of P-Asserted-Identity and use of the Privacy header when privacy is requested.

RFC2617 - HTTP Authentication draft

RFC1321 - The MD5 Message-Digest Algorithm

RFC3263 - Session Initiation Protocol (SIP): Locating SIP Servers

Does not interpret "regexp" provisioned in NAPTR RR.

RFC2782 - A DNS RR for specifying the location of services (DNS SRV)

All Srv RR received are ordered jointly by priority and weight. For simplicity, the current implementation does not support server load balance information conveyed through the change of weight in SRV RR.

RFC4028 - Session Timers in the Session Initiation Protocol

Partial support, Session Timer is configurable.

RFC3515 - The Session Initiation Protocol (SIP) Refer Method

REFER may be received by the 3300 but will not be generated

RFC3891 - The Session Initiation Protocol (SIP) "Replaces" Header

RFC3892 - The Session Initiation Protocol (SIP) Referred-By Mechanism

RFC3265 - SIP-Specific Event Notification

SUBSCRIBE message not supported.

Note: Within the 3300 ICP system, the characters #, *, @, and + have a special use. If these characters are used in a telephone name or number, they might not appear as expected when sent across a SIP Trunk.

 

[m1ck0]

Firstly, thanks slapin for the info. I have done numerous call debugs on the Cisco ipipgw and ethereal traces to/from the Nextone SBC. What I can see is that after the dtmf is sent to the Mitel, the transfer follows the "replaces" method. This is where it all goes bad, there are many re-invites and 488s.
I put in a ticket with Cisco TAC to see if they could advise a solution. The answer is that Cisco IPIPGW does not currently support re-invite. It is on the roadmap but won't work at the moment.
They suggest:
a/ using the SIP refer method instead, but looking at your list the 3300 will not generate this.
b/ having the mitel hairpin the call.

 

[slapin]

Looks like B method is the only option, in fact it's not so bad in LAN environment.

Could you drom me a message with your traces to tvman_us at yahoo.com. I would try to simulate it on different Cisco platforms in our lab since it's interesting subject for me.