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.

Background

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.

Supported platforms

The SIP RA’s SCTP implementation requires Java Standard Edition 11, 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.

Tip See SCTP - Getting Started for more information.

The SIP RA’s SCTP support uses the Java SCTP API, via the Netty library.

Using SCTP in your SIP applications

Below are instructions to configure the SIP RA, and send requests, and responses over SCTP.

Configure the SIP RA

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-console:

[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 IPAddress and Port properties.

The SIP RA is now ready to send and receive SIP messages using SCTP.

Multi-homing

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 IPAddress and SCTP:additional_addresses configuration properties.

  • The IPAddress property defines the "primary" address. The RA will bind to this address first.

  • The SCTP:additional_addresses property may contain one or more addresses, separated by commas or whitespace. The RA will attempt to bind to these addresses, after first binding to IPAddress.

  • If unable to bind to any one of these addresses, RA activation will fail, and a SLEE alarm will be raised.

Note If IPAddress is a wildcard address then all additional addresses will be ignored. Wildcard addresses in SCTP:additional_addresses are also ignored.

Send requests over SCTP

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.

Set the target URI’s "transport" parameter

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");

Use NAPTR and SRV DNS records as per RFC3263

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:bob@example.com, 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.

Send responses over SCTP

Tip Nothing special needs to be done for responses; they are always sent on the same transport that the request arrived on.
Previous page Next page