CME SIP trunk with sccp ephones and SRTP

[lourens mouton]

HI world.

I am currently struggling configuring a CME 8.6 talking to MS Office 365.

From a FXS port all works.

The challange is that when the sccp 7940 making a call to MS, the CME send the SDP with when sending the SIP INVITE with a standard RTP parameter.

Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 268

v=0
o=CiscoSystemsSIP-GW-UserAgent 7961 9044 IN IP4 x.x.x.x
s=SIP Call
c=IN IP4 x.x.x.x

t=0 0
m=audio 17558 RTP/AVP 0 101
c=IN IP4 x.x.x.x
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=direction:passive

The FXS port is properly encrypted and the SDP go out with SRTP.

m=audio 63882 RTP/SAVP 0 101

c=IN IP4 y.y.y.y.62

dspfarm profile 1 transcode universal security

trustpoint godaddy.int.sec

codec g729r8

codec g711ulaw

codec g711alaw

codec g729ar8

codec g729abr8

maximum sessions 2

associate application SCCP

dial-peer voice 1000 voip

description Office365

destination-pattern 812....

session protocol sipv2

session target dns:xxxx.um.outlook.com:5061

session transport tcp tls

incoming called-number .

voice-class sip url sips

dtmf-relay rtp-nte sip-notify

srtp fallback

codec g711ulaw

no vad

m=audio 63882 RTP/SAVP 0 101
c=IN IP4 y.y.y.y                        

I have a transcoder registered againsts the CME to support SRTP.

dspfarm profile 1 transcode universal security
trustpoint godaddy.int.sec
codec g729r8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 2
associate application SCCP

This is associated with the telephony services as a sdspfarm.

dial-peer voice 1000 voip
description Office365
destination-pattern 812....
session protocol sipv2
session target dns:XXX.um.outlook.com:5061
session transport tcp tls
incoming called-number .
voice-class sip url sips
dtmf-relay rtp-nte sip-notify
srtp

codec g711ulaw
no vad

Is it possible for CME to transcode the RTP stream from the 7940 to SRTP goining out the SIP trunk.

Currently it seems that the CME is simply copying the RTP from the 7940 straight into the SIP Invite, skipping the transcoding first.

I look forward to the man that can answer this one.

Lourens

[Akhil Behl]

Hi Lourens,

From what I know (and if this hasn't changed in recent past) CUCME doesn't support secure (SRTP, TLS) over SIP Trunk

http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeauth.html#wp1043585

If you do not wish to use H.323 trunks, as a workaround, you can use unencrypted SIP communication and an IPSec tunnel from CUCME to headend. This may not be very pretty or scalable but it works.

For more info on various ways in which you can safeguard signaling and media in your UC network, refer to Securing Cisco IP Telephony Networks

Regards,

Akhil Behl
Solutions Architect
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

[lourens mouton]

Hi Akbehl.

Microsoft support only SIP TLS with SRTP.

It certainly works 100% in my setup if I have FXS or ISDN to CME and then SIP/TLS to Microsoft.

ANA --> FXS port ---> CME ---> SIP/TLS/SRTP ---> Microsoft. Works

SCCP phone registered onto CME1 --> E1 Crossover ---> CME2 ---> SIP/TLS/SRTP ---> Microsoft. Works

SCCP phone registered onto CME1 --> SIP ---> CME2 ---> SIP/TLS/SRTP ---> Microsoft. Works  (CUBE)

SCCP phone registered onto CME ----> SIP/TLS/SRTP ---> Microsoft.    FAIL.

The latter fail as CME is passing the RTP stream SDP straight through and not hairpinning it on the CME to encrypt.

The problem seem that CME does not support the encryption of the RTP stream from an handset when leaving out to a SIPTLS dialpeer.

So, it does support SIP-TLS with SRTP over a trunk, just not SRTP coming from the SCCP handset.

My question is, is this on the roadmap?

[Akhil Behl]

Lourens,

It may work in certain setup however, it is not officially supported by Cisco BU or TAC as it stands today. Scenario 2 with CUBE is a realistic realization since, CUBE does support it. In either case 1 or 2 you're using CME as IP IP GW.

With that said, I can only say this could be supported in near future although I haven't seen this on the roadmap, yet.

Regards,

Akhil Behl
Solutions Architect
akbehl@cisco.com

Author of “Securing Cisco IP Telephony Networks”
http://www.ciscopress.com/title/1587142953

[ADAM CRISP]

Hi,

I looked at this type of issue a few years ago when we started offering TLS/SRTP SIP trunks.

The trick is to force calls via the tranacoder, which you can do by looping calls via a few dial peers. You need to understand number translation profiles . Here's an example

1. Create a lookback interface and give it a locally significant IP address

2. Create an outbound H323 dial-peer that outbound calls will always select and make the destination IP address your new loopback IP. When calls leave the outbound dial-peer use number translation profiles to pre-fix the call with a couple of letters - eg 812123456 will become AAA812123456

3. create an inbound dial-peer that has an incoming called number field that matches your prefx - eg ^AAA.+

At this point your SCCP call will "leave" the router as H323 - arrive again as H323

i.e. SCCP-> H323 -> H323

4. amend your SIP outbound dial-peer for MSLync - to have a destination-pattern with your prefix - eg ^AAA812.+

5. make sure you have H323 to SIP enabled on your router.

Calls will now make use of your securing transcoder and you're good to go.

I don't rememeber inbound calls being a problem  - but if they are you could do something similar in reverse.

Adam

[lourens mouton]

Hi Adam,

Sorry for the delay in response.

I have tried this and allthough this works, it shoots the ISR's CPU utilisation up to 90 %.

We ended using a Ingate Siperator to achieve the desired solution for now until Cisco has a solution to force traffic through a secure transcoder.