Video endpoint registerd to VCSc calling CUCM

Unanswered Question
Dec 19th, 2013
User Badges:

I have an EX90 registered to a VCSc with a SIP trunk connected to CUCM. An extension on CUCM can call the endpoint registered to the VCSc, but when a video endpoint  tries to call an extension on the CUCM the call fails, but the video endpoint can dial 9+10 digitit numberaor 9+1+!0 digits. i have set up a specific search rule to match an exact extension number in CUCM to match but the call still fails. In the call history of the VCSc the result is 404 not found - I am using SIP.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Patrick Pettit Thu, 12/19/2013 - 17:57
User Badges:
  • Cisco Employee,

Hi. Im assuming CCM is returning the 404 Not Found in this instance? If it is , the SIP trunk may be in a different CSS than the phone your trying to reach perhaps? May need to be checked if possible. Sounds like a CSS issue maybe. Would you be able to check?

VR
P2


Sent from Cisco Technical Support Android App

Michael Martin Fri, 12/20/2013 - 04:40
User Badges:

Thats the first thing I tried, extensively. Below is a reply from a TAC case opened with the CUCM group of another customer that has the same issue.


The cucm engineer did some more research and testing, he reports that because of the way the Caller Id is coming in from the VCS  and the CUCM is a proxy for this call, there isn’t anything that can be done on the CUCM except for a normalization script, which are not TAC supported.  He reports that besides a normalization script, he would  recommend going back to VCS and seeing if the caller ID can be corrected there.


Are you able to check with VCS to see if they can fix it there?

Patrick Pettit Fri, 12/20/2013 - 04:43
User Badges:
  • Cisco Employee,

Hi Michael.  Sounds interesting as I'm not sure why it would fail due to the caller id being presented to CUCM. Can you slide me your TAC case number, and I can take a look at the logs to see what you have there.  You can Private message the case number would be great. 


VR

P2

Patrick Pettit Sat, 12/21/2013 - 07:03
User Badges:
  • Cisco Employee,

HI Michael.  Are you aslo using the CUBE in the same manner here also?  Reading the case it seems the call has to go out via PSTN and manages to go through a CUBE.  The CUBE is rejecting it because it has no valid caller id?  So I'm assuming that the PAI would need to be modified in this instance when the call is passed from VCS to CUCM. 


VCS can't manipulate that far down in the initial INVITE.  I'd have to check to see if a CPL would do this, but I'm doubting it, but will check around for you. 


if you have endpoints running TC6.3, you can ultimately try this to see if this will work for you. 


1) H323 protocol on endpoint - Remove the h323ID from the system. 

2) Verify E164 alias is programmed on the system and is registered to VCS.

3) Place call as H323 so that the interwork function (IWF) send call as SIP towards CUCM.  Since the h323ID is missing, IWF may pick up E164 alias in P-Asserted Identity (PAI) and send the call to CUCM. 


Now, you can test this...I can't guarantee it will work, but from reading the notes, they want something numeric versus alphanumeric and maybe if we place the E164 alias in the PAI it will help.  Can't guarantee it though...let us know..


Thanks.


VR

P2

Actions

This Discussion