cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4757
Views
0
Helpful
5
Replies

CUCM <-> VCSC <-> VCSE Integration for URI Dialling

richard-marlow
Level 1
Level 1

I have recently upgraded our CUCM cluster to v9.1 and would like to integrate fully with our VCS (control and expressway) for SIP URI calls.

I have followed Cisco documentation and configured the following

  • SIP trunk from the CUCM to VCSC
  • Neighbour zone on the VCSC pointing at the CUCM Pub & Sub
  • Route pattern on CUCM for ‘*’ pointing to the VCS SIP trunk
  • Search rule on VCSC matching addresses assigned to CUCM users and pointing to the CUCM zone

The following calls work with no issues.

CUCM Registered Endpoint            ->            VCS Registered Endpoint

VCS Registered Endpoint               ->            CUCM Registered Endpoint

VCS Registered Endpoint               ->            External Endpoint

External Endpoint                          ->            VCS Registered Endpoint

External Endpoint                          ->            CUCM Registered Endpoint

However calls from CUCM registered devices to external destinations fail

CUCM Registered Endpoint            ->            External Endpoint

I can see logs on both the VCSC and VCSE which are as follows.

Feb 13 15:49:14 tvcs: Event="Call Rejected" Service="SIP" Src-ip="<VCSC IP>" Src-port="26439" Src-alias-type="SIP" Src-alias="sip:MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:auser@jabber.com:5060" Call-serial-number="d7c2d01e-75f4-11e2-9e2f-0010f31d1432" Tag="7d3f29f8-75f4-11e2-ace8-0010f321918c" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2013-02-13 15:49:14,706"

Feb 13 15:49:14 tvcs: Event="Search Completed" Service="SIP" Src-alias-type="SIP" Src-alias="MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:auser@jabber.com:5060" Call-serial-number="d7c2d01e-75f4-11e2-9e2f-0010f31d1432" Tag="7d3f29f8-75f4-11e2-ace8-0010f321918c" Detail="found:FALSE, searchtype:INVITE" Level="1" UTCTime="2013-02-13 15:49:14,706"

Feb 13 15:48:42 licensemanager: Level="INFO" Detail="License granted" local_call_id="d7c2d01e-75f4-11e2-9e2f-0010f31d1432" lic_type="traversal" UTCTime="2013-02-13 15:48:42,702"

Feb 13 15:48:42 tvcs: Event="Call Attempted" Service="SIP" Src-ip="<VCSC IP>" Src-port="26439" Src-alias-type="SIP" Src-alias="sip:MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:auser@jabber.com:5060" Call-serial-number="d7c2d01e-75f4-11e2-9e2f-0010f31d1432" Tag="7d3f29f8-75f4-11e2-ace8-0010f321918c" Protocol="TLS" Auth="NO" Level="1" UTCTime="2013-02-13 15:48:42,689"

Feb 13 15:48:42 tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:auser@jabber.com:5060" Call-serial-number="d7c2d01e-75f4-11e2-9e2f-0010f31d1432" Tag="7d3f29f8-75f4-11e2-ace8-0010f321918c" Detail="searchtype:INVITE" Level="1" UTCTime="2013-02-13 15:48:42,689"

Feb 13 15:44:22 licensemanager: Level="INFO" Detail="License freed" local_call_id="2963b2f4-75f4-11e2-b4ab-0010f31d1432" lic_type="traversal" UTCTime="2013-02-13 15:44:22,175"

Feb 13 15:44:22 tvcs: Event="Call Rejected" Service="SIP" Src-ip="<VCSC IP>" Src-port="26439" Src-alias-type="SIP" Src-alias="sip:MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:endpoint@cisco.com:5060" Call-serial-number="2963b2f4-75f4-11e2-b4ab-0010f31d1432" Tag="cedfc7d2-75f3-11e2-87b6-0010f321918c" Detail="Not Found" Protocol="TLS" Response-code="404" Level="1" UTCTime="2013-02-13 15:44:22,167"

Feb 13 15:44:22 tvcs: Event="Search Completed" Service="SIP" Src-alias-type="SIP" Src-alias="MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:endpoint@cisco.com:5060" Call-serial-number="2963b2f4-75f4-11e2-b4ab-0010f31d1432" Tag="cedfc7d2-75f3-11e2-87b6-0010f321918c" Detail="found:FALSE, searchtype:INVITE" Level="1" UTCTime="2013-02-13 15:44:22,166"

Feb 13 15:43:50 licensemanager: Level="INFO" Detail="License granted" local_call_id="2963b2f4-75f4-11e2-b4ab-0010f31d1432" lic_type="traversal" UTCTime="2013-02-13 15:43:50,170"

