01-23-2023 09:59 AM
Hello,
We have a setup where a Cisco CUBE SBC is set between two IPBX, each one connected to the Cisco CUBE with a sip trunk.
Everything works except when one IPBX sends an INVITE with a SDP payload containing a media port set to 0 for RTP.
Looking at SIP RFCs, it looks like this was used in the past to let know the other party that it should not send any RTP for this call. At least until we get a RE-INVITE...
The Cisco SBC does not accept this INVITE and sends back a SIP 488 Not acceptable here with a "Cause 65 Bearer capability not implemented".
Is it possible to let the Cisco SBC accept this port set to 0?
Many thanks for your help.
Solved! Go to Solution.
01-23-2023 10:55 AM - edited 01-23-2023 10:56 AM
@autresrhumbs1 Try the following command and see if that makes a difference.
voice service voip
sip
pass-thru content sdp
This command (pass-thru content sdp) instructs the CUBE to pass the sdp content to the final destination without inspecting it.
After the above change, if the destination PBX also sends a SIP 488 Not acceptable, then try to configure the source PBX to send a delayed offer with no SDP.
01-23-2023 10:55 AM - edited 01-23-2023 10:56 AM
@autresrhumbs1 Try the following command and see if that makes a difference.
voice service voip
sip
pass-thru content sdp
This command (pass-thru content sdp) instructs the CUBE to pass the sdp content to the final destination without inspecting it.
After the above change, if the destination PBX also sends a SIP 488 Not acceptable, then try to configure the source PBX to send a delayed offer with no SDP.
01-24-2023 12:58 AM
Are you sure, that this is the root problem?
As you said yourself, RTP with 0 is normal. This happens for example, if the CUCM phone buts the external caller on hold, then CUCM will update the SIP session and you would see a message from CUCM to CUBE with RTP port 0.
But without any logs from your side, it's hard to tell.
01-25-2023 04:33 AM
Many thanks @TechLvr, after setting the "pass-thru content sdp" in the sip section, the call was then forwarded to the final destination.
@b.winter, unfortunately, I will not be able to investigate this in the following days, but next time i will have a deeper look because you are probably right: I don't see why the CUBE does not accept this INVITE.
Since I am not an expert on Cisco CUBE, is there any specific command to activate logs that would help me understand why the CUBE does not accept this RTP port set to 0?
Thanks!
01-25-2023 04:37 AM
Hi,
For every SIP communication problem you have in the future, "debug ccsip messages" is the one for you to start with.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide