This issue is a bit niche, but it will serve to remind me the next time I come across it.
Recently I needed to connect a few Ribbon SWe-Lite SBCs to a SIP service provider over the internet using encryption. Connectivity was fine and inbound calls from the service provider were successfully routed and connected.
However, placing outbound calls to the service provider from the SBC failed with a 481 – Not Acceptable Here response.
After going through the usual troubleshooting steps such as blaming the security person and the firewall :), the problem seemed to be more down to the configuration supported by the provider.
Looking through an incoming INVITE from the provider, the crypto suite offered in SDP looked to be an acceptable match on the SBC, but I noticed that they didn’t send the key lifetime in the initial crypto offer.
You can find out if the lifetime is present in the a=crypto line in SDP at the end of the salt and after the first | break, as follows:
On INVITES initiated from the SBC to the provider I was sending the lifetime in SDP to them.
Logic dictates that I should try to remove that and try again and SUCCESS! Outbound calling is now working!
How to remove this on a Ribbon SWe-Lite
To remove the lifetime from being sent in SDP, go to the SDES profile attached to the media list for the trunk and set the Key Identifier Length to 0.
Now, when outbound calls are sent, the crypto includes just the algorithm and the salt needed to validate the encryption
Potential Bug?
Even though this resolved the issue, is did observe another behaviour that continued after this change (and probably was there before). I am not sure if it is a bug with the Ribbon code or not.
However, on response to inbound INVITES the SBC sends a 200 OK with SDP. Inside that response, the crypto line includes the key lifetime, even though the profile is set to not!
To remove that required a SIP Message Manipulation Rule applied to the outbound rules on the service provider Signaling Group
The create a Raw Message Rule
Use Match Regex: (a=crypto:(.*))\|(.*)
Replace: \1
Then apply that message table to the outbound rules on the Service provider signalling group
Now the 200OK with SDP response looks consistent
Calls were working in both directions even without this rule in place, so the impact of this seems to be a non-event, but at least it makes it easier to troubleshoot other issues when your call flows are consistently presented.
