Recently, one of my customers encountered a problem when connecting his CUCM to a telephony provider (ITSP) via a SIP trunk. Between the CUCM and the ITSP, a CUBE gateway was installed, as expected. The problem was the following: when making an outgoing call to the ITSP, CUBE sent a SIP INVITE, however, the provider did not respond to this request in any way, and no response messages were received from it. I described the solution of this issue on my personal blog here at https://dbenda.blogspot.com/2022/04/soure-port-5060-cisco-cube-sip.html but I also want to share this solution at Cisco Community.
Of course, the first thing to do in such a situation is to check which transport layer protocol (TCP or UDP) is configured on the gateway. However, in this case, the ITSP requested SIP messages to be sent with UDP transport, but Cisco gateways by default send all SIP messages with UDP, i.e. this was not the cause of the problem (you can control it with debug ccsip messages command). After talking with the provider's engineer, it was found out that they expect communication to the SIP gateway with the Destination Port = 5060, but they would also like to see Source Port as 5060 as well.
Typically, the Cisco Gateway selects the Source Port dynamically. Below is an example configuration for a gateway that solves this problem. There is one interesting command that sets Source Port = 5060
(config)# sip-ua
(config-sip-ua)# connection-reuse via-port
The connection-reuse via-port command, entered in the sip-ua configuration mode, just tells the gateway to select Source Port = 5060. After changing the CUBE configuration, calls began to work normally, as required.
It is possible that you will also encounter such a problem, and this solution will be useful for you too.
