Jabber: Internal Service Discovery fails after adding phone security profile and voice service domain.

[Malte_P_Scheuss]

Hy there,

we try to "disable" TCP over MRA, thats why we added a phone security profile to CSF phone. 

That means the PSP is encrypted, tls and port 5061 (because Expressways will just have TLS 5061 active).Also adding the  subdomain mra.domain.com as voice service doimain (no matter if jabber.xml or install parameter).

- SRV _collab-edge._tls.mra.domain.com works

- Expressway E certs fine with mra.domain.com

- Expressway C certs fine with internal certs incl. phone-security-csf.domain.com as SAN

- Jabber over MRA works fine just with TLS on

But when switching back to internal, Jabber does not look for internal SRVs. 

- Internal SRVs _cisco-uds._tcp.domain.com (also cuplogin) are set

- Service Domain Source by UPD = mail of user

=> Service Domain domain.com 

Switching back to internal network, Jabber still tries to connect to the edge service, no internal.

As i see in the jabber .log:

2021-07-20 13:41:07,089 DEBUG [0x00005e48] [s\impl\system\UserProfileBuilder.cpp(96)] [csf-unified.services.system.UserProfileBuilder] [CSFUnified::UserProfileBuilder::setUsernameToUserProfileEmailAddress] - Trying to retrieve the UserProfileEmailAddress from the UPN.

------

2021-07-20 13:41:07,279 DEBUG [0x00002bf4] [pters\config\ConfigStoreManager.cpp(174)] [ConfigService-ConfigStoreManager] [CSFUnified::ConfigStoreManager::getValue] - key : [servicesDomain] skipLocal : [0] value: [] success: [false] configStoreName: []
2021-07-20 13:41:07,279 DEBUG [0x00002bf4] [overyConfigurationInterfaceImpl.cpp(239)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getConfigValue] - servicesDomain key has not been found.
2021-07-20 13:41:07,279 DEBUG [0x00002bf4] [coveryConfigurationInterfaceImpl.cpp(69)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getDomain] - ServicesDomain not found in config, parsing email address.
2021-07-20 13:41:07,279 DEBUG [0x00002df0] [pters\config\ConfigStoreManager.cpp(174)] [ConfigService-ConfigStoreManager] [CSFUnified::ConfigStoreManager::getValue] - key : [TelemetryEnabled] skipLocal : [0] value: [false] success: [true] configStoreName: [BootstrapConfigStore]
2021-07-20 13:41:07,279 INFO [0x00002bf4] [s\impl\system\UserProfileManager.cpp(75)] [UserProfileManager] [CSFUnified::UserProfileManager::Impl::getUserProfileEmailAddressWithOrigin] -
2021-07-20 13:41:07,279 INFO [0x00002df0] [vice\src\services\impl\Governor.cpp(103)] [TelemetryService-Governor] [CSFUnified::telemetry::Governor::isDataIntakePermittedNow] - Data intake is forbidden by TelemetryEnabled criteria.
2021-07-20 13:41:07,279 INFO [0x00002bf4] [coveryConfigurationInterfaceImpl.cpp(87)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getDomain] - Domain built from email address
2021-07-20 13:41:07,279 INFO [0x00002df0] [csf-netutils\src\common\Reactor.cpp(195)] [csf.edge] [csf::common::Reactor::runEventLoop] - Reactor event loop entering wait()
2021-07-20 13:41:07,279 INFO [0x00002bf4] [coveryConfigurationInterfaceImpl.cpp(98)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getDomain] - Domain is set to: domain.com
2021-07-20 13:41:07,279 DEBUG [0x00002bf4] [pters\config\ConfigStoreManager.cpp(174)] [ConfigService-ConfigStoreManager] [CSFUnified::ConfigStoreManager::getValue] - key : [VoiceServicesDomain] skipLocal : [0] value: [mra.domain.com] success: [true] configStoreName: [BootstrapConfigStore]
2021-07-20 13:41:07,279 DEBUG [0x00002bf4] [overyConfigurationInterfaceImpl.cpp(229)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getConfigValue] - VoiceServicesDomain key retrieved value: mra.domain.com
2021-07-20 13:41:07,279 INFO [0x00002bf4] [overyConfigurationInterfaceImpl.cpp(173)] [service-discovery] [CSFUnified::DiscoveryConfigurationInterfaceImpl::getVoiceServicesDomain] - Retrieved VoiceServicesDomain: mra.domain.com
2021-07-20 13:41:07,279 INFO [0x00002bf4] [scovery\ServiceDiscoveryHandler.cpp(295)] [service-discovery] [CSFUnified::ServiceDiscoveryHandler::setupDiscoveryDomains] - *-----* Retrieved DNS Domain 'domain.com' from 'Windows User Principal Name (UPN)'
2021-07-20 13:41:07,279 INFO [0x00002bf4] [-diagnostics\src\DiagnosticsImpl.cpp(50)] [csf.diagnostics] [CSFDiagnostics::DiagnosticsImpl::AddRecord] - Add record task enqueued: Services Domain
2021-07-20 13:41:07,279 INFO [0x00002bf4] [-diagnostics\src\DiagnosticsImpl.cpp(50)] [csf.diagnostics] [CSFDiagnostics::DiagnosticsImpl::AddRecord] - Add record task enqueued: Services Domain Source

