cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6433
Views
15
Helpful
17
Replies

Jabber Expressway MRA connects to all but Softphone

kdotten36
Participant
Participant

Looking for some assistance.  I have Expressway 8.7 in the recommended two-legged design except not using NAT since the outside interface is already publicly accessible.  I have a valid Cert on exp-e, and a privately created CA cert on exp-c using the Certificate Guide and OpenSSL.

Getting Failed to Establish SSL errors.  In the debugging logs I see "peer did not return a certificate".  I have my private CA and self-signed CM cert installed to the Enterprise Trust store on the laptop and the iPhone from which I'm connecting.

CUCM (9.1.2) has a tomcat cert also signed by the private CA, and the CallManager cert is self-signed.  The root private CA and self-signed CM certs are uploaded as Trusted CA on both expressways.  I've tested Jabber for iPhone and Jabber for Windows and both can successfully register externally with Exp-E, IMP, CUX, but not the softphone.  I have a SIP Trunk for outbound calls and the Security SIP Profile has a separate port configured and there are two traversal zones, one for UC and one for that purpose.  I also tried removing the Trunk's traversal zone and all references to it in case it was interfering and got the same results.

I'm attaching one of the Jabber Problem Reports and a Developer's log from expressway E.  The time of the registration failure is 16:30 on 2/4/16.

If more are needed I can run another.  Thanks for looking.

EDIT: Forgot to mention, I also tried adding a firewall rule to allow all traffic to and from the expressway temporarily and it still didn't work, so it shouldn't be a firewall oversight.

1 Accepted Solution

Accepted Solutions

Wish I hadn't wasted so much of my own time on this, but it is now resolved.

Device Config > Built In Bridge needs to be Off.  It was set to Default which is On by a Service Parameter on our cluster.

The engineer said it's the second case he'd seen of this nature and will submit for it to be included in future deployment guides.

Registrations are now clean after network changes, service outages and app terminations.

View solution in original post

17 Replies 17

Chris Deren
Hall of Fame Master Hall of Fame Master
Hall of Fame Master

Are the CSF and TCT devices configured and associated with the end user? Do they work on internal network? Registration of soft phone has nothing to do with SIP trunks, etc. those are only used for B2B video across Expressway. 

Yes, the devices were configured correctly and work on the internal network.  I understand the SIP Trunks are not used for MRA, I only mentioned it because it's a common mistake have the SIP ports conflict between neighbors so I was trying to convey all available detail.

As coincidence would have it, I was able to finally get it working about an hour ago.  The problem was the Default Zone configuration on the C and E.  I configured both Expressways strictly by the guides (Basic Configuration, Mobile and Remote Access via Expressway, and Certificate Creation and Use Deployment Guide) from factory defaults, and both Default Zones were set with an Authentication policy of "Do not check credentials" and Use Default Zone access rules on port to "TLS (5061) and MTLS (5062)".  After picking apart the Admin Guide to better understand these settings, I changed those to the following...

Expressway-C - Default zone

Authentication policy = Check credentials
SIP Media encryption mode = Best effort
Use Default Zone access rules on port = MTLS Only (5062)

Expressway-E - Default zone

Authentication policy = Treat as authenticated
SIP Media encryption mode = Best effort
Use Default Zone access rules on port = MTLS Only (5062)

That fixed it.  Devices now register and calls are flowing.  What strikes me as odd is that none of the documentation mentions this, unless I'm mistaken, I even specifically searched for recommended Default Zone settings for MRA when I began to suspect it.  I guess it's possible some non-standard network config on our end made my setup an exception, but I would think it's an important step to cover if it is indeed required.

Thanks for the response though.  I'm a big fan of CDW (you're our Cisco partner!), and sorry to be so wordy, just trying to help out the next dud who failed miserably at this for as long as I did.

</