The SIP RA supports SCTP (RFC 4960) as a SIP transport, in addition to UDP, TCP, and TLS
SIP’s usage of SCTP is specified by RFC 4168, which the SIP RA adheres to. This page covers how to configure and use SCTP in your SIP RA applications.
Stream Control Transmission Protocol (SCTP)) is a transport protocol designed for call-control signaling . Like TCP, it provides reliable, ordered, end-to-end delivery of messages, but has many features that make it better than TCP for some applications. The main benefits of using SCTP for SIP are:
No "head of line" blocking: SIP SCTP messages are sent and received independently over the same association. A delay in routing or processing one message does not affect other messages. In contrast, TCP has to ensure that all bytes on a connection are processed sequentially, so delays processing earlier messages will hold up later messages.
Multi-homing: An SCTP association (connection) can be bound to multiple interfaces on a host. This means that associations can survive interface or network failures with no application involvement.
The SIP RA follows RFC 4168 when sending and receiving messages:
All SIP messages are expected to use a Payload Protocol Identifier of 0. The SIP RA ignores messages with a different PPID.
By default, the SIP RA sends messages on stream number 0 using unordered delivery. This avoids the "head of line" blocking issue.
If a request arrives on another stream, the SIP RA will accept it and send any responses on the same stream.
The SIP RA’s SCTP implementation requires Java Standard Edition 7, running on Linux 2.6 or Solaris 10 (or later versions of the same).
In addition, on Linux the
lksctp-tools package must be installed.
|See SCTP - Getting Started for more information.|
Before using SCTP, it must be enabled in the SIP RA.
To enable it, just add
SCTP to the RA’s "Transports" configuration property, along with TCP, UDP, or TLS.
For example, in
[Rhino@localhost (#0)] updateraentityconfigproperties sipra Transports TCP,UDP,SCTP [Rhino@localhost (#1)] deactivateraentity sipra [Rhino@localhost (#2)] activateraentity sipra
When the SIP RA is activated, it will start an SCTP server listening on the address given by the
The SIP RA is now ready to send and receive SIP messages using SCTP.
SCTP multi-homing is automatically used if
IPAddress is "AUTO" or a wildcard address such as "0.0.0.0".
In these cases the RA binds to all of the host’s interfaces, and these addresses are advertised to SCTP peers during association setup.
SCTP peers automatically probe these addresses to discover which ones are reachable.
SCTP multi-homing can also be restricted to use specific addresses.
These addresses must be configured in the RA’s
SCTP:additional_addresses configuration properties.
IPAddressproperty defines the "primary" address. The RA will bind to this address first.
SCTP:additional_addressesproperty may contain one or more addresses, separated by commas or whitespace. The RA will attempt to bind to these addresses, after first binding to
If unable to bind to any one of these addresses, RA activation will fail, and a SLEE alarm will be raised.
When sending a request, the SIP RA determines the transport protocol using the RFC3263 process. There are several ways to ensure that this process selects the SCTP transport for a request. These include setting the target URI’s "transport" parameter and using NAPTR and SRV DNS records as per RFC 3263.
The target URI is the URI from the first
Route header, if present, or the Request-URI.
Setting the URI’s
transport parameter to "sctp" will force the RA to use SCTP to send the request.
In the JAIN SIP API this would be done as follows:
Request invite = messageFactory.createRequest(...); SipURI requestURI = (SipURI) invite.getRequestURI(); requestURI.setTransportParam("sctp");
If the request’s target URI does not specify a transport, then the RA must lookup the NAPTR record for the URI’s host.
For example, if the URI was
sip:firstname.lastname@example.org, the RA would query the "example.com" domain for any NAPTR records.
These specify the preferred SIP transports for the domain. For example:
; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIP+D2S" "" _sip._sctp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com.
Here the preferred record (lowest order value) specifies the SCTP transport (with the
SIP+D2S service key),
and says the client should then lookup the SRV record
_sip._sctp.example.com to get the port and IP addresses to use.
The SIP RA does this automatically.
By configuring DNS appropriately for your domain as per RFC 3263, you can ensure that requests sent to
public addresses like
sip:host.yourdomain.com will automatically use SCTP or any other protocol.