No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Voice Feature Guide 01

Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Mechanism of the SIP Protocol

Mechanism of the SIP Protocol

This section describes the SIP protocol that involves network entities, SIP URI, SIP messages, and SIP media negotiation mechanism. Learning of this chapter enables you to have a deep understanding of the SIP protocol.

SIP Network Entities and Application

SIP Network Entities
Various logical entities exist on the SIP network to play different roles. Major SIP entities are SIP user agent and SIP network server, as shown in Figure 1-21.
Figure 1-21 SIP network entities

User agent (UA)

The UA sends or receives SIP requests and processes these requests. The UA is logically classified into user agent client (UAC) and user agent server (UAS). The UAC sends requests to UAS, and the UAS responds to these requests. The responses can be acceptance, rejection, or redirection.
NOTE:
A Huawei AG functions as a UA.

Proxy server

The proxy server, a logical network entity, forwards requests or responses on behalf of a client. The proxy server can also function as a server. The proxy server provides the following functions: routing, authentication, accounting control, call control, and service providing. The proxy server attempts to forward requests to multiple addresses in multiple modes, such as branching, cycling, and recursively querying.

Registration server

The registration server receives registration requests and saves address mapping contained in the registration requests to the database for the usage by subsequent call processing and subscriber's home address locating.

Redirection server

The redirection server responds to received requests with one or multiple new addresses. Then, the client simply sends requests to these addresses. The redirection server does not receive or reject calls. It mainly completes the routing function and can support the mobility of SIP terminals together with the registration process.

Location server

The location server provides locating functions. The location server obtains the possible called party's address for the redirection server and proxy server and provides a list of mapping between recorded addresses and contact addresses.

In the actual establishment of a SIP application system, a SIP server must cooperate with other background applications to provide a manageable carrier network. For example, the SIP server needs to communicate with the Remote Authentication Dial In User Service (RADIUS) server for terminal authentication.

NOTE:
The IMS network or softswitch functions as the redirection server, proxy server, and registration server, and the DNS server functions as the location server.
Basic SIP Functions
SIP provides the following basic functions:
  • User location: determines terminals used for communication.
  • User capabilities: determines the communication media and parameters used by the media.
  • User availability: determines the willingness of the called party to join in the communication.
  • Call setup: establishes a call between calling and called parties.
  • Call handling: transfers or terminates calls.
SIP AG on the IMS Network
Figure 1-22 shows the position of the SIP AG on the IMS network. NEs that have close relationship with the AG include call session control function (CSCF), proxy-call session control function (P-CSCF), interrogating-call session control function (I-CSCF), serving-call session control function (S-CSCF), home subscriber server (HSS), subscription locator function (SLF), media resource server (MRS), and application server (AS).
  • CSCF: The call control center of the IMS system. The CSCF dispatches multiple real-time services on the IP transmission platform and provides central routing engine, policy management, and policy implementation.
  • P-CSCF: The initial contact point between subscribers and the IMS. The P-CSCF routes terminal requests to a correct I-CSCF or S-CSCF and generates CDRs for roaming subscribers. It provides SIP compression on the Gm interface and integrity protection.
  • I-CSCF: During the IMS terminal registration, the I-CSCF assigns an S-CSCF for processing subscriber services and locates the S-CSCF that the called party registers with.
  • S-CSCF: The S-CSCF provides registration, authentication, service triggering and control, and session routing functions for IMS subscribers.
  • HSS: The HSS functions as a database to store information, such as subscriber numbers.
  • SLF: When multiple HSS devices exist in the domain, the SLF selects an HSS for storing subscriber data.
  • MRS: It is classified into multimedia resource function controller (MRFC) and multimedia resource function processor (MRFP). The MRS plays tones and announcements, processes conference media stream (audio mixing) and DTMF digits, and converts codecs. In some situations, the MRS and AS functions can be played by one device.
  • AS: It triggers services.
Figure 1-22 shows voice service providing using the SIP protocol on the IMS network.
  • The SIP AG accesses the IMS network through the P-CSCF. The P-CSCF forwards SIP messages (including registration, multimedia session, and IM/Presence messages) to the homed S-CSCF (based on registration information) or I-CSCF (based on the home domain name carried in the SIP message).
  • The I-CSCF assigns an S-CSCF for processing subscriber information based on subscriber registration information and CSCF capability information.
  • The S-CSCF receives registration requests sent by IMS subscribers and forwarded by the P-CSCF, cooperates with the HSS to authenticate subscribers, and provides routing functions for calling and called parties. The IMS communicates with the AS and MRFC under the control of the S-CSCF.
Figure 1-22 Simplified IMS networking

SIP URI

The SIP protocol uses the uniform resource identifier (URI) to identify terminal users. RFC 2369 defines URI rules and syntax.

SIP URI includes SIP URI and TEL URI, either of which can uniquely identify a SIP user. The SIP URI configured on the access device and the IMS for a SIP user must be the same.

SIP URI

SIP URI is used in SIP messages, indicating the initiator of a request (From), the current destination address (Request-URI), the final receiver (To), and the address after redirection (Contact). SIP URI can also be embedded into the Web page or other hyper links to indicate that a certain user or service can be accessed through SIP.

