cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5520
Views
1
Helpful
7
Replies

vcs or expressway: force unencrypted video sip call

r.rung
Level 1
Level 1

Hello Support Community,

 

let's say i have a cisco vcs or cisco Expressway Server and i want to make an outgoing sip video call.

to make the troubleshooting easier, i want to have an unencrypted sip call, even though the other external side is able to do encryption (has an _sips SRV record).

 

is there a way to do this on X8.6.1?

 

what i tried so far withour success: ( i tried it in that order)

-> Expressway-Edge: Setting the DNS Zone (B2B) Fallback transport protocol to TCP and Media encryption mode to "force unencrypted"

-> both Expressways: Setting the Zone "TraversalClient (B2B) SIP" to Transport "TCP" and Media encryption mode to "force unencrypted"

-> CUCM is not in Mixed mode

-> but the call is always encrypted from expressway-edge to the external client.

-> When i set "Configuration -> Protocols -> SIP -> TLS mode to off the call is dropped and no signaling is send to the other side

1 Accepted Solution

Accepted Solutions

Based on your previous post:

"with outgoing call i mean it's a business to business call from an endpoint that is registered to CUCM and then uses the firewall traversal of Expressway Series Server to connect to an outside SIP Client. (external domain)"

On my understanding, this is a MRA deployment with B2B calling.

For CUCM controlled environment with MRA wherein any call to or from Expressway-E that utilizes the CUCM-Expressway traversal zone is always encrypted. The CUCM traversal zone (Expressway X8.6) is automatically configured with appropriate parameters and cannot be modified which were set to SIP TLS with TLS verify mode set to ON and Media encryption mode set to Force encrypted.

 

regards,

Acevirgil

 

View solution in original post

7 Replies 7

shawnangelo
Level 1
Level 1

First off, is it a VCS or an Expressway solution. There are actually differences.

Secondly, when you say "outgoing call" are you referring to:

from an internally registered client (CUCM, VCSc, ExpresswayC) to an externally registered client (Expressway E VCSe)?

 

Or a typical business to business call from an internally registered client (CUCM, VCSc, ExpresswayC) to another domain outside of the environment?

Does the external domain resolve a _sip._tcp record?

Also, how are you determining that the call is truly end-to-end encrypted? Are you verifying that the encryption exists at all of the legs?

UCM/Client

Expressway-C/VCS-c

Expressway-E/VCS-e

Internet Client

 

 

 

oh i did not know that there is a techinical differences between vcs and expressway.

with outgoing call i mean it's a business to business call from an endpoint that is registered to CUCM and then uses the firewall traversal of Expressway Series Server to connect to an outside SIP Client. (external domain)

 

the external domain resolves _sips._tcp.domain.com and _sip._tcp.domain.com.

well the call is no end-to-end encrypted but i saw in the tcpdump file and in the information that you can see on expressway while the call is active that the call leg from Expressway-Edge to the external client is always TLS Encrypted. with the changes i did (explained in the first post) i can influence that the call legs from the internal client to CUCM, from CUCM to Expressway-CORE and between the Expressways are unencrypted.

Try this and post the log results.

 

-> Expressway-Edge: Setting the DNS Zone (B2B) Fallback transport protocol to UDP or TCP and Media encryption mode to "Auto" or "Force Unencrypted" (try both variants)

(do not perform this step) -> both Expressways: Setting the Zone "TraversalClient (B2B) SIP" to Transport "TCP" and Media encryption mode to "force unencrypted"

(do not perform this step) -> When i set "Configuration -> Protocols -> SIP -> TLS mode to off the call is dropped and no signaling is send to the other side

Hello shawnagelo,

 

sorry for the late answer, i was very busy the last time.

so i tried both variants and in the protocol i always see that the signaling is encrypted: (status - calls - calls)

Leg 2
Bandwidth nodeDNS Zone (B2B)
Target alias 1sip:called.sipuri.de (Url)
ProtocolSIP
Address193.158.104.xx:5061
TransportTLS
Encryption typeAES

i'm not sure where i can see if media is also encrypted, but of course i need to have signaling and media unencrypted for troubleshooting.

the far end side (Telepresence MX200) shows:

Call 
ProtocolSIP
Transmit call rate384 kbps
Receive call rate6000 kbps
EncryptionAES-128

Based on your previous post:

"with outgoing call i mean it's a business to business call from an endpoint that is registered to CUCM and then uses the firewall traversal of Expressway Series Server to connect to an outside SIP Client. (external domain)"

On my understanding, this is a MRA deployment with B2B calling.

For CUCM controlled environment with MRA wherein any call to or from Expressway-E that utilizes the CUCM-Expressway traversal zone is always encrypted. The CUCM traversal zone (Expressway X8.6) is automatically configured with appropriate parameters and cannot be modified which were set to SIP TLS with TLS verify mode set to ON and Media encryption mode set to Force encrypted.

 

regards,

Acevirgil

 

this was the answer i searched for, but did not find till now.

thank you for clarifying.

Your welcome.

And to add for MRA how media is carried-out:

[CUCM]<--best-effort-->[Expressway-C]<--mandatory-->[Expressway-E]<--mandatory-->[Endpoint]

MRA deployment uses Mandatory Media Encryption wherein Media encryption is required. Unencrypted calls should always fail; no fallback is allowed. CUCM and Expressway are consistent in signaling for this case. 

CUCM and Expressway both use m=RTP/SAVP in order to describe the media in the SDP. The SDP has crypto attributes (a=crypto...lines in the media sections of the SDP).

If the call goes MRA type to CUCM, then CUCM expects to see the x-cisco-srtp-fallback header if the media encryption is optional. If CUCM does not see this header, it considers the call to be encryption-mandatory. 

 

regards,

Acevirgil