GIAO THỨC SIP (Session Initiation Protocol)

Giao thức SIP dùng cho các kết nối giữa 2 MSC Server (qua interface Nc), giữa MSC server và IMS, giữa
MSC Server và NGN.
Là giao thức điều khiển nằm trong lớp APPLICATION LAYER.
Được dùng cho : + Khởi tạo (creation)
+ Sửa đổi (Modification)
+ Kết thúc phiên (Terminate of Session)
Giao thức SIP có thể sử dụng UDP hoặc SCTP làm giao thức truyền tải (Mặc định dùng UDP)

Bản tin SIP có 2 loại là Request và Response

SIP request là được gửi từ Client đến Server
SIP request bao gồm:
+ INVITE :UE origin mời UE khác cùng kết nối vào phiên
+ PRACK: phản hồi các bản tin 1xx (response)
+ ACK: phàn hồi cuối cùng cho 1 bản tin INVITE
+ BYE: Kết thúc 1 phiên hiện có
+ OPTIONS: Lấy thông tin, function của số gọi
+ CANCEL: dừng một yêu cầu trước khi nhận phản hồi cuối cùng của yêu cầu đó.
SIP Response để phản hồi các yêu cầu, chứa trạng thái của phiên (Success hoặc Failure).
SIP Response bao gồm: 3 chữ số, chữ số đầu là loại bản tin response, 2 chữ số cuối cung cấp chi tiết
thông tin của bản tin SIP response.
+1xx (provisional): Chỉ ra bản tin request đã được nhận thành công và server đang tiếp
tục tiến trình xử lý request
+ 2xx (Success): Chỉ ra kết nối thành công, hiểu và chấp nhận.
+ 3xx (Redirection) Cần thực hiện 1 hành động nữa để hoàn thành request
+ 4xx (Client Error) Chỉ ra request có chứa cú pháp sai hoặc request không được xử lý
tại server này
+ 5xx (Server Error): chỉ ra server không xử lý được request hợp lệ này.
+ 6xx (Global Failure) Chỉ ra request không xử lý được tại bất cứ server nào.
Cụ thể như sau:
SIP RESPONSE

Table 1 List of common SIP responses

Message Direction Function

100 MSC -> MSC Trying

180 MSC -> MSC Ringing

181 MSC -> MSC Call Is Being Forwarded

182 MSC -> MSC Queued

183 MSC -> MSC Session Progress

200 MSC -> MSC OK

300 MSC -> MSC Multiple Choices

301 MSC -> MSC Moved Permanently

302 MSC -> MSC Moved Temporarily

305 MSC -> MSC Use Proxy

380 MSC -> MSC Alternative Service

400 MSC -> MSC Bad Request

401 MSC -> MSC Unauthorized

Table 1 List of common SIP responses

Message Direction Function

402 MSC -> MSC Payment Required

403 MSC -> MSC Forbidden

404 MSC -> MSC Not Found

405 MSC -> MSC Method Not Allowed

406 MSC -> MSC Not Acceptable

407 MSC -> MSC Proxy Authentication Required

408 MSC -> MSC Request Timeout

410 MSC -> MSC Gone

413 MSC -> MSC Request Entity Too Large

414 MSC -> MSC Request-URI Too Long

415 MSC -> MSC Unsupported Media Type

416 MSC -> MSC Unsupported URI Scheme

420 MSC -> MSC Bad Extension

421 MSC -> MSC Extension Required

423 MSC -> MSC Interval Too Brief

480 MSC -> MSC Temporarily Unavailable

481 MSC -> MSC Call/Transaction Does Not Exist

482 MSC -> MSC Loop Detected

483 MSC -> MSC Too Many Hops

484 MSC -> MSC Address Incomplete

485 MSC -> MSC Ambiguous

486 MSC -> MSC Busy Here

487 MSC -> MSC Request Terminated

Table 1 List of common SIP responses

Message Direction Function