Generally, the SIP URI is in the following format: sip:user:password@host:port;URI-parameters?headers
Table 1-7 SIP URI format description

Item

Description

SIP

Indicates that the SIP protocol is used to communicate with the peer end.

user

Indicates the user name, which can consist of any characters. In general, the user name can be an e-mail address or a telephone number.

password

Indicates the password, which can be presented in the SIP URI. However, password presentation in the SIP URI is not recommended, because it poses security risks.

host

Indicates the host name. It can be the host domain name or an IPv4 address.

port

Indicates the ID of the port to which requests are sent. The default value is 5060, which is the ID of the public SIP port.

URI-parameters

Indicates URI parameters.
  • transport-param: specifies the protocol used in the transmission layer, such as, UDP or TCP.
  • user-param: identifies whether the user name is a telephone number or a common user name.
  • method-param: specifies the method that is used.
  • ttl-param: indicates the time-to-live (TTL) value of UDP multicast packets. The parameter is used only when the transmission protocol is UDP and the server address is a multicast address.
  • maddr-param: indicates the address of the server that communicates with the user. The parameter overwrites any address derived from the host field. Generally, the parameter is a multicast address.
NOTE:
Parameters transport-param, method-param, ttl-param, and maddr-param are all URL parameters. They are used only in a redirected address, that is, the Contact header field.

headers

Is contained in requests. The header field can be specified using a question mark (?) in a SIP request. For example, sip:alice@example.huawei.com?priority=urgent

Table 1-8 shows examples of the SIP URI.
Table 1-8 SIP URI examples

Example

Description

sip:55500200@10.10.10.1;

55500200 indicates the user name, and 10.10.10.1 indicates the IP address of the gateway for IP calls.

sip:55500200@ 10.10.10.1 :5061; User=phone;

55500200 indicates the user name, 10.10.10.1 indicates the IP address of the host, and 5061 indicates the port ID of the host. User=phone indicates that the user name is a telephone number.

sips:1234@10.110.25.239

sips indicates the secure SIP URI, that is, the security-based TLS protocol is used on the transmission layer. 1234 indicates the user name, and 10.110.25.239 indicates the IP address of the gateway for IP calls.

TEL URI

TEL URI identifies a telephone number that occupies resources. The telephone number can be a global number or a local number. The global number must comply with the E164 coding standard and start with a plus sign (+). The local number must comply with local private numbering plan. Format:

tel:+86-755-6544487

tel:45687;phonecontext=example.com

tel:45687;phonecontext=+86-755-65

SIP Message

Format

The SIP message is encoded in the text format, each line ending with CR or LF. The SIP message has two types, the request message and the response message. The general message format is as follows:

SIP message = Start line
*Message header field
Empty line (CRLF)
[Message body]

A SIP message consists of a start-line, one or more header fields, and a message body. The request and response messages are the same in the format and only differ in the start-line. The request message has a request-line as the start-line and the response message has a status-line as the start-line.

Request Message

Request messages are sent from the client to the server. SIP request messages include INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, PRACK, and UPDATE. Table 1-9 describes these SIP request messages.

Table 1-9 SIP request messages

Request Message

Function

INVITE

Invites a user to join a call

ACK

Acknowledges the response message of the request

OPTIONS

Requests for querying capability information

BYE

Releases an established call

CANCEL

Releases an unestablished call

REGISTER

Registers the user location information on the SIP network server

PRACK

Acknowledges a reliable provisional response message

UPDATE

Updates the session

start-line

The start-line consists of Method, Request-URI, and SIP-Version.
  • Method: determines the type and purpose of a request message. Keywords are request messages in Table 1-9.
  • Request-URI: identifies the user or server address used by the request.
  • SIP Version: indicates the SIP version contained in a request or response. This parameter is case insensitive. In general, values are always in upper cases.

Header field

For details, see Message Header.

Message body

For details, see Message Body.

Response Message
The SIP response message is used for responding to the SIP request message, indicating whether the call is successful or fails. Different from request messages, the start-line of response messages is also called status-line, which consists of SIP-Version, Status-Code, and Reason-Phrase.
  • SIP-Version: indicates the used SIP version.
  • Status-Code: identifies the response message type. The status-code is a 3-digit integer. The first digit of the status-code defines the response type. The other two digits provide detailed descriptions about the response. Table 1-10 describes response messages.
  • Reason-Phrase: provides descriptions about the status code. This field is optional.
Table 1-10 SIP response messages

Status Code

Meaning

Function

1XX

Provisional

The request has been received and is being processed.

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.

NOTE:
Except 1XX responses, other responses are final responses and can terminate requests.

SIP requires that the application must understand the first integer of the response status code, and allows the application not to process the last two integers of the status code.

For example, SIP/2.0 200 OK
  • SIP/2.0 indicates that the SIP version is 2.0.
  • 200 is the status code, indicating a successful response.
  • OK is the cause code and is the further explanation about 200.
