SIP in Yate

Revision as of 11:03, 24 October 2012

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. The SIP protocol it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP). Yate implements SIP protocol that runs on UDP and TCP, not SCTP.

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.

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

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

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.

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

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.

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.

More information about SIP Protocol.