Messages

1

MiVoice Office 250/Mitel 5000 / Re: Transfer to extension from SIP trunk fails

« on: October 21, 2016, 02:19:55 PM »

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.

2

MiVoice Office 250/Mitel 5000 / Re: Transfer to extension from SIP trunk fails

« on: October 21, 2016, 01:50:24 PM »

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.

3

MiVoice Office 250/Mitel 5000 / Transfer to extension from SIP trunk fails

« on: September 27, 2016, 02:38:47 PM »

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