Re: MRA OAuth Soft phone registration sent on wrong port (5061 instead

maxwellbarron · ‎03-08-2021

I recently upgraded my corporate UC systems to 12.4 (from 11.5) in order to implement OAuth for security vice CAPF on Jabber devices. However, once the security profile is set to OAuth, soft phones fail to register through MRA (on Prem devices continue to register and function as normal). I have checked the documents and followed the guides for implementation. OAuth on CUCM is enabled and sip-oauth mode is on. Expressway-C CUCM deployment refreshed and shows the auto created CEOAuth zone and search rule, CUCM shows contactable on port 5091. IM&P, Voicemail, and Directory all connect and function on MRA. However, I find the following errors when logging in over MRA on a desktop Jabber client:

"sipoauthflag set to TRUE on device's security profile. Register received on wrong port(5061)!
02115959.012 |10:37:57.167 |AppInfo |DMMSStationD-SD(23) - sendRegisterResp: non-200 response code 403, ccbId 213436, expires 4294967295, warning SIP OAuth Registration port Mismatch
02115959.013 |10:37:57.167 |AppInfo |DMMSStationD-SD(23) - DevStat-StopClose: SIP OAuth Registration port Mismatch"

Everything works as expected if I turn off OAuth on the sip security profile (just as it did prior to upgrade -- this includes the use of tokens)

Jabber config XML has <SSO_Enabled>TRUE</SSO_Enabled> and login provides authentication webpage, login clears, tokens are granted per Expressway logs.

I have found no way to configure this behavior... Port 5091 is NOT blocked between C and CUCM. I am unsure of why the registration is being sent to CUCM port 5061 instead of 5091. Can anyone here be of assistance?

Expressway-C Config:

UC

Unified Communications mode: MRA

Authentication Path: UCM / LDAP

Authorize by OAuth token with refresh: on

Authorize by user credential: on

Allow Jabber iOS clients to use embedded Safari browser: No

Check for internal authentication availability: Yes

Allow activation code onboarding: No

UC Traversal Zone configs

Port: 7002

Accept proxied registrations: Allow

ICE support: Off

ICE Passthrough support: On

Multistream mode: On

SIP poison mode: Off

Preloaded SIP routes support: Off

SIP parameter preservation: Off

AES GCM support: Off

SIP UPDATE for session refresh: Off

Authentication policy: Do not check

Accept delegated credential checks: Off

maxwellbarron · ‎03-11-2021

Reviewing logs I have noted that the registration request from the internal interface of the E to the C shows a route to the CUCM on port 5091. However, the SIP registration message from the next leg (C to CUCM) shows a route to CUCM on port 5061. SIP messages below. I do not see any failed or rejected messages to CUCM on port 5091. It appears that for some reason the C simply changes the route to the standard TLS zone. the CEOauth zone shows valid and reachable. I have found nothing in the logs thus far to show any TLS failures between C and CUCM.

From internal E interface to C

Via: SIP/2.0/TLS x.x.x.30:7002;egress-zone=UCZone;branch=z9hG4bKc01eb9798d367a2a326fcdc7f588fc3964507.a4279ab1d5ef4fbd0cae6b00ce9a00c2;proxy-call-id=4aa6fbb6-90c2-4959-8a53-b97307ee4317;rport
Via: SIP/2.0/TLS x.x.x.144:54354;branch=z9hG4bK24b4cc05;received=x.x.x.171;rport=54354;ingress-zone=CollaborationEdgeZone
Call-ID: ac87a32c-e1a306f2-29e7e88f-385519c7@x.x.x.144
CSeq: 3673 REGISTER
Contact: <sip:2c9c835f-aef9-4e5f-3ab3-38af6680d19e@x.x.x.144:54354;transport=tls>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-ac87a32ce1a3>";+u.sip!devicename.ccm.cisco.com="CSFmaxbarron";+u.sip!model.ccm.cisco.com="503";video;+u.sip!userid.ccm.cisco.com="max.barron"
From: <sip:8030@x.x.x.101>;tag=ac87a32ce1a306f45b0f74b5-53b745c7
To: <sip:8030@x.x.x.101>
Max-Forwards: 15
Route: <sip:x.x.x.101:5091;transport=tls;lr>
Path: <sip:x.x.x.30:7002;transport=tls;lr>
Path: <sip:x.x.x.171:54354;transport=tls;apparent;ds;lr>
User-Agent: Cisco-CSF
Expires: 3600
Date: Thu, 11 Mar 2021 15:53:25 GMT
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1,X-cisco-graceful-reg,X-cisco-duplicate-reg,path
P-Asserted-Identity: <sip:8030@x.x.x.101>
X-TAATag: 267ee2ec-b89e-4ce6-87b8-325b3532f66d
Reason: SIP ;cause=200;text="cisco-alarm:24 Name=CSFmaxbarron ActiveLoad=Jabber_for_Mac-12.9.4.304807 InactiveLoad=Jabber_for_Mac-12.9.4.304807 Last=phone-reg-rej"
Session-ID: 2b358b7f00255000a0000757bf950000;remote=00000000000000000000000000000000
Mime-Version: 1.0
Content-Type: multipart/mixed;boundary=uniqueBoundary
Content-Length: 1295

--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
Content-Disposition: session;handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<x-cisco-remotecc-request>
<bulkregisterreq>
<contact all="true">
<register></register>
</contact>
</bulkregisterreq>
</x-cisco-remotecc-request>
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
Content-Disposition: session;handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<x-cisco-remotecc-request>
<optionsind>
<combine max="6">
<remotecc>
<status></status>
</remotecc>
<service-control></service-control>
</combine>
<dialog usage="hook status">
<unot></unot>

</dialog>
<dialog usage="shared line">
<unot></unot>

</dialog>
<presence usage="blf speed dial">
<unot></unot>

</presence>
<joinreq></joinreq>
<cfwdall-anyline></cfwdall-anyline>
<coaching></coaching>
<oosalarm></oosalarm>
<x-cisco-number></x-cisco-number>
<bfcp></bfcp>
<ix></ix>
<gatewayrecording></gatewayrecording>
<conferenceDisplayInstance></conferenceDisplayInstance>
<qos-tcl></qos-tcl>
</optionsind>
</x-cisco-remotecc-request>
--uniqueBoundary--

Warning in logs prior to sending reg req on 5061:: 2021-03-11T10:53:25.207-05:00 x-x-expsc1 tvcs: UTCTime="2021-03-11 15:53:25,207" Module="developer.sip.leg.adjacency" Level="WARN" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(446)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7f97a5ae4700": Ports from route and zone differ, should be the same, using zone one: gkSipPort="5061"

From C to CUCM

Via: SIP/2.0/TLS x.x.x.51:5061;egress-zone=CEtls102100101;branch=z9hG4bK37f4bc4f8d85def0f830a9a1f8f83d9430949.58ba70479ee87b0cbd15bfa437923347;proxy-call-id=72cd56f2-3626-4465-af77-556787dad361;rport
Via: SIP/2.0/TLS x.x.x.30:7002;egress-zone=UCZone;branch=z9hG4bKc01eb9798d367a2a326fcdc7f588fc3964507.a4279ab1d5ef4fbd0cae6b00ce9a00c2;proxy-call-id=4aa6fbb6-90c2-4959-8a53-b97307ee4317;received=x.x.x.30;rport=7002;ingress-zone=UCZone
Via: SIP/2.0/TLS x.x.x.144:54354;branch=z9hG4bK24b4cc05;received=x.x.x.171;rport=54354;ingress-zone=CollaborationEdgeZone
Call-ID: ac87a32c-e1a306f2-29e7e88f-385519c7@x.x.x.144
CSeq: 3673 REGISTER
Contact: <sip:2c9c835f-aef9-4e5f-3ab3-38af6680d19e@x.x.x.51:5061;transport=tls;orig-hostport=x.x.x.144:54354>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-ac87a32ce1a3>";+u.sip!devicename.ccm.cisco.com="CSFmaxbarron";+u.sip!model.ccm.cisco.com="503";video;+u.sip!userid.ccm.cisco.com="max.barron"
From: <sip:8030@x.x.x.101>;tag=ac87a32ce1a306f45b0f74b5-53b745c7
To: <sip:8030@x.x.x.101>
Max-Forwards: 14
Route: <sip:x.x.x.101:5061;transport=tls;lr>
User-Agent: Cisco-CSF
Expires: 3600
Date: Thu, 11 Mar 2021 15:53:25 GMT
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1,X-cisco-graceful-reg,X-cisco-duplicate-reg,path
P-Asserted-Identity: <sip:8030@x.x.x.101>
X-TAATag: 267ee2ec-b89e-4ce6-87b8-325b3532f66d
Reason: SIP ;cause=200;text="cisco-alarm:24 Name=CSFmaxbarron ActiveLoad=Jabber_for_Mac-12.9.4.304807 InactiveLoad=Jabber_for_Mac-12.9.4.304807 Last=phone-reg-rej"
Session-ID: 2b358b7f00255000a0000757bf950000;remote=00000000000000000000000000000000
Mime-Version: 1.0
Content-Type: multipart/mixed;boundary=uniqueBoundary
Content-Length: 1295

--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
Content-Disposition: session;handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<x-cisco-remotecc-request>
<bulkregisterreq>
<contact all="true">
<register></register>
</contact>
</bulkregisterreq>
</x-cisco-remotecc-request>
--uniqueBoundary
Content-Type: application/x-cisco-remotecc-request+xml
Content-Disposition: session;handling=optional

<?xml version="1.0" encoding="UTF-8"?>
<x-cisco-remotecc-request>
<optionsind>
<combine max="6">
<remotecc>
<status></status>
</remotecc>
<service-control></service-control>
</combine>
<dialog usage="hook status">
<unot></unot>

</dialog>
<dialog usage="shared line">
<unot></unot>

</dialog>
<presence usage="blf speed dial">
<unot></unot>

</presence>
<joinreq></joinreq>
<cfwdall-anyline></cfwdall-anyline>
<coaching></coaching>
<oosalarm></oosalarm>
<x-cisco-number></x-cisco-number>
<bfcp></bfcp>
<ix></ix>
<gatewayrecording></gatewayrecording>
<conferenceDisplayInstance></conferenceDisplayInstance>
<qos-tcl></qos-tcl>
</optionsind>
</x-cisco-remotecc-request>
--uniqueBoundary--

maxwellbarron · ‎03-11-2021

Ran another round of tests with all debugging options on. Here is an excerpt that is interesting. I also found an excerpt showing that it discovered OAuth on port 5061. CUCM is configured for 5091 and the zone configuration page shows 5091. So it knows the zone exists. I also see the keep alives to the CUCM:5091. I'm at a complete loss here. I can see no real reason for C to send OAuth configured devices through the CETls zone instead of CEOAuth zone.

2021-03-11T17:15:40.739-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:40,734" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(933)" Method="ZoneManager::getNonTraversalServerZoneListByAddr" Thread="0x7fcb7772f700": this="0x55e53bd49020" Zone CEtcp-x.x.x.101 with remote address ['IPv4''TCP''x.x.x.101:5061'] found
2021-03-11T17:15:40.739-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:40,734" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(933)" Method="ZoneManager::getNonTraversalServerZoneListByAddr" Thread="0x7fcb7772f700": this="0x55e53bd49020" Zone CEtls-x.x.x.101 with remote address ['IPv4''TCP''x.x.x.101:5061'] found
2021-03-11T17:15:40.739-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:40,734" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(933)" Method="ZoneManager::getNonTraversalServerZoneListByAddr" Thread="0x7fcb7772f700": this="0x55e53bd49020" Zone CUCM-B2B with remote address ['IPv4''TCP''x.x.x.101:5061'] found
2021-03-11T17:15:40.739-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:40,734" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(933)" Method="ZoneManager::getNonTraversalServerZoneListByAddr" Thread="0x7fcb7772f700": this="0x55e53bd49020" Zone B2B-testing with remote address ['IPv4''TCP''x.x.x.101:5061'] found
2021-03-11T17:15:40.739-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:40,734" Module="developer.zone.zonemgr" Level="DEBUG" CodeLocation="ppcmains/oak/zones/ZoneManager.cpp(933)" Method="ZoneManager::getNonTraversalServerZoneListByAddr" Thread="0x7fcb7772f700": this="0x55e53bd49020" Zone CEOAuth-x.x.x.101 with remote address ['IPv4''TCP''x.x.x.101:5061'] found

2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.config" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyConfigDb.cpp(491)" Method="SipProxyConfigDb::isUsInDNS" Thread="0x7fcb7893d700": DNS isUs check , host=x.x.x.101, dnsHostName=x-expsc1, fqdn=x-expsc1.x.x.com, clustername=
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(339)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700":
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(346)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700": Detail="URL to use" url="sip:x.x.x.101:5091;transport=tls;lr"
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(436)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700": Detail="Zone details"ZONETYPE_NEIGHBOURCEtls-x.x.x.101
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(440)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700": Port numbers from route and from zone port="5091" gkSipPort="5061"
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="WARN" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(446)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700": Ports from route and zone differ, should be the same, using zone one: gkSipPort="5061"
2021-03-11T17:15:31.609-05:00 x-expsc1 tvcs: UTCTime="2021-03-11 22:15:31,604" Module="developer.sip.leg.adjacency" Level="DEBUG" CodeLocation="ppcmains/sip/sipproxy/SipProxyLegAdjacency.cpp(468)" Method="SipProxyLegAdjacency::setNextHopFromUrl" Thread="0x7fcb7893d700": setNextHopAddr: address="x.x.x.101:5061/TLS" zone="CEtls-x.x.x.101" destinationIsNatted="false"

Peter Kuznicki · ‎08-12-2021

Running into exact same issue after enabling SIP OAuth mode on CUCM 12.5 (SU4) and Expressway's version x12.5.4. Have you found a fix for this?

jdiegmueller · ‎08-15-2022

@Peter Kuznicki wrote:
Running into exact same issue after enabling SIP OAuth mode on CUCM 12.5 (SU4) and Expressway's version x12.5.4. Have you found a fix for this?

I realize this is a tick over a year old, but wanted to give this thread a bump to ask if anyone in the thread figured this out? I have the same issue with one specific customer running CUCM 12.5(1)SU6. Expressway was originally on Expressway X12.7.1, but I also tried upgrading to X14.0.8 without any success.

Curious if the other folks who reported this were perhaps using IPs (vs FQDNs) for the CUCM node definitions in System->Server? This customer is, and that's the only thing that's a little unique about this enviornment. Hoping that isn't it the cause, because migrating this particular customers to FQDN-based node definitions is simply not possible at this time.

jdiegmueller · ‎08-15-2022

@jdiegmueller wrote:
Curious if the other folks who reported this were perhaps using IPs (vs FQDNs) for the CUCM node definitions in System->Server? This customer is, and that's the only thing that's a little unique about this enviornment. Hoping that isn't it the cause, because migrating this particular customers to FQDN-based node definitions is simply not possible at this time.

Appears that indeed this is the root cause (and I suspect was for you other folks, too):

* https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu30173

Peter Kuznicki · ‎08-15-2022

Looking through my notes I believe this issue was resolved by uploading the root and intermediate certs that signed the Exp C server certificate to CUCM as tomcat-trust and then restarting CUCM cluster.

b.winter · ‎08-15-2022

But this is already stated big and fat on the download page of the related Expressway-versions:

Cisco can't make it easier than this, as it seems a lot of people are not able to read release notes, upgrade guides, or other docs anymore.

Peter Kuznicki · ‎08-15-2022

Agree for version X14, however this was for version X12.5.4 and don't recall seeing anything about that in the documentation.

b.winter · ‎08-15-2022

Because it was not necessary for versions lower than X14.
Maybe you ran into another issue and you resolved it with what you did.

MRA OAuth Soft phone registration sent on wrong port (5061 instead of 5091) - Still unresolved