The article explains various methods of controlling transport protocols for SIP signaling and how these work together. 


In this section:


Related articles:

At the SIP Signaling Port Level

The "Transport Protocols Allowed" setting at the SIP Signaling Port level controls which transport protocol(s) the SIP signaling port supportS (UDP, TCP, TLS, SCTP). In other words, it defines the listeners that the SBC opens for the SIP signaling port's IP address. Usually, multiple SIP peers utilize the same SIP signaling port, and at the same time each of these peers prefer a different transport protocol for SIP. You can control this at the SIP Trunk Group and IP Signaling Profile (IPSP) levels.

At the IP Signaling Profile Level

The IPSP → Egress IP Attributes → transport (type1 to type4) feature controls the selection of the transport protocol for outgoing calls only; it has no effect on incoming calls.

Note that although one can define up to four transport types, the SBC only uses the first one. The SBC doesn't do any fallback if the call over the type1 transport choice fails. If no transport types are defined at this level, the Transport Preference selection at the SIP trunk group level comes into play.

At the SIP Trunk Group Level

The "Transport Preference" at the SIP Trunk Group level controls the transport protocol selection for outgoing calls only if no transport type is defined at the IPSP level. Only preference1 plays a role; the SBC doesn't do any kind of fallback to preference2 or preference3 or preference4 in case the call over preference1 transport protocol fails.

For incoming SIP traffic, the Transport Preference setting acts as a filter. The SBC accepts calls that come over a transport protocol listed in the Transport Preference preference1-preference4. Calls coming over a transport protocol not defined by the Transport Preference are rejected with a SIP 488 response.

Outgoing Transport Protocol Derived From a NAPTR DNS Response

You can configure the SBC to determine the transport protocol for outgoing SIP calls from a NAPTR DNS response. The NAPTR DNS response contains one or more SRV records, each with a different transport protocol type. Because the SBC uses the SRV record with the lowest preference number, it uses the protocol of this SRV record as the outgoing transport type. The SBC cannot fall back to the other transport type defined by the record(s) with the higher preference if the call over the transport type selected from the lowest preference number SRV record fails.

Note

For outgoing calls, if the transport protocol chosen at the TG/IPSP/DNS level is not defined at the SIP Signaling Port level in the "Transport Protocols Allowed" setting, the SBC clears the call attempt with a SIP 404 response as there is no socket listener to serve the request.

Defining Transport Protocols for Pathcheck Profiles

Although the Pathcheck profile includes four transportPreference objects (preference1-preference4), the SBC uses just one of these, and it does not fall back to lower preference transport types if the pathcheck fails for the selected transport protocol.

The SBC starts the pathcheck SIP OPTIONS ping over a transport protocol defined in preference2-preference4 only if the SIP signaling port does not have the pathcheck's preference1 transport protocol defined in its transportProtocolsAllowed list.