CUBE, SIPS & non-secure phones

[Gordon Ross]

I've got a CUBE (IOS-XE 17) & CUCM (12.5) connected via a secure SIP trunk.

Calls to/from the SIP trunk from/to a phone with a secure Device Security Profile work fine. But calls to/from a phone with an insecure Device Security Profile fail. (Calls between secure & unsecure phones work fine too)

What do I need to do to allow this secure SIP trunk to talk to an unsecure phone?

[Adam Pawlowski]

I’ve just set this up myself recently in the lab so I am no pro - however if you configure srtp, the command to enable I believe needs to be “srtp fallback” otherwise it will not allow it. 

[Adam Pawlowski]

I tested the configuration, it is "srtp fallback" which can be applied at the sip service level globally or at the peer. The caution is that "no srtp fallback" seems to become "no srtp" in the configuration which is not what you want, and srtp by itself doesn't allow fallback.

That should work as long as it is allowed on all the other applicable parts to allow non secured call to traverse the trunk or complete.

[Gordon Ross]

I've tried the "srtp fallback"option but a 7941 with an unsecure profile can't answer the call. A 7811 with a secure profile can answer the call (and I get the padlock symbol)

[Adam Pawlowski]

 Hi Gordon,

I apologize I'm not an expert in this area, I based testing on a secured 8841 and non-secured Jabber client, and followed these instructions for configuration:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/srtp-rtp-interworking.html

If the CUBE is connected out via secure SIP trunk to another ITSP or destination that supports secure trunk, the scenario should be the interworking scenario indicated there, which, it appears that "srtp" on the secured peers is required, and "srtp fallback" on the peers which could possibly have RTP, would be the configuration.

If the call is presented then signaling works, and assuming we didn't get into a codec debacle here, what I ended up having to do next was grab SIP debugs to see what's being offered/presented, and see if there's a reason or something else coming from the UCM if it's dropping the call when the 7941 answers. I didn't have any trouble with non-secure calls, though I will be doing more testing going through this, it was the secure calls that were an issue to get setup.

Again pretend I know nothing, if I were also picking a troubleshooting point, in a scenario where there are two SIP trunks to the CUBE, one secure one not, I would look to see if there's some other configuration that would prevent the CUBE from inserting itself in the middle to interwork the media. If it's flowing through then it would likely fail should the 'secure' end itself not support negotiating back to RTP. I live in an archaic land of ISDN PRI yet so we have not tackled that.

E:

One other thing, and this was a bit back, when fallback wasn't enabled the CUBE would be sending its messaging as "sips" instead of "sip" which the UCM would reply back with a 488 not acceptable.