Customer is establishing SIP trunking service with a carrier who is wanting to use port 5100 for the SIP connections between the customer SBC and the carrier SBC. While I can make this work, I have noticed that NONE of the SIP messaging on the non standard sip port is visible using the standard CCSIP debugs.
Is there any way to tweak the debugs so that these traces can be seen? I'm not certain the carrier is going to be willing to change to port 5060, and debugging by having to run packet captures is going to be a real pain.
Did you modify the SIP listen port on CUBE itself or merely the dial-peer’s session target? If the latter I have seen that work fine with debugs in the past (eg using multiple trunks to CUCM on different ports).
I ran into an issue over the weekend when testing IOS 15.6 and 15.7 on my CUCME. Debug ccsip messages did not show any debugs. To monitor the debug I was using term monitor as well as logging buffered debug. In one case, there were no debugs at all and in the other case there were only debugs in the "show log". Not sure if this is your problem or not but worth a mention.
How is your CUBE set up? Does it register with the remote SBC or does it just send SIP INVITE? Are you seeing this issue in outbound calls or inbound? (or both)?
Does remote SBC expect your customer SIP source port to also be 5100? (so basically from customer to ITSP SBC has source and destination of x.x.x.x:5100 <-> x.x.x.x:5100)
As a workaround, might be able to NAT the SIP signalling traffic to the desired port, keeing the customer CUBE on 5060.
We have to register and authenticate. I do not specifically do anything to change the source port (I'm not even sure how I would do that).
Interestingly, we found that debug ccsip all does show the registration messages in the log, and like you I found that the messages do appear in the log, though strangely not on the terminal via term mon.