488 MSC -> MSC Not Acceptable Here

491 MSC -> MSC Request Pending

493 MSC -> MSC Undecipherable

500 MSC -> MSC Server Internal Error

501 MSC -> MSC Not Implemented

502 MSC -> MSC Bad Gateway

503 MSC -> MSC Service Unavailable

504 MSC -> MSC Server Timeout

505 MSC -> MSC Version Not Supported

513 MSC -> MSC Message Too Large

600 MSC -> MSC Busy Everywhere

603 MSC -> MSC Decline

604 MSC -> MSC Does Not Exist Anywhere

606 MSC -> MSC Not Acceptable

NỘI DUNG BẢN TIN SIP

Table 1 IEs in the Request-Line and message header

IE Description

Via Indicates the path through which the request has passed.
The Via header field prevents loops during the transmission of a request. It also ensures that
the corresponding response takes the same path as the request. Therefore, the transmission of
the request and response passes through firewalls or meets special requirements on route
selection.
Generally, the Via header field is in the following format:
Table 1 IEs in the Request-Line and message header

IE Description

Via: sent-protocol sent-by; via-params comment

Here, sent-protocol = protocol-name/protocol-version/transport; via-params = via-branch.
The Via header field must contain the host name or network address of the client and if the
default port number is not contained, the port number at which the client wishes to receive
responses. Normally, each host that sends or forwards a SIP message places its host name or
network address to the Via header field to indicate the path that the SIP message has passed.
The sent-by parameter in the Via header field specifies the address to which a response is to
be sent.

The Via header field in the INVITE message is considered as an example here. In this
example, the request is transmitted through UDP and sent from a termination with the IP
address 129.9.30.50 and port number 5062.

Call-ID Indicates the ID of the SIP session.

A single multimedia conference may have several calls with different Call-IDs. For example,
a subscriber can identify whether the invitations are repeated by using the session ID of the o
IE and the version number in the SDP body.
Generally, the Call-ID header field is in the following format:
Call-ID: local-id@host
Here, host must be a domain name or an available IP address defined globally. In such a case,
local-id, which is composed of URI characters, must be uniquely in the scope defined by host.
local-id can also be set to a globally unique value to ensure the uniqueness of Call-ID
globally. Call-IDs are case-sensitive.

The Call-ID header field in the INVITE message is considered as an example here. In this
example, 10.18.5.64 is a globally defined domain name and
57a5882d4d39645728558b68cc55eb19 is a local ID.

From Indicates the originator of the request.

The server copies the value of the From header field from the request to the corresponding
response. All the SIP requests and responses must contain this header field.
Generally, the From header field is in the following format:
From: display-name <SIP-URI>;tag=xxxx
Here, display-name specifies the characters displayed on the user interface. If presentation is
forbidden, Anonymous is displayed on the user interface by default. display-name is an
optional parameter.
tag must be set to a hexadecimal character string, including hyphens (-). When two user
instances sharing the same SIP address originate a session by using the same Call-ID, the tag
parameter is used for distinguishing. The value of tag must be globally unique. The values of
Call-ID and tag cannot be changed during a session.
Table 1 IEs in the Request-Line and message header

IE Description

The From header field in the INVITE message is considered as an example here. In this
example, 86263201800002 is the calling number of the session.

To Indicates the recipient of the request.

Its format is the same as that of the From header field. All the SIP requests and responses must
contain this header field.

The To header field in the INVITE message is considered as an example here. In this example,
86263201800001 is the called number of the session.

CSeq Indicates the command sequence.

 All the SIP requests must contain this header field. The header field consists of a decimal
sequence number and a method. The sequence number must be unique in the scope
defined by Call-ID. The initial sequence number is arbitrary. For the subsequent requests
with the same Call-ID but different methods or message bodies, the sequence number
increases by one for each request. The request that is resent has the same sequence
number as that of the request that is sent for the first time.
 The server copies the value of the CSeq header field from the request to the