------

Discovery is setup with ServicesDomain: domain.com and VoiceServicesDomain: mra.domain.com

------

"Updating GlobalEdgeStateController. Domains: Internal- mra.domain.com, External- mra.domain.com"

Any ideas? 

[Adam Pawlowski]

If you've told the client that voice services are at mra.domain.com, it will go over there at some point and attempt to connect to those services. The diag screen makes it look like the collab edge record isn't visible there internally, so you could add cisco-uds there. Not entirely sure what your requirements are that the two things are split up with this specification, when it should be able to run fine if the domain.com is the same in both instances - its just saying where the DNS records are here.

MRA is encrypted, it uses TLS between it and the client for authentication, HTTP/HTTPS, SIP, media, etc.

As far as I am aware, unless something is changed CAPF enrollment does not work over MRA. If your solution supports oAuth and the phone security profile has that checked then it will work, and encryption will be formally enabled and capable throughout the solution, and not just between the client and the Expressway.

[Malte_P_Scheuss]

Hi Adam, 

does that mean, when I rollout a new voice service domain (mar.domain.com) it will overwrite the regular service domain? 

Because without psp it worked fine: That means internal SRV (uds ans cuplogin) lookup by service domain and outside SRV (edge) over voice service domain.

With psp internal and external SRV lookup just over voice serve domain. as send in the logfile.

Bug or Feature?

[Roger Kallberg · Accepted solution]

AFAIK when you set the voice service domain it will be used for all service discovery. Again AFAIK there is no option to use one domain externally and another internally for service discovery.

[Malte_P_Scheuss]

Worked.

internal DNS SRVs set with subdomain mra.domain.com and boom

CSF with psp (TLS 5061)

Just TLS on Expressway

now it’s done

thanks all

[Adam Pawlowski · Accepted solution]

I suppose anything could be a bug or unexpected behavior - the documentation only covers so many scenarios and sometimes things don't work as expected outside of that realm.

Here's what the parameter's description is:

VoiceServicesDomain

Applies to all the Cisco Jabber clients.

Specifies the Fully Qualified Domain Name that represents the DNS domain where the DNS SRV records for _collab-edge and _cisco-uds are configured.

Example: Given the following DNS SRV records:

• _collab-edge._tls.voice.example.com

• _cisco-uds._tcp.voice.example.com

The VoiceServicesDomain value will be voice.example.com.

Note	Don't configure this parameter for MRA when your voice services domain is the same as the sign-in account domain. For deployments with MRA, only configure this parameter if the domains are different.

In a lab scenario, I had connected to a system by signing into Jabber, over MRA, as myself@test.company.tld , which signed in as expected initially. However, the Jabber client subsequently loaded the configuration file, and I had the voiceservicesdomain parameter set to the production company.tld system. After some time the client began to probe and connect there, which broke Jabber.

Based on the above, I'd expect it to do this, and if I'd deployed it where test.company.tld did not have the DNS records, Jabber probably would have fallen back to that key? I don't really know in which order or timeframe to expect the client to do what, as the documentation only outlines that specific scenario. The client may have other behaviors for service discovery which may result in it operating when that's configured but records are missing (as it may have discovered them initially from initial service discovery).

I'm not too familiar with the phone security process with Jabber, as our shop is MRA only, and CAPF enrollment has to be done on premise before it works over MRA. oAuth works without this limitation if your solution supports it. I reset my client and signed in to see if I could see in the logging where it referenced the security profile, but, I was not able to find it. Perhaps the need to retrieve or validate the certificate is triggering the service discovery process again.

TAC might be able to help validate your configuration that it is arranged in a supported way, just due to the sometimes unexpected interaction of the components.

[Malte_P_Scheuss]

Hey guys, our SP told us about this Bug CSCvi88267 

seems like no big issue but seems like my problem

-> possible solution in that case:

internal SRVs for domain.com & mra.domain.com

-> because if device gets the voice service domain by xml or install it will now look for internal mra.domain.com 

external can stay as it is