Hi Prasanth,
So consider voice service domain as an "alternate domain". By default jabber always does service discovery on the domain through which you login, in case there is a requirement for service discovery to be done apart from the login domain you use "voice service domain".
This is very handy in a scneario such as collaboration edge (MRA). So consider that all the users logs in to Jabber when they are inside the enterprise network with domain "xyz.local", but when they try to login to Jabber while they are at home the domain "xyz.local" won't be available. But if the jabber-config.xml has voice service domain say as "xyz.com" then what happens is when the jabber service discovery fails with "xyz.local", it falls back to "xyz.com". and runs the service discovery.
Voice service domain only kicks in when the service discovery fails with login domain.
Service discovery will be something like this in internal/external scenario
Internal login
_cisco-uds._tcp.xyz.local --fails
_collab-edge._tcp.xyz.local --fails
use voice service domain
_cisco-uds._tcp.xyz.com -- pass.
---------------------------------------
On collaboration edge (MRA)
_cisco-uds._tcp.xyz.local --fails
_collab-edge._tcp.xyz.local --fails
Use voice service domain
_cisco-uds._tcp.xyz.com --fails
_collab-edge._tcp.xyz.com --pass
The drawback of using the voice service domain is users must login to jabber atleast once using the actual login domain so that jabber-config.xml file can be pushed and then this way Jabber knows about the "voice service domain".
However i can't think of any use case to use voice service domain in a scenario when Jabber logins with in an enterprise network.
Regards,
Alok
