SIP in Yate

Revision as of 13:23, 8 November 2012

This page describes the implementation of SIP protocol in Yate

Yate Server as a SIP - B2BUA

Yate is a back-to-back user agent (B2BUA). This is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests to destination end, handling the signalling between end points back-to-back.

Yate is not a Proxy Server, he does much more than that:

• maintains a complete state for the calls
• handles automatic call disconnection or call transfer
• conceals the caller identity
• generate requests of their own and also final responses
• can provide NAT traversal solution
• can interwork with different networks
• can overwrite and modify the SIP headers like Contact, Via, Route.

Yate implements SIP protocol that runs over User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), but not over Stream Control Transmission Protocol (SCTP).

Yate can act as a SIP Server as you can see in the image below and also you can configure Yate to be a SIP Client.

The flow for this messages is similar to the HTTP request/response transaction model.

A transaction occurs between a user agent client (UAC) and a user agent server(UAS), and comprises all messages from the initial request to the final response.

The first line tells us that this is INVITE request which is used to establish a session.

The responses can be provisional, starting with 1 followed by two digits (for example, "180 Ringing") or final starting with 2 followed by two digits (for example, "200 Ok").

The scope of a transaction is defined by the stack of the Via headers of the SIP request.

After 100 Trying response is sent, if no request arrives to Caller then Yate will send a copy of the first INVITE, this is called retransmission and the flow of the messages will continue. A dialog is established, such as INVITE to an request a 2xx response - the action was successfully received, understood, and accepted.

As you can see in the image, the RTP can pass directly from caller to the callee once the transaction is established, or the RTP can go through Yate and Yate will send the SDP to the callee.

How to configure SIP in Yate

This are the configuration files for SIP:

• ysipchan.conf the main file for configuring SIP methods
• sipfeatures.conf configures some SIP features
• sip_cnam_lnp.conf controls how CNAM and LNP queries are performed

For configuring users, gateways no matter the protocol used, other files are used as regfile.conf or regexroute.conf.

Using the default configuration from ysipchan.conf file, Yate will behave as a SIP server, that will listen on all interfaces or you can configure your own listeners. In Yate you can build UDP, TCP, TLS listeners.

More infomations about SIP Routing in Yate.

SIP with NAT in Yate

Historically there have been problems with SIP when passing through NAT. This is not a SIP problem, but the RTP problem. SIP announces the RTP address and port, but if the client is behind NAT, it announces the client's RTP port, which can be different from the port the NAT allocates externally. The solution is to use a SIP Session Border Controller.

In [general] section from file ysipchan.conf the nat setting will try to replace nonroutable IP addresses of the RTP media stream with the address the SIP signalling was received from. This significantly improves chances that clients behind a dumb NAT get normal voice. This option is enabled by default. For changing it's value, remove character ';'.

If a gateway is created for SIP in accfile.conf there are some parameters for NAT:

• localaddress: Local address to set in sent messages

- Set it to 'yes' to detect NAT and re-register with public ip when NAT is detected

- Set it to 'no' or ipaddress (e.g. 1.2.3.4 or 1.2.3.4:5060) to disable NAT detection

• keepalive: Optional interval for NAT keep alive.

ISUP signalling with SIP-T

In Yate, ISUP signalling is encapsulated in SIP and it is done using SIP-T protocol.
The ISDN User Part or ISUP is part of the Signalling System No. 7 (SS7) which is used to set up telephone calls in the public switched telephone network (PSTN).
When a telephone call is set up from one subscriber to another, several telephone exchanges could be involved, possibly across international boundaries.
To allow a call to be set up correctly, where ISUP is supported, a switch will signal call-related information like called party number to the next switch in the network using ISUP messages.
The telephone exchanges may be connected via E1 or T1 trunks which transport the speech from the calls. The other way of encapsulating ISUP in SIP is SIP-I but is not supported by Yate.
In section [sip-t] enable parameter isup that will build outgoing or decode incoming application/isup bodies.
If enabled an incoming application/isup body will be decoded and added to the engine message issued by the receiving channel.
If the channel needs to add more then one body to an outgoing message, a multipart/mixed body will be attached to the message.

DTMF methods

In section [general] parameter dtmfmethods configures the allowed methods for sending or receiving DTMFs and the order they are tried:

• rfc2833 - Send DTMFs as RFC2833 RTP signals. This method will be used if media is started and remote party advertised telephone event support in SDP.
• info - Send DTMFs using SIP INFO method.
• inband - Send DTMFs in audio stream. This method will succeed if media is started, the tone generator module is loaded and there is a translator from PCM (yate 'slin' format) to current rtp format

More information about how to send DTMFs.

Codecs supported in Yate

The [codecs] section allows to individually enable or disable the codecs. This is a list of supported codecs:

• default - Enable all unlisted codecs by default if a transcoder exists
• mulaw - Companded-only G711 mu-law (PCMU/8000)
• alaw - Companded-only G711 a-law (PCMU/8000)
• gsm: - European GSM 06.10 (GSM/8000)
• lpc10 - Linear Prediction Codec (LPC/8000)
• ilbc - Internet Low Bandwidth Codec (iLBC/8000)
• amr - Adaptive Multi-Rate 3GPP (AMR/8000)
• slin - Signed Linear 16-bit uncompressed (L16/8000)
• g723 - ITU G.723 all variations (G723/8000)
• g726 - ITU G.726 32-bit (G726-32/8000)
• g728 - ITU G.728 all variations (G728/8000)
• g729 - ITU G.729 all variations (G729/8000)
• g729_annexb - G.729 Annex B (VAD) support default (if not in SDP)
• amr_octet - Octet aligned AMR RTP payload default (if not in SDP)

Listeners set in Yate

Configured listeners tell Yate on which network interfaces to listen.

They are set in section called [listener name] or in [general] section in ysipchan.conf.

Yate can bind TCP, UDP and TLS listeners.

See also:

• SIP Protocol.
• SIP Configuration File
• SIP Features Module