Showing results for 
Search instead for 
Did you mean: 

MRA configuration with different domain name

Hi ,

We are configuring MRA with different internal and external domain name. internal domain is abc.local and external domain is

Exp C ,CUCM and IMP are in abc.local domain and Exp E is in domain. users using user@abc.local to login to jabber .

So we created external  SRV records . (  . in internal DNS server we created 

From what I know , we need to create record in internal DNS as well .


The problem is since we cant add zone (it will affect the existing ERP setup ) we cannot create in our DNS server . 

Is there any workaround for this ?


Aneesh Abraham



Hi Ayodeji,


Will this configuration work with 2 different domain? Like the example above, abc.local for internal and for external.




I know that this is an old post but running into similar situation.

Aneesh, just like you said -

internal = abc.local

external =

not allowed to publish (create zone) of one into another side

The problem is you have to use from outside for collab-edge discovery. Expressway-C will use to look for internal services on behalf of the client.

Tested creating Pinpoint Subdomain and Jabber uses that for discovery but was not sure if it is still supported by TAC even though all the planning guides talk about pinpoint subdomain.

Did you find answer/solution for this?



You can try creating the records just for Jabber as shown below:

dnscmd . /zoneadd /dsprimary

dnscmd . /recordadd @ SRV 10 0 8443

dnscmd . /recordadd @ SRV 20 0 8443

Hopefully you are able to sign certs from an external CA for domain.local.

Please rate useful posts.

Thanks George,

The issue is that the business does not allow to create a zone for the outside domain internally - If the domains are:

internal = abc.local

external =

Cannot create zone internally. The alternative is to create a sub-domain zone, for example "" zone. This way the internal would be authoritative for the sub-domain and the external would stay authoritative for the main domain and there would no disruption on the production systems that are on the main domain The SRV would be

It seems to work on a lab but not sure if it was acceptable solution. Any ideas?



You are correct. Jabber will use the UDS domain as the discovery domain. All you need to do as you have done is to host internally and then point the cisco-uds SRV to Once Jabber gets the response for cisco-uds srv query, it will then use the as the service discovery domain

Please rate all useful posts

Thanks Ayodeji,

That is exactly how we tested it; we were not sure if it was supported by TAC. It seems as though it is ok as long servicedomain is used in the jabber-config.xml.

Thanks for all the help,


This is supported by TAC, I have done this for two customers now and supporting another one with the same setup

Don't forget to rate helpful post

Please rate all useful posts

Thanks Ayodeji. Your posts in this discussion and another one have been of great help in understanding this situation.

I have a question - Why can't we have collab-edge SRV on while the uds is on

We should be able to do this using the VoiceServiceDomain configuration key, that will point to while the services domain can remain as (as mentioned in , although I find inconsistencies in the example give here)

I may have understood it wrong, but this is how it should work:-

MRA clients:-

Login using and do not get uds SRV in, but are able to find  collab-edge SRV that points to

Internal clients:-

Query uds/collab-edge SRV in and do not get a response, but due to voiceservicesdomain configured as query for uds again in domain. uds SRV record exists on the internal name server for domain pointing to

Please help me understand if this is wrong.




You are correct and this is the old way of doing the deployment.

However in newer versions of jabber you dont need servicesdomain. This is because Jabber will extract the uds domain found in the UDS discovery and ue it  the discovery domain. 

Please rate all useful posts

Thanks Ayodeji.

So in newer deployments, having UDS and collab-edge SRV records in the same domain is a necessity then.

That would mean that even though internal name server can't be authoritative for the, we would need to create a subdomain - say on both external and internal and then create the respective SRVs?

I see that you have added a response to Abdu's explanation "All you need to do as you have done is to host internally" - but I think abdu mentioned "Cannot create zone internally". I think we would just need to create a zone for "" on internal DNS and have A record for CUCM and SRV for cisco-uds in pointing to the cucm. On external DNS too we will have, with SRV for collab-edge and A record for exp-E.




No, you cant do that how will jabber find the UDS domain?

The first thing jabber does is query for collab-edge SRV query using

Next is the public DNS will return the FQDN of your expressway server

Next Jabber will perform edge_config query proxied through expressway-e

expresway-e will send request to expressway-c and then expressway see will perform edge provisioning. Part of this task by expressway-c will be to perform a cisco-uds SRV query against the domain. Because at this point this is your discovery domain. When this is done, The internal DNS server with will then return the names of the UDS servers configured for the cisco-uds srv query eg

Now Jabber gets this and change its service discovery domain to

So you need to host internally. 

Dont forget to rate helpful posts!

Please rate all useful posts

Thanks for sharing the flow. I understand that.

I believe that the problem was that can't be hosted on internal domain, as it can break other forwarding relationship. If we could have hosted internally as well as externally, I believe there would have been lesser problems. But as Abdu mentioned "Cannot create zone internally" and "not allowed to publish (create zone) of one into another side", is the issue.

Referencing the dns configuration document (see the excerpt attached)

"Support of the fixed pinpoint subdomain has been replaced in later versions of Cisco Jabber by the support of the new VoiceServicesDomain configuration key. 

Example configuration using Service Discovery to replace pinpoint subdomains:

• Internal DNS authoritative for : example.local

• External DNS authoritative for :


Create a zone on both the internal and external DNS server for


So what is being asked to do is to create a zone for "" and not host first on internal DNS and then make cisco-uc as a child to, as this has the potential of disrupting the DNS structure.

With VoiceServicesDomain set to (or in Cisco document), shouldn't the UDS domain be and not Also, with VoiceServicesDomain set as, wouldn't the MRA client also query for collab-edge SRV in

"The client performs a Domain Name System (DNS) SRV record query for _collab-edge._tls.<domain>. This implies that when the domain from the login user ID is different than the domain from the Expressway E, you must use the voice service domain configuration. Jabber uses this configuration in order to discover the Collaboration Edge and the UDS"


Apologies, If I have misunderstood, but I believe the crux of the problem is that can't be hosted internally.




My point is this, however you do it either by creating a zone for the external domain or hosting it intenrally, that domain needs to be available because when you set your ServicesDomain (again you dont need voiceservicesdomain), all your query both internally and externally will be done against it.

I have done this a few times now and all the times, the external domain has been hosted internally. I have not used zones as you mentioned.

Please rate all useful posts

Honestly best approach is using both Services Domain and Voice Service Domain for different domain for internal and external.

If your Internal Domain is Internal.Domain

And External Domain is External.Domain

You should use configuration URL and or include the "Voice Service Domain" for Internal.Domain.

Changing a customers DNS environment by hosting the External Domain internally could be wide impacting (especially if it doesnt exist)


First of all there is a difference between services domain and voice services domain and it is good to know when you should use which one. Try and do some research and you may know why all you need is services domain and not voice service domain.

Secondly, even when you set your services domain to, your expressway-c will still need to run a DNS SRV query for that domain as part of Jabber discovery process, hence you still need to be able to do a lookup for in your internal DNS. 

Please rate all useful posts