ITSP-CUBE-CUCM-UCCX

[Ermir Morina]

Greetings, 

So i have an odd issue with incoming calls from outside to our cube-cucm-uccx, the setup worked just fine until some days ago and now it just stopped working, I have a secure sip trunk between cube and cucm, when i try calling from outside the "post office" replies with Call cannot be completed (in my native language lol).

I suspect that there is a problem between CUCM & UCCX, because the CUBE-CUCM SIP seems fine (or maybe that is just my thought), so I'd love to hear from you and ask for your help.

Thank you very much in advance.

[Shalid Kurunnan Chalil]

To start with, you may check below;

• Does the CUBE Trunk CSS has the access to the CTI Route points DN's ?
• Any changes in the codec?  check the codecs in the incoming call leg of ITSP/CCM/CCX?
• Can you debug the CCX script and see whether the call is hitting on the script
• check the CUBE logs what error message send by CCM/CCX?

Regards,

If this answered your question, please click "Accept as solution"
If you find this response useful, please mark it as "Helpful"

[Ermir Morina]

Thank you for your response!

So about the questions and tips:

1. Yes i checked them and it has access to all of them.

2. No unfortunately I was hoping that was the case initially, but no all of them seem to be as they should.

3. Any commands or tips on how I should execute this process?

4. Checked them and the message I get when the call gets disconnected is this :

