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.
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?
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?
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.
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..
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...