cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
789
Views
0
Helpful
1
Replies

Call Transfer from SIP ITSP to Unity Connection Intermittent

Helmi Muzammil
Level 1
Level 1

Hello,

 
We have Unified CM 9.1 integrated with Unity Connection 9.1 using SCCP. The issue is that when receive a call from outside through a SIP, CUC AA is invoked and after entering an internal extension it tried to connect to it but call intermittently success and fails.On the fail called ip phone extension I can see that call was attempting to ring and disconnect immediately.

The call flow is as follow:

 
SIP ITSP-->CUBE-->Unified CM CTI RP-->CUC --> CUCM-->IP Phone

 

On unity connection I have added codec g711alaw on advertised codec as it is used mainly from ISP, Also I have added "allow transfer to external number" check box under greeting for CUC.All call search space are correctly configured and have access to CUC and IP Phones.Also, early offered is enforced on the CUBE and using SIP trunk between CUCM and CUBE with sip profile Best Effort .

 
I have attached a debug ccsip message contain 2 calls  and it shows :

18:49:18 - 18:49:35 : The call was successfull

18:49:40 - 18:49:50 : The call was fail and I'm receiving isdn cause code 47 which means resources are not available or the original destination is unavailable and to invoke redirection to a new destination.

Appreciate your help.

1 Reply 1

Jonathan Unger
Level 7
Level 7

Hi There,

Would you be able to attach a CUCM trace for the failed call?

I suspect in this case that this will have something to do with media resource allocation.

The only major difference I can spot in the SIP trace for the 2 calls is with the media address being allocated (found in the final 200 OK messages from CUCM to the CUBE). CUCM is telling the CUBE to send the media to the following addresses for each call:

Working call media address = 159.163.127.235 (not sure what this device is)

Failed call media address = 159.163.127.233 (this is most likely an MTP or Transcoder which is configured on the CUBE).

-----------------------------------------

One other thing to note is that you have a little bit of sub-optimal call routing going on.
When the call first hits your CUBE from the ITSP, the CUBE is attempting to send the call to CUCM, it is doing so via its interface with the IP 10.92.50.7, which call manager is rejecting. This IP is most likely does not exist in the CUCM SIP trunk configuration for this CUBE.

CUBE then has to issue a new invite to CUCM again from the interface 159.163.127.233 which is then accepted by CUCM.



You may want to consider modifying your dial-peer configuration so that CUBE does not need to send 2 INVITE messages to CUCM for every incoming call (with the first one being rejected every time).

I had to do some guessing based on the limited information provided, but am I correct in thinking that you have at least 3 IP addresses on this CUBE?