SIP in Yate

From Yate Documentation
(Difference between revisions)
Jump to: navigation, search
(→‎Listeners set in Yate)
 
(107 intermediate revisions by 3 users not shown)
Line 1: Line 1:
  
−
Yate is a back-to-back user agent (B2BUA) that receives a request and processes it. Yate is not a proxy server. Unlike a proxy server, Yate maintains dialog state and must participate in all requests sent on the dialogs it has established.
+
The implementation of SIP it is done using a VoIP SIP driver based on [[YASS]] library.  
  
−
SIP (Session Initiation Protocol) is a signaling protocol used to create, manage and terminate sessions in an IP based network. The SIP protocol it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP).
+
Yate can be used as a:
 +
* [[Yate as SIP server|SIP Server]] - by default Yate can be used as a SIP Server that will listen to all interfaces. You just have to configure users and routing rules in specific configuration files.
 +
* [[Yate as a Conference Server|SIP conference Server]]
 +
* [[SIP_Client|SIP Client]].
 +
* [[SIP Router]]
 +
* [[SIP Session Border Controller]]
 +
* [[SIP Registration Server]]
 +
 
 +
The main configuration file is [[SIP_Configuration_File|ysipchan.conf]].
 +
 
 +
The main functions in this file are:
 +
* defining a '''[[Listeners in Yate|listener]]''' (a specific section in configuration file) which specify the interface so Yate will listen to, that can be on UDP, TCP or TLS.
 +
* enable/disable '''methods''' section - will allow to enable/disable [[SIP Methods]].
 +
* define [[SIP_Flood_Protection|flood protection mechanisms]].
 +
* enable [[SIP Security in Yate|security]] - allows you to use of SRTP packets for voice.
 +
* supports [[RTP_Forwarding|RTP forward]].
 +
* encapsulate SIP in ISUP signalling using SIP-T protocol. The protocol SIP-I is not supported by Yate.
 +
 
 +
=== Yate Server as a SIP - B2BUA ===
 +
 
 +
[[File:yate_b2bua_call_scenario.png]]
 +
 
 +
Yate is a back-to-back user agent (B2BUA). This is a logical entity that receives calls on SIP and sends them through other protocols as configured. In the figure it is IAX, but it can be H.323, Jingle, SIP.
 +
 
 +
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]].
  
 
[[File:sip_flow_messages.png]]
 
[[File:sip_flow_messages.png]]
Line 10: Line 45:
 
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.
 
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 message which is used to establish a session.
+
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 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 messages.
+
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 a 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 SBC|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. You should also have parameter ''ignorevia'' enabled.
 +
 
 +
When Yate is behind a NAT and registers in [[Accfile|accfile.conf]] to a Sip gateway you can set following parameters:
 +
 
 +
* 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, [http://en.wikipedia.org/wiki/ISDN_User_Part ISUP] signalling is encapsulated in SIP using [http://en.wikipedia.org/wiki/Session_Initiation_Protocol#SIP-ISUP_interworking SIP-T protocol].
 +
 
 +
The other way of encapsulating ISUP in SIP would be SIP-I, but it is not supported in Yate.
 +
 
 +
In section '''[sip-t]''' enable parameter ''isup'' that will build outgoing or decode incoming application/isup bodies.<br>
 +
If enabled, an incoming application/isup body will be decoded and added to the engine message issued by the receiving channel.<br>
 +
If the channel needs to add more then one body to an outgoing message, a multipart/mixed body will be attached to the message.
 +
-->
  
−
The reply code is an integer number from 100 to 699 and indicates type of the response. There are 6 classes of responses:
+
==== DTMF methods ====
  
−
*    1xx are provisional responses. A provisional response is response that tells to its recipient that the associated request was received but result of the processing is not known yet. Provisional responses are sent only when the processing doesn't finish immediately. The sender must stop retransmitting the request upon reception of a provisional response.
+
In section '''[general]''' parameter ''dtmfmethods'' configures the allowed methods for sending or receiving DTMFs and the order they are tried:
  
−
Typically proxy servers send responses with code 100 when they start processing an INVITE and user agents send responses with code 180 (Ringing) which means that the callee's phone is ringing.
+
*    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
  
−
*    2xx responses are positive final responses. A final response is the ultimate response that the originator of the request will ever receive. Therefore final responses express result of the processing of the associated request. Final responses also terminate transactions. Responses with code from 200 to 299 are positive responses that means that the request was processed successfully and accepted. For instance a 200 OK response is sent when a user accepts invitation to a session (INVITE request).
+
More information about [[SIP_Send_DTMFs|how to send DTMFs]].
  
−
A UAC may receive several 200 messages to a single INVITE request. This is because a forking proxy (described later) can fork the request so it will reach several UAS and each of them will accept the invitation. In this case each response is distinguished by the tag parameter in To header field. Each response represents a distinct dialog with unambiguous dialog identifier.
+
==== Codecs supported in Yate ====
  
−
*    3xx responses are used to redirect a caller. A redirection response gives information about the user's new location or an alternative service that the caller might use to satisfy the call. Redirection responses are usually sent by proxy servers. When a proxy receives a request and doesn't want or can't process it for any reason, it will send a redirection response to the caller and put another location into the response which the caller might want to try. It can be the location of another proxy or the current location of the callee (from the location database created by a registrar). The caller is then supposed to re-send the request to the new location. 3xx responses are final.
+
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)
  
