Conductor Alias matching

[Mike Assel]

Hoping someone can clear up some confusion I have.  I have in my lab Conductor trunked to CUCM.  I have a route pattern in CUCM pointing to Conductor ,31XX and I have an alias configured in Conductor, (313.)@mydomain.us  .   Looking at the call history, when a call comes in from CUCM, say 3133, the destination URI in conductor shows as 3133@10.1.200.57.  10.1.200.57 is the rendezvous IP for conductor and therefore the target IP address of the SIP trunk in CUCM.  I'm not sure why CUCM is using the SIP trunk IP and not the domain in the destination URI, but what I'm most confused about is why Conductor is matching on that  URI at all, since it contains the IP address and not the domain name.  

The real reason I ask is because I have a customer that for some reason their Rendezvous calls are showing up as 404 not found in conductor.  Is there a setting somewhere in CUCM or Conductor that I may have overlooked?

Thanks,  Mike

[Nicholas Thompson]

1.  The endpoints need to be configured to "Use Fully Qualified Domain Name In SIP Requests" in order for the domain to match.  If that is not set on the SIP Profile, then CUCM will treat the numbers as dialed digits and then send the call with the ####@IP format.  This also means the Enterprise FQDN needs to be set so that if someone dials a number, the endpoint will append it with the @mydomain.us URI.

2.  In the Alias configuration, check the "Allow conference to be created" setting.  If set to "Yes" then the conference will be created on the fly if someone dials matches that actual string, regardless of being scheduled or not.  If set to "No", then even if it matches, the conference will not be created.

3.  You say in your lab it is matching on that string when it shouldn't be.  Can you clarify or show this?  You are right in that it shouldn't be matching it at all.  Do you have any other aliases it might be matching instead?

[Mike Assel · Accepted solution]

Thanks for the reply Nicholas.  I had all those items configured correctly.  The issue turned out to be the SIP domain on the conductor.  For some reason, this Conductor had no SIP domain configured.  This is the typical warning that you will see in the log when a call is received with no matching alias:

conferencefactory.controller: Level="WARNING" Event="A CPL 'reject' has been returned to a client. Reasons could include: no matching alias, no conference template, or no dial plan prefix configured." Destination-alias="9235@10.10.10.10" Request_unique_identifier="9ac13f0f-24dc-11e5-8fb6-692ae99d748e" Requester_(VCS/Unified_CM/client)_address="10.10.10.10." Source_protocol="SIP" Unauthenticated_source_aliases="[8604419235@gdeb.com]" UTCTime="2015-07-07 19:16:01,247"

Now, when a SIP domain is configured on Conductor, it will use the SIP Domain API to transform any alias destined for @ip-of-conductor to @sip-domain-of-conductor (page 199 http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/conductor/admin_guide/TelePresence-Conductor-Admin-Guide-XC3-0.pdf).  So, if the SIP domain of Conductor is darmckin.local and one of its IP addresses is 10.10.10.10, and I have a conference alias configured as \d{4}@darmckin.local, when Conductor receives a call destined for 9235@10.10.10.10 the call will match that alias and you will see this in the log: 

conferencefactory.controller: Level="INFO" Event="An incoming call match string has been modified to include the SIP domain supplied by the API instead of the local domain." New_match_string="9235@darmckin.local" Original_match_string="9235@10.10.10.10" UTCTime="2015-07-07 19:24:23,531"

Once I saw these lines in the log I realized what the issue was, but I wasn't sure how to fix it.  To make things more confusing, in other Conductor installs I've done I never configured a SIP domain (that I can recall) and the Conductor/CUCM deployment guide doesn't mention anything about it.  To see what the SIP domain is on Conductor you have to use this CLI command:

xconfig SIP Domain 1 Domain: “darmckin.local”

In my case, the domain was empty.  To set the SIP domain, use this command:

xCommand DomainAdd Domain: darmckin.local

 I worked with TAC on this and as a result this bug was filed: https://tools.cisco.com/bugsearch/bug/CSCuv22029

Cheers, Mike

[Nicholas Thompson]

Wow.  Interesting.  I have done many deployments and have never hit that.  Quite the find.  Thanks for the update!