SIP in Yate

From Yate Documentation
(Difference between revisions)
Jump to: navigation, search
(→‎ISUP signalling)
Line 1: Line 1:
 +
 +
 +
=== Yate Server as a SIP - B2BUA ===
  
 
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.
 
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.
  
−
===SIP Transactions and dialogs in Yate ===
 
  
 
SIP (Session Initiation Protocol) is a signaling protocol used to create, manage and terminate sessions in an IP based network. Yate implements SIP protocol that runs on  User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), but not on Stream Control Transmission Protocol (SCTP).
 
SIP (Session Initiation Protocol) is a signaling protocol used to create, manage and terminate sessions in an IP based network. Yate implements SIP protocol that runs on  User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), but not on Stream Control Transmission Protocol (SCTP).
Line 21: Line 23:
  
 
The reply code is an integer number from 100 to 699 and indicates type of the response. There are 6 classes of responses:
 
The reply code is an integer number from 100 to 699 and indicates type of the response. There are 6 classes of responses:
 +
* 1xx: Provisional -- request received, continuing to process the request;
 +
* 2xx: Success -- the action was successfully received, understood, and accepted;
 +
* 3xx: Redirection -- further action needs to be taken in order to complete the request;
 +
* 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
 +
* 5xx: Server Error -- the server failed to fulfill an apparently valid request;
 +
* 6xx: Global Failure -- the request cannot be fulfilled at any server.
  
−
*    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.
 
−
 
−
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.
 
−
 
−
*    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).
 
−
 
−
*    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.
 
−
 
−
*    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.
 
−
 
−
*    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.
 
−
 
−
*    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.
 
  
 
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.
 
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.
Line 40: Line 35:
 
===How to configure SIP in Yate ===
 
===How to configure SIP in Yate ===
  
−
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. In Yate you can build UDP, TCP, TLS listeners. The routing it can be done from one ore more routing modules.
+
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. In Yate you can build UDP, TCP, TLS listeners.  
 +
Yate can be configured to act as a SIP Server or as a [[SIP Client]].
 +
More about routing you can find [[here]].
  
−
=== SIP with NAT in Yate ===
+
==== SIP with NAT in Yate ====
  
 
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, you just have to remove ';' that makes the line a comment in the file.
 
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, you just have to remove ';' that makes the line a comment in the file.
  
−
=== ISUP signalling ===
+
==== ISUP signalling ====
  
 
In Yate, ISUP signalling is encapsulated in SIP and it is done using protocol: SIP-T. The other way is SIP-I but is not supported by Yate.<br>
 
In Yate, ISUP signalling is encapsulated in SIP and it is done using protocol: SIP-T. The other way is SIP-I but is not supported by Yate.<br>
Line 53: Line 50:
 
If the channel needs to add more then one body to an outgoing message, a multipart/mixed body will be attached to the message.
 
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 ===
+
==== DTMF methods ====
  
 
In section '''[general]''' parameter ''dtmfmethods'' configures the allowed methods and the order they are tried:
 
In section '''[general]''' parameter ''dtmfmethods'' configures the allowed methods and the order they are tried:
Line 63: Line 60:
 
More information about how to send DTMFs you can find [[SIP_Send_DTMFs|here]].
 
More information about how to send DTMFs you can find [[SIP_Send_DTMFs|here]].
  
−
=== Codecs supported in Yate ===
+
==== Codecs supported in Yate ====
  
 
The '''[codecs]''' section allows to individually enable or disable the codecs.
 
The '''[codecs]''' section allows to individually enable or disable the codecs.
Line 82: Line 79:
 
* amr_octet  - Octet aligned AMR RTP payload default (if not in SDP)
 
* amr_octet  - Octet aligned AMR RTP payload default (if not in SDP)
  
−
=== Listeners set in Yate ===
+
==== Listeners set in Yate ====
  
 
Listeners in Yate can be set in section called [listener name] and this will tell Yate on which interface to listen. More information about listeners you can find [[SIP Listeners in Yate|here]].
 
Listeners in Yate can be set in section called [listener name] and this will tell Yate on which interface to listen. More information about listeners you can find [[SIP Listeners in Yate|here]].

Revision as of 13:27, 26 October 2012


Contents

Yate Server as a SIP - B2BUA

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.


SIP (Session Initiation Protocol) is a signaling protocol used to create, manage and terminate sessions in an IP based network. Yate implements SIP protocol that runs on User Datagram Protocol (UDP) and Transmission Control Protocol (TCP), but not on Stream Control Transmission Protocol (SCTP).

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 message 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 messages.

After 100 Trying message is sent if in 250 ms no message arrives to Caller A then Yate will send a copy of the first INVITE, this is called retransmission and the flow of the messages will continue.

The reply code is an integer number from 100 to 699 and indicates type of the response. There are 6 classes of responses:

  • 1xx: Provisional -- request received, continuing to process the request;
  • 2xx: Success -- the action was successfully received, understood, and accepted;
  • 3xx: Redirection -- further action needs to be taken in order to complete the request;
  • 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
  • 5xx: Server Error -- the server failed to fulfill an apparently valid request;
  • 6xx: Global Failure -- the request cannot be fulfilled at any server.


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.

How to configure SIP in Yate

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. In Yate you can build UDP, TCP, TLS listeners. Yate can be configured to act as a SIP Server or as a SIP Client. More about routing you can find here.

SIP with NAT in Yate

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, you just have to remove ';' that makes the line a comment in the file.

ISUP signalling

In Yate, ISUP signalling is encapsulated in SIP and it is done using protocol: SIP-T. The other way 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 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 you can find here.

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

Listeners in Yate can be set in section called [listener name] and this will tell Yate on which interface to listen. More information about listeners you can find here.


More information about SIP Protocol.

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

Variants
Actions
Preface
Configuration
Administrators
Developers