Forwarding since a unity connection doesn't work

[Adrian Montoya Ruiz]

Hi, i have the next issue.
I have a CUCM version 10.0.1 integrate with a CUCA version 10.0.1, in that unity I have the auto attendant configured with a menu with 3 options: 0 goes to the recepcionist, 4 goes to the extension 1690 and 5 goes to the extension 1692. The problem is when I tried to made a forwarding, especially for busy or no answer option, the forwarding woks and the call is redirect to the other number and the number ringing but when the call is answered the call drop. If I made an internal call or a direct call for any one of that extension the forwarding works correctly and the calls never drop.

[Slavik Bialik]

Something almost similar happen to me, but not 100%. Try do the following:

1. Login to Unity Connection.
2. Navigate to Telephony Integrations -> Port Group
3. Select your port group
4. Go to: Edit -> Advanced Settings
5. Uncheck "Use DTMF KPML".

Actually, after the scenario that I had, everytime that I'm installing new Unity I'm unchecking this option.

It was a long time ago, and I can't remember exactly what happend, but after investigating CUCM logs I found out that when it tried to use KPML for the selections in the IVR, the call was disconnected after being answered. The CUCM always tried to use MRG for some transcoding for some reason, so unchecking the KPML option lead to use of the standard RFC 2833, which I totally prefer (but not Unity unfortunately, heh).

[Adrian Montoya Ruiz]

Hi and thanks for the reply.

I deactivate the DTMF KPLM option in my port group but I still have the same trouble. And i made a wireshark capture with a IP communicator but I just see a complete call. What other options could I use to see what happen with the call?

[Slavik Bialik]

In the wireshark capture who originated the BYE message? the CUCM?
I think you need to gather the SDL logs from the CUCM and see if there's something wrong there. You can attach us the logs and we can give it a look, but if you do please also give us some information like who dialed (ext.), where the call is transferred after the IVR in Unity and etc.

BTW, just for testing... (do this step by step)
1. Do you have a MRGL profile associated in your SIP trunk towards Unity? If not, please add it. And reset the SIP trunk.
2. Are you using early media from CUCM to Unity? If so, try to disable it. (This setting is in the SIP Profile, in a field named "Early Offer support for voice and video calls") And of course reset the SIP trunk.
3. Try enabling MTP on the SIP Trunk, and reset the SIP trunk.

I'm guessing that enabling the MTP on the SIP trunk probably will help, but for me this is just a workaround, and I do it only for tests to understand more where the issue occurs, as enabling the MTP is now using your CUCM resources expensively and I do not recommend it.

[Adrian Montoya Ruiz]

Hi and thanks again,

I been watch in the configuration of the Unity and the CUCM and I don't have any Sip trunk between CUCM and the unity.

So about the first question: I just see the CTI Route Points and don't have any MRGL,so I put in one but the forwarding still not working, and in the unity I see 3 port group (2 are Skinny  and 1 SIP) and one of the skinny are the Default TRAP Phone System.

For the second question: NO the standard sip profile don't have enable the "Early Offer support for voice and video calls"

For the third question: If I don't have a SIP trunk between the CUCM and Unity is necesary enable the a MTP?

Sorry for the confusing info, but I just started to manage this CUCM and I this is the example of the connection:
Unity Connection------Callmanager---(SIP trunk)-----CUBE--------Provider(SIP trunK)

And I got these logs using the RTMT I hope will be useful.

https://www.dropbox.com/s/l1ae5bivd7zt7x3/Logs.zip?dl=0