We are configuring MRA with different internal and external domain name. internal domain is abc.local and external domain is abc.com
Exp C ,CUCM and IMP are in abc.local domain and Exp E is in abc.com domain. users using firstname.lastname@example.org to login to jabber .
So we created external SRV records . (_collab-edge._tsl.abc.com) . in internal DNS server we created _cisco-uds._tcp.abc.local.
From what I know , we need to create _cisco-uds._tcp.abc.com record in internal DNS as well .
The problem is since we cant add abc.com zone (it will affect the existing ERP setup ) we cannot create _cisco-uds._tcp.abc.com in our DNS server .
Is there any workaround for this ?
Solved! Go to Solution.
Take a look at pinpoint domain in the document below:
Take a look at pinpoint domain in the document below:
Thanks George . I was looking for a document like this .
but as per the document pinpoint subdomain is not supported in new version of jabber and it replaced by voice services domain .Can anyone tell me how to do that
in the jabber-config.xml
or from the outside to avoid logging in you can leave of the servicediscovery if you aren't using webex
Users can install jabber and launch this url from email to by pass logging in first. If you are using android devices you need to publish this as a webpage. Iphone/ipad/etc works fine
Thanks efisher for replying .
The issue here is I cannot add abc.com in my internal domain (abc.local is my local domain) . As George suggested pinpoint subdomain is a solution for this .But I dont know cisco support that now. Is there any other solution for this issue ?
As per the document you provided above
Support of the fixed pinpoint subdomain has been replaced in later versions of Cisco Jabber by the support of the new VoiceServicesDomain configuration key.
I have looked at a few jabber logs recently and I can say that I didnt see jabber querying cisco-internal.domain.com SRV record after collab-edge record and others failed. It may be that this is no longer supported. I suggest you use the "voiceservicesDomain" option..Here is an indepth detail on how to get this done
Thanks Ayodeji for the support
My issue is we have configured email in cloud so our email id is email@example.com and we have some other cloud service as well they are using abc.com to access those services. if I add abc.com zone in our internal DNS server every service stop working and employees cannot access emails. so I cannot add abc.com zone in our internal server.
I hope it is clear now. Is there any work around for the issue I am stuck at this point .
Infact ignore the idea of opening a TAC case. What you can do is put your expressway in abc.local. This is fairly easy since its defined by configuration and not any AD integration. With this, you can then define your voiceservicesdomain to be abc.local. You will then need to configure SRV records as follows
This section describes the configuration settings for the external and internal DNS records.
SRV record _collab-edge._tls.abc.local -------------points to FQDN of expressway
Type Entry Resolves To
SRV record _cisco-uds._tcp.abc.local -----points to CUCM
_cuplogin._tcp.abc.local-----points to IMP
This should do it for you.
Thanks for replying..
If I put my expressway in abc.local domain it is not routable from internet
abc.local is an internal domain ( it is not a registered domain ) registered domain is abc.com (routable from internet ) . We need to register Jabber from internet . do you think it will work ?
The expressway C will sit in the internal domain and doesnt have to be routable over the internet. The expressway E will sit in the DMZ/external network and that has to be on the abc.com domain. This will work just fine, I am not quite sure what you are concerned about.
As Ayodeji mentioned above, put the SRV records as he mentioned. One minor change is that external SRV record. It should be _collab-edge._tls.abc.com and not abc.local. which points to FQDN of Expressway E (eg.expe.abc.com).
When building the internal UC traversal zone and assuming you dont have any kind of split DNS, the FQDN of the Expressway E will be used as the peer address. This should resolve to the external public IP address assigned to the Expressway E.
If you follow the link that Ayodeji gave, that should work.There might be minor differences due to the latest version of 8.2.
George according to the documentation his setup will not work if he uses the guide, here is the argument:
1. He needs to set voice services domain to abc.com
The client performs a Domain Name System (DNS) SRV record query for _collab-edge._tls.abc.com. Jabber uses this configuration in order to discover the Collaboration Edge and the UDS.
2.Because the voice services domain is set to abc.com, Jabber embeds abc.com in the transformed URL for the Collaboration Edge configuration discovery (get edge_config). Once received, the Expressway-C performs an SRV UDS record query for abc.com and returns the records in the 200 OK message
So the transformed url will look like this:
Hence ExpwC needs to do a SRV query domain abc.com
The issue here is that his internal domain is abc.local, hence he cant configure SRV records for abc.com and as such any SRV query for that domain will fail.
SO it looks like for this to work your expwe domain has to be the same as your internal domain. Unless you can add new zones to your DNS server
If i use dual NIC in Expressway E, how do i setup the traversal zone? Should i use FQDN of Expressway E which is external domain?
If you use dual NIC, then the FQDN of expressway-E needs to resolve to the Internal IP of Expwe. The external interface will need to be natted to talk to the public.
Will this configuration work with 2 different domain? Like the example above, abc.local for internal and abc.com for external.
I know that this is an old post but running into similar situation.
Aneesh, just like you said -
internal = abc.local
external = abc.com
not allowed to publish (create zone) of one into another side
The problem is you have to use abc.com from outside for collab-edge discovery. Expressway-C will use _cisco-uds._tcp.abc.com 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 _cisco-uds._tcp.domain.com. /dsprimary
dnscmd . /recordadd _cisco-uds._tcp.domain.com. @ SRV 10 0 8443 cucm1.domain.com
dnscmd . /recordadd _cisco-uds._tcp.domain.com. @ SRV 20 0 8443 cucm2.domain.com
Hopefully you are able to sign certs from an external CA for domain.local.
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 = abc.com
Cannot create abc.com zone internally. The alternative is to create a sub-domain zone, for example "mra.abc.com" 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 abc.com. 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 abc.com internally and then point the cisco-uds SRV to mra.abc.com. Once Jabber gets the response for cisco-uds srv query, it will then use the mra.abc.com as the service discovery domain
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
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 abc.com while the uds is on mra.abc.com?
We should be able to do this using the VoiceServiceDomain configuration key, that will point to mra.abc.com while the services domain can remain as abc.com (as mentioned in http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide_chapter_010.html#CJAB_TK_U6868975_00 , although I find inconsistencies in the example give here)
I may have understood it wrong, but this is how it should work:-
Login using firstname.lastname@example.org and do not get uds SRV in abc.com, but are able to find collab-edge SRV that points to exp.abc.com
Query uds/collab-edge SRV in abc.com and do not get a response, but due to voiceservicesdomain configured as mra.abc.com query for uds again in mra.abc.com domain. uds SRV record exists on the internal name server for mra.abc.com domain pointing to cucm.mra.abc.com.
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.
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 abc.com, we would need to create a subdomain - say mra.abc.com 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 abc.com internally" - but I think abdu mentioned "Cannot create abc.com zone internally". I think we would just need to create a zone for "mra.abc.com" on internal DNS and have A record for CUCM and SRV for cisco-uds in mra.abc.com pointing to the cucm. On external DNS too we will have mra.abc.com, 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 abc.com
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 abc.com domain. Because at this point this is your discovery domain. When this is done, The internal DNS server with abc.com will then return the names of the UDS servers configured for the cisco-uds srv query eg xxx.mra.abc.com.
Now Jabber gets this and change its service discovery domain to mra.abc.com
So you need to host abc.com internally.
Dont forget to rate helpful posts!
Thanks for sharing the flow. I understand that.
I believe that the problem was that abc.com can't be hosted on internal domain, as it can break other forwarding relationship. If we could have hosted abc.com internally as well as externally, I believe there would have been lesser problems. But as Abdu mentioned "Cannot create abc.com 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) http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.pdf
"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 : example.com
Create a zone on both the internal and external DNS server for cisco-uc.example.com
So what is being asked to do is to create a zone for "cisco-uc.example.com" and not host example.com first on internal DNS and then make cisco-uc as a child to example.com, as this has the potential of disrupting the DNS structure.
With VoiceServicesDomain set to mra.abc.com (or cisco-uc.example.com in Cisco document), shouldn't the UDS domain be mra.abc.com and not abc.com? Also, with VoiceServicesDomain set as mra.abc.com, wouldn't the MRA client also query for collab-edge SRV in mra.abc.com?
"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 abc.com 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.
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 example.com, 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 _cisco-uds.example.com in your internal DNS.