corresponding response.

The CSeq header field in the INVITE message is considered as an example here. In this
example, the sequence number of the INVITE message is 1.

Session- Indicates the session update interval for update negotiation. This header field can be contained
Expires in the INVITE, UPDATE, and 2xx messages.

The Session-Expires header field in the INVITE message is considered as an example here. In
this example, the local end sends a re-INVITE or UPDATE message to the peer end every
1800 seconds after the session is connected, to check whether the peer end has terminated the
session.

Contact Indicates the address for direction communication, that is, the URI of the originator.
This header field can be contained in the INVITE, ACK, REGISTER, 1xx, 2xx, and 3xx
messages.
The Contact header field in the INVITE and ACK messages indicates the location from which
the request is sent. Therefore, the callee can directly send requests, for example, a BYE
message, to the location identified by the Contact header field, rather than through the proxy
servers identified by the Via header field.

The Contact header field in the INVITE message is considered as an example here. In this
example, the IP address of the caller is 129.9.30.50.
Table 1 IEs in the Request-Line and message header

IE Description

Allow Indicates the types of requests supported by the proxy server.

The Allow header field in the INVITE message is considered as an example here. In this
example, the proxy server supports the following methods: INVITE, ACK, OPTIONS, BYE,
CANCEL, INFO, PRACK, NOTIFY, MESSAGE, REFER, and UPDATE.

Max- Indicates the maximum number of times the request can be forwarded before it arrives at the
Forward destination.
s When receiving a request containing the Max-Forwards header field, the proxy server or
gateway must check and update the value of the header field. The initial value of the header
field is 70. The value decreases by one at each hop, that is, when the request passes through
each proxy server or gateway. If the value reaches 0 but the request does not arrive at the
destination, the server sends a 483 message and terminates the request.
The header field is used to ensure that resources of the proxy servers are not wasted because
of loops during message transmission.

The Max-Forwards header field in the INVITE message is considered as an example here. In
this example, the request can be forwarded for 70 times before it arrives at the destination. If
the request does not arrive at the destination after being forwarded for 70 times, the request is
terminated.

RSeq Indicates the sequence number of a reliable provisional response message 1XX.
This header field consists of a decimal sequence number and a command name. When a
100rel message is sent and supported, this header field is contained in the reliable provisional
response 1XX message, which ensures the reliability of message transmission.

The RSeq header field in the 183 message is used as an example here. In this example, the
sequence number of the 183 message is 101.

RAck Indicates the sequence number of the PRACK message that maps a reliable provisional
response message 1XX.
This header field consists of three parts: two decimal sequence numbers and the message type.
The first decimal sequence number is the sequence number indicated by the RSeq header field
in the 1XX message. The second decimal sequence number and the message type are those
indicated by the CSeq header field in the 1XX message.

The RAck header field in the PRACK message is considered as an example here. In this
example, the PRACK message is a message in response to the 1XX message, in which the
RSeq header field has the sequence number 1 and the CSeq header field has the sequence
number 1 INVITE.

Reason Indicates the reason of session release.

Table 1 IEs in the Request-Line and message header

IE Description

This header field can be contained in the CANCEL and BYE messages.

The Reason header field in the BYE message is considered as an example here. In this
example, the release cause value is 16, which indicates that the session is released normally.

Content- Indicates the length of the message body, expressed in decimal values.
Length This header field is used to indicate the size of the message body to be sent. The empty line
used for separating the message header from the message body is not counted as Content-
Length. The value of Content-Length must not be smaller than 0. If no message body is
contained, the value must be set to 0.

The Content-Length header field in the INVITE message is considered as an example here. In
this example, the length of the message body is 444 bytes.

Content- Indicates the media type of the message body.

Type If the message body is contained, the Content-Type header field must be specified.

The Content-Type header field in the INVITE message is considered as an example here. In
this example, the media type of the message body is SDP.