Do we have the same Certificate requirement if are using CMS with Expressway if Dial-In from external S4B client ?
as we are using CMS-Core and CMS-Edge ?
because I have move the config solution from
Expr-E -- Exp-C -- CMS-Core
- Exp-E is Single NIC with Public IP
- Turn Server using of Expr-E
- wbeRTC via Expr-E to CMS-Core is running well !
- so it seems TURN Server is running
- RMS License exist on the Exp-E ( I think is needed, without License Call was not going trough the Exp-E)
- CMS running SW 2.1.7
- Expressway running X8.9.2
At the moment I have the following Certificate:
- Dial-in from S4B to CMS is ringing but call can not established, after 10 sec disconnect:
call 1: recognised as Lync
2017-05-10 13:45:49.883 Info call 1: incoming encrypted SIP call from "sip:email@example.com" to local URI "sip:firstname.lastname@example.org" (Lync)
2017-05-10 13:45:50.455 Info participant "email@example.com" joined space 4a04eb96-3309-4296-8901-9260b77b6a9c (user Spaces)
2017-05-10 13:45:56.201 Info call 1: media framework reporting rx video RTP frequency 0 - fixed up to 90000
2017-05-10 13:46:01.645 Info call 1: ending; remote SIP teardown; ICE negotiation in process - connected for 0:11
2017-05-10 13:46:01.646 Info participant "firstname.lastname@example.org" left space 4a04eb96-3309-4296-8901-9260b77b6a9c (user Spaces)
- Dial-Out from CMS to S4B , the same problem
- Eventlogs on the Exp-C / Exp-E
I see the Calls on the Expressway's is going to the right traversal Link,
Any Input or help appreciated.
Solved! Go to Solution.
Did you configure you CMS to use the Expressway-E TURN?
I have configured Expressway-E TURN, and is working well for webRTC
and yes I have seen the new guide, so far the search rule and traverselling is working fine, maybe the Problem could be Single NIC on Exp-E
with TURN ? or Certificate, but the call is established I see not a certificate Problem , more as soon the starting the ICE connection
Have you looked at the SIP logs? Are you seeing a 504 Server time-out? If yes, do you have the Expressway's certificate signed by a 3rd party CA? Does this certificate have both the domain you are calling from as well as the Expressway's FQDN in the SAN?
Be sure to have your SRV records _sipfederationtls mapping the SAME domain than the A records from the Expressway. Microsoft rejects thing like:
_sipfederationtls._tcp.domainA.com ==> expresswaye1.domainB.com
Then it clearly shows a turn issue, I had the same.
When establishing the call, during the 10 secs while the call is connected, quickly checks the CMS Status ==> Calls, expand the S4B participant and check if there is media recognized. If it shows no audio/ni video, then you have a TURN issue.
Ports must be open between CMS and ExpE (3478 and 24000-29999, see docs).
It seems like we have an IDENTICAL config as Georg, with very similar issues. We are very early in the config, but we're trying to configure the "Open Federation with MS Organizations" section with difficulty when federating with external microsoft domains.
Call Leg 1: Cisco IP Video Phone calls external MS domain, call routes from core to cms call bridge
Call Leg 2+: CMS call bridge sends new call to core over lync type trunk. Core sends call over B2B traversal to edge. Cisco edge [expressway] routes call as ms sip av & share over to MS Edge.
Cisco IP Phone gets 1xx messages the entire time and ringback is even heard. External ms client rings. When answered, Cisco IP Phone sees CMS logo and recording "you are the only participant, goodbye" and the call drops.
I still need to get the traces sorted out, but from the ms client end, there appears to be lots of attempts for different kinds of candidates, but the sdp from the Cisco Edge only has 2 (itself and TURN to CMS).
Could ICE not be operational on the Cisco Edge? Would it need to be enabled on the Default Zone, or the initial DNS (Outbound) Zone? Is this even possible to do with a single NIC deployment?
Now for the good part...
If the call is NOT answered by the ms client, call forwards to voicemail...Exchange Online UM. Call is answered and two way audio established. TURN is being leveraged and operational. It appears to only be with ICE type calls. Could encryption on the Cisco side be suspect?
We have the CMS set to Encrypted on the outbound call and SIP Encryption set to allowed under SIP settings. Do we need to set media encryption to forced for zones on core &/or edge clusters?
Still real early in our attempts. But we do have Cisco Advanced Services actively engaging.
One more thing to note. This cluster pair is also configured for MRA. The zone we're using for B2B calling is a secure traversal zone (not the UC used for MRA). SIP Standards calls are fine.
Thanks for all Inputs
- SRV Record is Ok
I think could be a TURN Issues, I will checking again the Firewall, should be Ok.
by the way I have open a Cisco TAC case
Take a look at media encryption field at CMS. Try to change and see if it works.
Use SIP Trace/debug at CMS to check the details of a SFB call and responses.
I have a similar ICE Negotiation whilst sharing content:
Mar 28 09:36:28 user.info LTSA-JHB-CMS01 host:server: INFO : call 2: recognised as Lync (application sharing)
Mar 28 09:36:28 user.info CMS01 host:server: INFO : call 2: incoming e ncrypted SIP call from "sip:email@example.com" to local URI "sip:firstname.lastname@example.org" (Lync sharing)
Mar 28 09:36:28 user.info CMS01 host:server: INFO : pairing incoming Lync call from 'email@example.com' with existing call
Mar 28 09:36:28 user.info CMS01 host:server: INFO : call 2: content receiver starting for 192.168.86.152
Mar 28 09:36:28 user.info CMS01 host:server: INFO : call 2: created application sharing handler on 192.168.86.152
Mar 28 09:36:41 user.info CMS01 host:server: INFO : call 2: ending; remote SIP teardown; ICE negotiation in process - connected for 0:11
On the default, traversal server, client and CMS zone, ive enabled ICE support and i have no joy.
Georg, what was your issue with regards to the firewall config? May have the same issue although calls are successful. The way i see content sharing from S4B, its just another call leg into CMS.
Any help would be great !
I can not really say what was the problem, Customer told me, that he has configured a wrong or used a wrong profile which contains 1:1NAT , FW is working as L2 Firewall, maybe helps Customer is using Wathchguard.