Feb 13 15:43:50 tvcs: Event="Call Attempted" Service="SIP" Src-ip="<VCSC IP>" Src-port="26439" Src-alias-type="SIP" Src-alias="sip:MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:endpoint@cisco.com:5060" Call-serial-number="2963b2f4-75f4-11e2-b4ab-0010f31d1432" Tag="cedfc7d2-75f3-11e2-87b6-0010f321918c" Protocol="TLS" Auth="NO" Level="1" UTCTime="2013-02-13 15:43:50,142"

Feb 13 15:43:50 tvcs: Event="Search Attempted" Service="SIP" Src-alias-type="SIP" Src-alias="MX200.cucm@mycompany.co.uk" Dst-alias-type="SIP" Dst-alias="sip:endpoint@cisco.com:5060" Call-serial-number="2963b2f4-75f4-11e2-b4ab-0010f31d1432" Tag="cedfc7d2-75f3-11e2-87b6-0010f321918c" Detail="searchtype:INVITE" Level="1" UTCTime="2013-02-13 15:43:50,142"

Feb 13 15:43:24 licensemanager: Level="INFO" Detail="License freed" local_call_id="06cae8c0-75f4-11e2-8199-0010f31d1432" lic_type="traversal" UTCTime="2013-02-13 15:43:24,123"

Does this mean that the DNS lookup has not worked correctly? The same addresses are reachable from VCSC registered endpoints.

Does the VCSE treat calls originating from CUCM differently?

If anyone can point me in the right direction then I would be grateful.

Many Thanks

1 Accepted Solution

Accepted Solutions

Richard,

that would explain the discrepancy, and adjusting the transform so that it changes alias@domain:5060 to alias@domain should resolve the issue, as it seems to have in your case already.

Since the route pattern on CUCM towards the VCS matches on "*", does it mean that whatever domain you dial, for instance 'alias@testdomain.com', that the call would be sent towards the VCS-C and arrive with destination alias 'alias@testdomain.com:5060'?

If that is the case, you should be able to create a generic transform which would strip off the ":5060" portion of the incoming destination alias, so that you can also call other organizations from UCM via VCS-C and VCS-E.

Hope this helps,

Andreas

View solution in original post

5 Replies 5

awinter2
Level 7
Level 7

For the failing call, the destination alias is 'auser@jabber.com:5060', and I suspect that the problem is related to the port number which is included in this destination alias. Normally the destination alias in this case would be 'auser@jabber.com' without the port number. The VCS-C rejects these call attempts with '404 Not Found', indicating that the call is not being sent out the traversal zone to VCS-E at all.

I'm assuming you have a transform in place on the VCS-C to transform the destination alias for calls coming from CUCM to the VCS-C, so why is this transform not removing the port number in the destination alias?

What was the original destination alias for this failing call as dialled on the UCM registered endpoint?

Could you show us the relevant transforms and search rules from your VCS-C?

Thanks for the pointer

I have added a transformation matching a suffix of :5060 and replacing it with nothing.

This seems to work and I am now able to make outbound calls from endpoints registered to CUCM.

Is this the recommended configuration? Could the uri format not be adjusted at the CUCM?

When I created the SIP trunk I used the SIP profile named "Standard SIP Profile for VCS" and naively thought this would work.

Is there an option within CUCM to remove the appended port number?

Thanks again.

Hi Richard,

if you have used the latest VCS <> UCM deployment guide (

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Cisco_Unified_Communications_Manager_Deployment_Guide_CUCM_8_9_and_X7-2.pdf), there is a section on page 23 called 'Set up a transform for CUCM to call the Cisco VCS Local and Neighbor Zones' which instructs you to create a transform which changes the IP address and port of the VCS to a domain.

This transform can for instance change firstname.lastname@10.0.10.2:5060 to firstname.lastname@cisco.com, where '10.0.10.2' is the IP address of the VCS and 'cisco.com' is the SIP domain in use in your environment.

You are however using UCM 9.1 which has some changes to URI dialling, could you let us know what format/syntax the destination alias has when it hits the VCS-C in your case? Is it alias@domain:5060, or alias@VCSIP:5060?

- Andreas

Thanks for the link Andreas

From a CUCM connected endpoint I am able to diala destination URI which is entered in the format

alias@domain. However it reaches the VCS as alias@domain:5060.

The endpoints I was using for testing were an EX90 and an MX200.

Thanks

Richard

Richard,

that would explain the discrepancy, and adjusting the transform so that it changes alias@domain:5060 to alias@domain should resolve the issue, as it seems to have in your case already.

Since the route pattern on CUCM towards the VCS matches on "*", does it mean that whatever domain you dial, for instance 'alias@testdomain.com', that the call would be sent towards the VCS-C and arrive with destination alias 'alias@testdomain.com:5060'?

If that is the case, you should be able to create a generic transform which would strip off the ":5060" portion of the incoming destination alias, so that you can also call other organizations from UCM via VCS-C and VCS-E.

Hope this helps,

Andreas

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: