SRTP on VG320

[Richard Simmons]

Hello,

I need to integrate VG320's into a cloud hosted SBCaaS - I've got this working via a TLS SIP Trunk, however, the calls are not encrypted. I have tried enabling SRTP on the dail-peers but the calls fail with SRTP enabled;

dial-peer voice 99 voip
description *** inbound from SBCaaS ***
session protocol sipv2
session transport tcp
incoming called-number .
voice-class codec 1
  voice-class sip srtp-auth sha1-80
voice-class sip profiles 200
voice-class sip block 183 sdp present
voice-class sip pass-thru headers 290
dtmf-relay rtp-nte
srtp 
no vad

I see this in the SIP messages;

SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/TLS 20.197.211.71:5067;branch=z9hG4bK00B8d624af0885c8915
From: <sip:REDACTED@SBCaaS.com>;tag=gK001cfa64
To: <sip:REDACTED@CiscoVG320.com>;tag=DA802448-2344
Date: Thu, 10 Aug 2023 12:03:07 GMT
Call-ID: 471868364_125152269@20.197.211.71
CSeq: 512951 INVITE
Allow-Events: telephone-event
Warning: 399 10.80.161.79 "Cannot fallback to RTP. SRTP configured on dialpeer"
Reason: Q.850;cause=65
Server: Cisco-SIPGateway/IOS-15.9.3.M7
Session-ID: a952d0682b125bafb9a217f869075824;remote=c997555d0e855347bfb9a93b3a5a238b
Content-Length: 0

If I enable 'SRTP Fallback' on the dial-peer then the calls connect correctly.

Is there something I need to do with the DSP's to enable this functionality?

Thanks,

Richard

[b.winter]

Why are people always posting only small pieces of information?!

Why aren't you posting the debug logs of the full call? What should anybody do with just one SIP message?!
And why aren't you posting the full config?

[Richard Simmons]

Thanks for getting back to me, I thought I had posted the pertinent information here; I can post a full call flow, which in this case is just an Invite followed by the 488 reply above.

I've not posted the full config as it's quite a hassle to redact the customer-identifiable / specific items.

[b.winter]

Even if the call logs only included 2 messages, without the full context, a single message is helpless.
So please post the config and the full debug.

And if I'm not wrong, VGs need to have a PVDM for sRTP, like the old ISR 2k router.

According to your OP, calls with "SRTP fallback enable" work, because the audio is RTP only probably. Maybe the other side doesn't want RTP at all. But again, without a full debug it is just glass ball reading ...

[Richard Simmons]

Here's the call flow; will work on the config too;

Received:
INVITE sip:number@Cisco_VG320 SIP/2.0
Via: SIP/2.0/TLS SBCaaS:5067;branch=z9hG4bK00B8d610ea2ddde7c88
From: <sip:number@SBCaaS>;tag=gK001cf8d1
To: <sip:number@Cisco_VG320>
Call-ID: 471868363_98494632@SBCaaS
CSeq: 919736 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH,X-MS-Location
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:number@SBCaaS:5067;transport=tls>
P-Preferred-Identity: <sip:number@SBCaaS:5067>
User-Agent: Ribbon SBCvirtualCloud V09.02.04R000
X-MS-SBC: Ribbon SBCvirtualCloud V09.02.04R000
Supported: timer,100rel,precondition,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 250
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 499322 67213 IN IP4 SBCaaS
s=SIP Media Capabilities
c=IN IP4 SBCaaS
t=0 0
m=audio 15446 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=rtcp:15447

Aug 10 12:03:06 UTC: //353787/B3615304A80E/SIP/Msg/ccsipDisplayMsg:
Sent:
ae07sc2101#SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/TLS SBCaaS:5067;branch=z9hG4bK00B8d610ea2ddde7c88
From: <sip:number@SBCaaS>;tag=gK001cf8d1
To: <sip:number@Cisco_VG320>;tag=DA802090-10A7
Date: Thu, 10 Aug 2023 12:03:06 GMT
Call-ID: 471868363_98494632@SBCaaS
CSeq: 919736 INVITE
Allow-Events: telephone-event
Warning: 399 10.80.161.79 "Cannot fallback to RTP. SRTP configured on dialpeer"
Reason: Q.850;cause=65
Server: Cisco-SIPGateway/IOS-15.9.3.M7
Session-ID: b1cb7b995faf5cf188bb3d1b60c844ac;remote=5c0a313ea93b550ab75464b265ad15ba
Content-Length: 0

[b.winter · Accepted solution]

The SBC doesn't do sRTP, that's why the calls fail, if "SRTP fallback" is not configured.
Because this command forces the VG to use SRTP, but if the other side (in your case the SBCaaS) doesn't do sRTP, the call will fail.

The SBC does encrypted signalling (SIP over TLS), but not encrypted RTP.

[Richard Simmons]

Thanks for your help, indeed, the SBCaaS was not offering SRTP, that was updated and it's now working as expected; SIP Invite for reference;

Received:
INVITE sip:number@Cisco_VG320:5061 SIP/2.0
Via: SIP/2.0/TLS 20.197.211.71:5067;branch=z9hG4bK00B682d0935b7568238
From: <sip:number@SBCaaS>;tag=gK007361dd
To: <sip:number@Cisco_VG320>
Call-ID: 471871653_94608881@20.197.211.71
CSeq: 390274 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH,X-MS-Location
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:number@SBCaaS:5067;transport=tls>
P-Preferred-Identity: <sip:number@SBCaaS:5067>
User-Agent: Ribbon SBCvirtualCloud V09.02.04R000
X-MS-SBC: Ribbon SBCvirtualCloud V09.02.04R000
Supported: timer,100rel,precondition,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 340
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 37546 852134 IN IP4 SBCaaS
s=SIP Media Capabilities
c=IN IP4 SBCaaS
t=0 0
m=audio 23540 RTP/SAVP 0 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:LiVLGyd4ACN50TqXNEGtoegD+6G/FbuB6EY7MWXu|2^31
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=rtcp:23541