Transfer to extension from SIP trunk fails

[bsm73]

Equipment: Mitel 5000 (software version unknown at this time.)

Scenario:
Internal extension (A) calls another internal extension (B) that points to a SIP trunk.
Call is answered by application on SIP trunk.  Call is established and audio works fine.
During the call, the caller is transferred to another internal extension (C) via SIP in-call REFER method.

Problem:
The caller hears ringing, however the phone at the destination (C) does not ring.

Analysis:
Reviewing SIP trace of application on SIP trunk, the REFER is 202 Accepted and then a NOTIFY is received with body SIP/2.0 200 OK.  After the NOTIFY, the application sends BYE to end the call (PBX should now have it as a blind transfer).

Testing:
Mimiced this call flow using three desk phones (i.e. removing the sip trunk from the scenario) by using one extension (A) to call another extension (Y) which then transfers the call to the destination extension (C) and it rings for both the caller and the destination phone.  So it must be related to the SIP trunk somehow.

Not sure what the problem might be.

Thank you for suggestions on what to look at.
- Brian

[pexecutone]

Does phone C have a Mailbox? If it doesn't have a Mailbox does it have an Extension ID? The phone should have one or the other. There is bug in one of the 6.0 versions that when Phone A called Phone B and Phone B grabbed a SIP Trunk and call out .The caller would not hear ring back. The call would ring the still ring the intended cell phone.

[Tech Electronics]

Bsm73,

Are you the Mitel vendor or the customer?

Did you look at the SIP logs from the phone system?

Which phone is doing the transfer A or the application on the other end of the SIP trunk that isn't an application of the Mitel 5000? How is this transfer really performed?

Thanks,

TE

[bsm73]

Does phone C have a Mailbox? If it doesn't have a Mailbox does it have an Extension ID? The phone should have one or the other. There is bug in one of the 6.0 versions that when Phone A called Phone B and Phone B grabbed a SIP Trunk and call out .The caller would not hear ring back. The call would ring the still ring the intended cell phone.

Apologies for my tardiness in replying.
Phone C has a mailbox associated with it.
This is a different scenario based on your description of the bug.
See my next reply for more detail.

[bsm73]

Bsm73,

Are you the Mitel vendor or the customer?

Did you look at the SIP logs from the phone system?

Which phone is doing the transfer A or the application on the other end of the SIP trunk that isn't an application of the Mitel 5000? How is this transfer really performed?

Thanks,

TE

Again, sorry for taking so long to reply.

I am neither the Mitel vendor or the customer.  I am the application provider on the other end of the SIP trunk.
Our application has been successfully interop tested with the Mitel MCD series as "Compatible".
But we do not have experience with the 5000 series.

This is what the setup looked like:

Code: [Select]

[Application B] <----------- SIP trunk ---------> [Mitel 5000] <----------- Phone A
                                                            ^
                                                             \-------------- Phone C
It is the application (mine) at the end of the SIP trunk that is using an in-dialog SIP REFER to attempt to transfer an active call between phone A and my application to phone C  on another phone extension.

The Mitel vendor asked Mitel support for help and sent along SIP traces.  They were told by Mitel engineering that the 5000 cannot perform REFER transfers on a SIP trunk.   So, even though the 5000 is '202 Accepting' the REFER request from the application and then sending a NOTIFY with '200 OK' in the body, the switch cannot actually perform the transfer.  Basically, the 5000 is not following SIP RFC specifications and I was tricked into believing it was a simple configuration/setup/Class of Service kind of issue.

Mitel engineering told the Mitel vendor to have the application use SIP INVITEs to make calls on the SIP trunk.
While our application can do this, it would keep two ports up for the entire call duration.  Unfortunately, our application does not support re-invite transfers to drop out of the call.  This renders this option not cost effective due to the increased number of application ports that would be required.

So, we worked with the Mitel vendor to switch from the SIP trunk to using registered SIP endpoints so our application basically mimics multiple soft-phone endpoints.  But, because the 5000 cannot support multiple calls on the same extension, multiple registrations are required.   This solution is working, meaning that REFER transfers are working as expected for both internal extensions and external phone numbers (this is required by the customer).   There is more testing to be done related to creating hunt groups so multiple calls to different applications can be supported for the customer but I think it may work well enough.

[Tech Electronics]

bsm73,

I think that I understand what you are doing and I can't think of any secure system allowing a 3rd party connection [FXO] control over routing within the system itself. I can see allowing an FXS as that is a valid entity within the system; even though is can still be insecure.

With FXS a transfer is initiated within the system and the 5000 will allow an entity within the system to perform such an action. With FXO a request to transfer is considered to be coming from outside the system, if that makes sense, and therefore not a trusted entity.

As for allowing multiple calls on FXS that is allowed so I don't know what exactly the scenario is that it wouldn't allow that other than the limit is beyond 2. Now for FXO the amount of calls is based on the amount of trunks to a SIP Peer Trunk Group, but since an FXO is a single entity is can only handle a single call. The Trunk Group itself though can handle as many calls as there are trunks, but a Trunk Group is not allow to initiate a transfer as it can only route calls to destinations.

It sounds as though you have the problem figured out, but just for further reference the Mitel 3300 and the Mitel 5000 are two completely different phone systems that were made by two completely different manufacturers and therefore they do not and will not operate the same even when doing similar functions; apples and oranges.

Thanks,

TE