−
*    4xx are negative final responses. a 4xx response means that the problem is on the sender's side. The request couldn't be processed because it contains bad syntax or cannot be fulfilled at that server.
+
==== Listeners set in Yate ====
  
−
*    5xx means that the problem is on server's side. The request is apparently valid but the server failed to fulfill it. Clients should usually retry the request later.
+
Configured listeners tell Yate on which network interfaces to listen.
  
−
*    6xx reply code means that the request cannot be fulfilled at any server. This response is usually sent by a server that has definitive information about a particular user. User agents usually send a 603 Decline response when the user doesn't want to participate in the session.  
+
They are set in section called [listener name] or in [general] section in ysipchan.conf.
  
−
A call leg is a dialog. A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as INVITE to an request a 2xx response. A dialog is identified by a call identifier.
+
Yate can bind TCP, UDP and TLS [[Listeners in Yate|listeners]].
  
−
Using the default configuration from ysipchan.conf file, Yate will behave as a SIP server, that will listen on all interface or you can configure your own listeners.
 
  
−
SIP is a signalling protocol that runs on UDP so in Yate is implemented a mechanism of transactions. Also TCP/ TLS is implemented in Yate.
+
'''See also:'''
  
−
The way ISUP signalling is incapsulated in SIP it is done throw 2 protocols: SIP-T and SIP-I. Only SIP-T is supported by Yate.
+
* [http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP Protocol].
 +
* [[SIP Configuration File]]
 +
* [[SIP Features Module]]
 +
* [[Telephony]]
  
−
More information about [http://en.wikipedia.org/wiki/Session_Initiation_Protocol SIP Protocol].
+
[[Category:SIP]] [[Category:Codecs]] [[Category:DTMF]] [[Category:B2BUA]]

Latest revision as of 11:43, 4 November 2013

The implementation of SIP it is done using a VoIP SIP driver based on YASS library.

Yate can be used as a:

The main configuration file is ysipchan.conf.

The main functions in this file are:

  • defining a listener (a specific section in configuration file) which specify the interface so Yate will listen to, that can be on UDP, TCP or TLS.
  • enable/disable methods section - will allow to enable/disable SIP Methods.
  • define flood protection mechanisms.
  • enable security - allows you to use of SRTP packets for voice.
  • supports RTP forward.
  • encapsulate SIP in ISUP signalling using SIP-T protocol. The protocol SIP-I is not supported by Yate.

Contents

[edit] Yate Server as a SIP - B2BUA

Yate b2bua call scenario.png

Yate is a back-to-back user agent (B2BUA). This is a logical entity that receives calls on SIP and sends them through other protocols as configured. In the figure it is IAX, but it can be H.323, Jingle, SIP.

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.

Sip flow messages.png

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.

[edit] 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.

[edit] SIP with NAT in Yate

Historically there have been problems with SIP when passing through NAT. This is not a SIP problem, but a 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. You should also have parameter ignorevia enabled.

When Yate is behind a NAT and registers in accfile.conf to a Sip gateway you can set following parameters:

  • 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.

[edit] 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.

[edit] 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)

[edit] 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:

Retrieved from "https://docs.yate.ro/wiki/index.php?title=SIP_in_Yate&oldid=7300"
Personal tools
Namespaces

Variants
Actions
Preface
Configuration
Administrators
Developers