I have been trying to get SRTP media encryption to work on my SIP trunk connecting my Avaya Aura CM 6.0 to an ACME Packet Session Boarder Controller (SBC) managed by another agency. They configured the connection on the SBC red side as transparent to allow the CM to do the encryption. I've set my system-parameters customer-options page 4 Media Encryption Over IP to Y, IP Trunks to Y, system-parameters features page 19 Direct IP-IP Audio Connections to Y, SDP Capability Negotiation for SRTP to Y, my ip-codec-sets using G.711, G.711MU Media Encryption to 1: 1-srtp-aescm128-hmac80, 2: 2-srtp-aescm128-hmac32, 3: none. I can see my test calls seize the SIP trunk member, and hear ringing from the other end, the other end hears the rings, but when pickup no audio. Call traces show the calls going out and being received at the other end. Is there anything else I should be looking for. This is my first time doing this so any guidance would help. Thank you.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Enabling SRTP on Avaya Aura CM on 6.0
- Thread starter avi777
- Start date
CM6-->ACME-->?
Is that the PSTN?
If so, why does it matter if you're unencrypted inside your network?
If the untrusted side of the Oracle/ACME is a private trunk that you want encrypted, then the Oracle can do that on its own without changing anything on CM.
Are you end to end TLS? On newer CMs, you have to be end to end TLS to do encrypted media because the media decryption keys are exchanged in SIP signaling. It's not secure to have CM-->SM be TLS and SM-->Oracle be TCP and carry the SRTP keys on the TCP leg. Maybe the Oracle is rejecting that.
What does an RTP trace on those calls show?
You should see CM user-->Oracle and Oracle-->CM User and on the other side, Oracle-->Other Guy and Other Guy-->Oracle
Is that the PSTN?
If so, why does it matter if you're unencrypted inside your network?
If the untrusted side of the Oracle/ACME is a private trunk that you want encrypted, then the Oracle can do that on its own without changing anything on CM.
Are you end to end TLS? On newer CMs, you have to be end to end TLS to do encrypted media because the media decryption keys are exchanged in SIP signaling. It's not secure to have CM-->SM be TLS and SM-->Oracle be TCP and carry the SRTP keys on the TCP leg. Maybe the Oracle is rejecting that.
What does an RTP trace on those calls show?
You should see CM user-->Oracle and Oracle-->CM User and on the other side, Oracle-->Other Guy and Other Guy-->Oracle
- Thread starter
- #4
The SBC is my gateway to government telephone network and my Avaya CM is not encrypting with them but with softswitch at other end of the SBC network. The SBCs are basically set to transparent to allow my CM to do the encryption instead of the SBC. It's a government requirement that the CM be doing the encryption.
So the signaling path should be:
CM-->SM-->Oracle-->Softswitch
And the SRTP path should be CM Endpoint-->Softswitch Endpoint
Correct?
If you have SIP phones, their encryption options are defined by the settings file. If you're direct audio all the way across, then the CM and Softswitch endpoints might be actual phones or media gateways.
The encryption keys will be exchanged in the SIP signaling and if there's any TCP and SIPS URIs you might get in trouble.
See
Are you sending SRTP to a fixed media resource on that softswitch? 1 or 2 IPs always?
Are you sending SRTP direct to endpoints?
Are those endpoints in the same subnets as the Avaya phones?
If they're in a different network, I'd add those IPs to the network map as belonging to the Softswitch IP phones network with a network region.
Do you have procr in its own region with no DSPs and every other region is direct to procr while being indirect to each other through procr?
If so, I'd make the softswitch region direct to a region with only gateways and reach procr through that region.
I'd use that same region in the sig group for far end network region - that will define the codecs used in setup.
I'd also forbid inter/intra region audio from that softswitch region to your DSPs.
You'll want to see the media offer now be from CM to SM to Oracle advertising the media gateway IP in the c=line and the port in the m=audio line.
Presuming it works with TCP today, it shouldn't be a RTP ports issue, but hey, check that too.
And then you can enable rtp debugging on the G450... I can't remember exactly how right now
But you can show rtp something summary or whatever and the G450 will provide stats on streams it's supposed to be receiving.
And you'll know from where it should be receiving based on the SDP you get back from Oracle.
And you'll know what the encryption keys being offered back to you are. You can encrypt your media to them and tell them in signaling how to decrypt it, but they have to return the favor in kind.
Do you have access to an end to end signaling trace from both sides?
Something like the method above would allow you to either port mirror and wireshark on the gateway or use the rtp debugging on the G450 to see if you're even getting anything.
CM-->SM-->Oracle-->Softswitch
And the SRTP path should be CM Endpoint-->Softswitch Endpoint
Correct?
If you have SIP phones, their encryption options are defined by the settings file. If you're direct audio all the way across, then the CM and Softswitch endpoints might be actual phones or media gateways.
The encryption keys will be exchanged in the SIP signaling and if there's any TCP and SIPS URIs you might get in trouble.
See
Are you sending SRTP to a fixed media resource on that softswitch? 1 or 2 IPs always?
Are you sending SRTP direct to endpoints?
Are those endpoints in the same subnets as the Avaya phones?
If they're in a different network, I'd add those IPs to the network map as belonging to the Softswitch IP phones network with a network region.
Do you have procr in its own region with no DSPs and every other region is direct to procr while being indirect to each other through procr?
If so, I'd make the softswitch region direct to a region with only gateways and reach procr through that region.
I'd use that same region in the sig group for far end network region - that will define the codecs used in setup.
I'd also forbid inter/intra region audio from that softswitch region to your DSPs.
You'll want to see the media offer now be from CM to SM to Oracle advertising the media gateway IP in the c=line and the port in the m=audio line.
Presuming it works with TCP today, it shouldn't be a RTP ports issue, but hey, check that too.
And then you can enable rtp debugging on the G450... I can't remember exactly how right now
But you can show rtp something summary or whatever and the G450 will provide stats on streams it's supposed to be receiving.
And you'll know from where it should be receiving based on the SDP you get back from Oracle.
And you'll know what the encryption keys being offered back to you are. You can encrypt your media to them and tell them in signaling how to decrypt it, but they have to return the favor in kind.
Do you have access to an end to end signaling trace from both sides?
Something like the method above would allow you to either port mirror and wireshark on the gateway or use the rtp debugging on the G450 to see if you're even getting anything.
- Status
Similar threads
- Question