Message Header
The SIP message header consists of SIP header fields to complete information transfer and parameter negotiation for SIP sessions. RFC 3261 defined various SIP header fields. This section only introduces five mandatory header fields in a SIP message.
Table 1-11 Mandatory SIP header fields

Header Field

Function

Common Format

Description

Call-ID

Globally identifies a session.

Local flag@host

-

From

Indicates the initiator of the request. The server copies this field from the request message to the response message.

Displayed name<SIP-URI>;tag=XXXX

The tag, a hexadecimal character string, is used to identify two subscribers who share a SIP address to initiate calls using the same call ID. The tag value must be unique globally. A subscriber must have the same call ID and tag value for a call.

To

Indicates the recipient of the request. It has the same format as From. To and From differs only in the first keyword.

Displayed name<SIP-URI>;tag=XXXX

CSeq

Indicates the sequence number of a request. The client adds this field to each request. The server copies the CSeq value in the request to the response. CSeq is used to determine mapping between responses and requests.

sequence number message name

-

Via

Indicates the path that the request passes. This header field can prevent loop from happening during the request transmission and ensure that the response and request are transmitted in the same path to meet specified requirements.

transmit protocol, sender; hidden parameter, TTL parameter, multicast address parameter, receiver flag, branch parameter

For details, see Via processing.

Via processing

Figure 1-23 shows the Via processing.
  • For a request: When transmitting a request, the SIP entity adds its address on the most outer of the Via set of the request. Therefore, when the request reaches the destination, a Via header field set similar to the stack is formed in the request.
  • For a response: The destination entity copies the Via address in the request to the response. When receiving the response, the proxy server checks whether the Via at the most outer of the Via set is the proxy server's address. If yes, the proxy server deletes the Via, checks the next Via address, and sends the response to the next Via address. If the next Via address does not exist, this response is terminated on this proxy server.
Figure 1-23 Processing of the Via header field
Message Body

The message body is used to negotiate information and parameters during the call establishment. In addition, the message body also transfers authentication information. In general, SIP messages are in Session Description Protocol (SDP) format.

SIP Media Negotiation Mechanism

Session Initiation Protocol (SIP) cooperates with the Session Description Protocol (SDP) to complete media negotiation. Negotiated media includes the IP address, port ID, codec, and media channel parameters.

SDP
SDP, a text-based control protocol at the application layer, is used for negotiating media, including media type and codec solution during session establishment. For the SDP message format, see RFC 2327. Descriptions of common SDP lines are as follows.

SDP lines

Description

v line Indicates the SDP protocol version.
o line Provides the session initiator (user name and host address), session flag, and session version number.
s line Indicates the session name. Each session has a unique session name in the session description.
c line Indicates the linked address. In general, the linked address is the IP address of an AG or a SIP terminal controlled by the IP multimedia subsystem (IMS).
t line Indicates the start and stop times for a session. The t line is used if a session is active at multiple irregularly spaced times.
m line Indicates media description. A session may not have media description or have multiple media descriptions. Media can be audio, video, application (such as whiteboard information), data, and control.
a line Indicates media attribute. A session may not have media attribute or have multiple media attributes. The media attribute can be:
  • media direction: sendonly, recvonly, inactive, or sendrecv
  • ptme (packetization time)
  • bandwidth
  • codec format
Media Negotiation Process

The SIP protocol implements media negotiation based on a simple offer/answer model. In this model, the call initiator informs the call receiver of all supported media formats. The call receiver selects one or multiple media formats to respond the call initiator. Then, media streams are transmitted using negotiated media formats.

Through the negotiation, both the call initiator and call receiver obtain peer media attributes so that they can communicate using correct media channels.

Offer/answer processes cannot be overlapped. Each media negotiation must be on the basis of the previous negotiation. Media streams can be added to (not deleted from) a new SDP offer. Nevertheless, you can set the port number of the media streams to 0 to change the number of media streams that are used.

Media Negotiation Example
Figure 1-24 shows a SIP media negotiation example.
  1. The Alice's SIP phone sends an INVITE message to the Tom's SIP phone to establish a session. The INVITE message contains Alice's SDP information (in blue). The SDP information contains IP address 192.168.0.2, port number 4917, and supported codecs PCMU and PCMA.
  2. Tom's SIP phone replies with a 100 response, indicating that the invitation is being processed.
  3. Tom's SIP phone sends a 200 response to Alice's SIP phone. The 200 response indicates that the invitation has been successfully processed and carries Tom's SDP information (in blue). The SDP information contains IP address 192.168.0.100, port ID 49270, and supported codec PCMA.
  4. After receiving the 200 response, Alice's SIP phone sends an ACK message to Tom's SIP phone to confirm the receiving of the 200 response. Then, Alice and Tom can exchange RTP media packets using the negotiated IP address, port, and codec to communicate with each other.
NOTE:
After the session is established, if the Tom's or Alice's SIP phone wants to modify parameters, they can send a Re-INVITE message to initiate another negotiation. The processing rule is the same as that for processing the INVITE message.
Figure 1-24 SIP media negotiation example
Translation
Download
Updated: 2019-02-22

Document ID: EDOC1100067358

Views: 13272

Downloads: 129

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next