cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1094
Views
1
Helpful
4
Replies

CUBE - SIP trunk and Cause 65 Bearer capability not implemented

autresrhumbs1
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

TechLvr
Spotlight
Spotlight

@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. 

View solution in original post

4 Replies 4

TechLvr
Spotlight
Spotlight

@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. 

b.winter
VIP
VIP

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.

autresrhumbs1
Level 1
Level 1

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!

Hi,

For every SIP communication problem you have in the future, "debug ccsip messages" is the one for you to start with.