''//79698/5355D809BBEA/CCAPI/ccCallDisconnect:
Cause Value=47, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=47)''  (So this is the message i get on debug voip ccapi inout, the call is accepted by CUBE, translated into the UCCX DN (CTI Route Point DN), but i get no logs from the CUCM, even after collecting the logs i see nothing on the CUCM... which is strange to me.

Any other ideas, thoughts, hints/tips would be greatly appreciated by my side, thank you a lot for your time and effort!

[Shalid Kurunnan Chalil]

Hi, 

Cause code 47 typically means an issue with media negotiation

• Do you have the MTP checked on the trunk?
• Please collect and check the  debug ccsip messages from the CUBE to see whether the CUBE is sending the disconnect response or CUBE getting from the call manager (attach the sip logs in the txt file to the case otherwise) 

for reactive debugging for the script (Ideally to debug the script and helps to Correct any errors flagged). here if you manage to get the CUBE SIP logs, you may not require this. but still for confidence you can check whether the call is hitting on the CCX or not. 

1. From the Cisco Unified CCX Editor menu bar, choose Debug > Reactive Script.
   1. The Reactive Debugging Script dialog box appears.
2. IIn the Script File Name text field, enter the file name of the script you want to debug or use the drop-down menu to choose the desired script.
3. In the Wait Time (Secs) text field, enter the amount of time you want the Cisco Unified CCX Engine to wait for the result of a triggering event 

4. Click OK.

5. Make a test call and Choose Debug > Continue to allow the system to continue debugging, or Debug > Step Over to debug one step at a time

Regards,

If this answered your question, please click "Accept as solution"
If you find this response useful, please mark it as "Helpful"

[Ermir Morina]

Greetings, 

So I was checking the CCsip messages on the CUBE and you can see on the logs i attached.

So as I can see the CUBE just keeps trying its dial peers but it just doesn't send the incoming call towards CUCM ( we have a secure sip trunk from CUBE to CUCM ).

If you can take a look at the logs and maybe we can discuss further about the potential source of problem.

Thank you very much for your time and effort, I appreciate it! 

[Ermir Morina]

Here are the logs 

[Shalid Kurunnan Chalil]

Hi 

As per the given logs, I cant see the invite sending to the call manager device. 

Its looks like the number 23290320 are being translated to 003813820077803 and sending back to the ITSP. 

Invite received from ITSP:
Feb 25 07:39:12.530: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:23290320@CUBE-out-IP :5060;user=phone SIP/2.0
Via: SIP/2.0/UDP ITSP IP:5060;branch=z9hG4bKqftamm1068v1hvcm00r0.1
From: "My-MobileNumber" <sip:My-MobileNumber@ITSP IP:5060;user=phone;cpc=ordinary>;tag=pl4t0qj8sa
To: "23290320" <sip:23290320@CUBE-out-IP :5060;user=phone>
Contact: "My-MobileNumber" <sip:My-MobileNumber@ITSP IP:5060;user=phone;transport=udp>

I expected to see another invite to call the manager, Is it your call manager IP that your changes as ITSP???

Feb 25 07:39:12.546: //10104/635D4CFFAAEC/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:003813820077803@ITSP IP:5060 SIP/2.0
Via: SIP/2.0/UDP CUBE-out-IP :5060;branch=z9hG4bKD5825
Remote-Party-ID: "My-MobileNumber" <sip:9My-MobileNumber@CUBE-out-IP >;party=calling;screen=no;privacy=off
From: "My-MobileNumber" <sip:9My-MobileNumber@CUBE-out-IP >;tag=111A57B4-1913
To: <sip:003813820077803@ITSP IP>
Contact: <sip:9My-MobileNumber@CUBE-out-IP :5060>

This device (ITSP) is sending 503 unavailable. 

Feb 25 07:39:12.558: //10104/635D4CFFAAEC/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP CUBE-out-IP :5060;branch=z9hG4bKD5825
From: "My-MobileNumber" <sip:9My-MobileNumber@CUBE-out-IP >;tag=111A57B4-1913
To: <sip:003813820077803@ ITSP IP>;tag=ouhb-pfa3g6o3s1
Call-ID: 635FBD9F-767311EB-AAF4D837-9CDC85AC@CUBE-out-IP
CSeq: 101 INVITE

Please correct me if i am wrong in the call flow

ITSP--> CUBE-->CUCM

in this case, there seems to be an issue in the configuration.

Possible cause: 

1. check your configuration again and see if you have relevant dial peer to the call manager matching 23290320

2. confirm that My-MobileNumber" <sip:My-MobileNumber@ITSP IP:5060;user=phone;cpc=ordinary and INVITE sip:003813820077803@ITSP IP:5060 SIP/2.0 same or different devices. 

Please let me know if you can share the CUBE configuration with the thread to look further. 

Regards

[Ermir Morina]

hi! 

So the call flow should be ITSP->CUBE->CUCM->UCCX (CTI RP 77803).

1.I will send the CUBE config that consists of the required configs.
2.Yes that is the same device/IP.

Thank you!

[Shalid Kurunnan Chalil]

Thanks for the file. 

As per my understanding, It looks like the CUBE routing the call back to the ITPS using your dial-peer "6" .

1. Call received to CUBE - dial-peer in use dial-peer voice 1 VOIP. 
2. The number translated in to 77803 (translation-profile incoming INBOUND_CALLS) --> 23290320 --> 77803
3. CUBE then matched the dial-peer 6 and translated the 77803 to 0038138200 and sends to ITSP. 

Could you please try the below dial-peer and make a test call?

dial-peer voice 1 voip

 description === INBOUND CALLS FROM A1 ISTP (removed your TP from here) ===

  max-conn 2

 session protocol sipv2

 incoming called-number 23290320

 voice-class sip options-keepalive up-interval 10 down-interval 5 retry 1

 voice-class sip bind control source-interface GigabitEthernet0/0

 voice-class sip bind media source-interface GigabitEthernet0/0

 dtmf-relay rtp-nte

 codec g711ulaw

 no vad

!

dial-peer voice 2 voip

 description ==INBOUND CALL 77803 Call Center extension to Subscribe ( added your r==

translation-profile outgoing INBOUND_CALLS

preference 1

 destination-pattern 23290320

 session protocol sipv2

 session target ipv4: 10.155.2.200 (CUCM SUB IP)

 session transport tcp tls

 voice-class sip bind control source-interface GigabitEthernet1/0

 voice-class sip bind media source-interface GigabitEthernet1/0

 dtmf-relay rtp-nte

 srtp

 codec g711ulaw

 no vad

Please try this and let me know how it goes. If you are still facing the issue Please take the debug output of

debug voip dialpeer detail

debug ccsip messages 

Regards, 

Shalid