Table of Contents

Put forward and studied by the IETF, the Session Initiation Protocol (SIP) is an application-layer control protocol for multimedia communication over IP network, which can be used for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls, distance learning, telemedicine, and similar applications. That is, all interactive two-party or multiparty multimedia communication activities over the Internet are multimedia sessions. Members in a session can communicate through multicast or through a mesh of unicast relations, or a combination of these.

SIP is being developed and studied. On one hand, SIP learns from the design concepts of other Internet standards and protocols and follows Internet principles such as concision, openness, compatibility and expendability with security issues taken into account. On the other hand, SIP fully considers the support for traditional PSTN services including Intelligent Network (IN) services and Integrated Services Digital Network (ISDN) services.

SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user’s current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the underlying transport protocol and can be extended with additional capabilities.

Being an application-layer multimedia session signaling protocol, SIP can be used to initiate sessions as well as invite members to sessions that have been advertised and established by other means. Sessions can be advertised using multicast protocols such as Session Announcement Protocol (SAP), electronic mail, web pages or Lightweight Directory Access Protocol (LDAP), among others. SIP transparently supports name mapping and redirection services, allowing the implementation of ISDN and IN telephony subscriber services. These facilities also enable personal mobility, that is, the ability of end users to request and access subscribed telecommunication services on any terminal in any location at any time. SIP supports five facets of establishing and terminating multimedia communications:

l User location: determination of the end system to be used for communication.

l User capabilities: determination of the media and media parameters to be used.

l User availability: determination of the willingness of the called party to engage in communications.

l Call setup: "ringing", establishment of call parameters at both called and calling party.

l Call handling and control: including redirection, transfer and termination of calls.

SIP can initiate multiparty sessions using a multipoint control unit (MCU), unicast mesh, or multicast, supporting gateway functionality between PSTN and Internet calls.

SIP can be used in conjunction with other signaling systems or protocols for call setup. The IETF has included extensibility and compatibility of SIP with other protocols. For example, SIP could be used to determine that the party can be reached through H.323, obtain the H.245 gateway and user address and then use H.225.0 to establish the call. In another example, SIP might be used to determine that the callee is reachable through the PSTN and indicate the phone number to be called, possibly suggesting an Internet-to-PSTN gateway be used.

SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed, but SIP can be used to introduce conference control protocols. SIP does not reserve resources, but can convey to the invited system the information necessary to do this.

3.1.2 Related Terms

I. Call

A call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call-ID.

For example, all participants in a conference invited by the same source comprise one call. A point-to-point Internet telephony conversation is a kind of simplest session and maps into a single SIP call.

In normal cases, a call is established by the calling party. More generally, a call can be established by a third party who does not participate in the media communication, where the calling party of the session is not the same as the inviter of the session. For multicast conferences, if a user is invited to the same multicast session by several people, each of these invitations will be a unique call. In an MCU-based, call-in conference, each participant uses a separate call to invite himself to the MCU.

II. Transaction

SIP is a client/server protocol. A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client.

A normal call consists of three transactions. Call initiation consists of two operation requests, namely INVITE and ACK. The former requires a response. The latter is only an acknowledgement that the final response is received; it does not require a response. Call termination consists of one operation request, namely BYE.

III. SIP URL

To transfer protocol messages correctly, there are two significant problems in SIP to be solved. The first problem is addressing, that is, the form of address used to identify end users. The second problem is user location, which will be described later. SIP utilizes the WWW technology to solve those problems.

SIP Uniform Resource Locators (URLs) are used for addressing purposes. SIP URL syntax is defined according to the Uniform Resource Identifier (URI) guidelines specified in the RFC 2396. Especially, the user field could be a telephone number to support addressing of IP telephony gateway and achieve the interworking between IP calls and the PSTN.

A SIP URL has the syntax:

SIP: Username:password@host:port; transport parameter; user parameter; method parameter; time-to-live; server address parameter? header name=header value

SIP indicates that the SIP is used for the communication to the specified end system.

Username is composed of any characters in a form of e-mail address or telephone number. (SoftX3000 adopts telephone number as the username.)

Host is either a domain name or an IPv4 address.

Port refers to the port number to which request message is sent. The default port is 5060, the public SIP port number.

Password can be included in a SIP URL, which is not recommended for the sake of security.

Transport parameter indicates the used transport protocol, TCP or UDP. The default transport parameter is UDP.

For user parameter, a function of SIP URL is to allow the host to be an IP telephony gateway with a telephone number as the username. Because BNF syntax cannot distinguish telephone number from general username, “user parameter” is added to follow the domain name. Two values are available for this field: IP and phone. When the field is set to “phone”, the username is a telephone number and the corresponding end system is an IP telephony gateway.

Method parameter refers to the method (operation) to be used.

Time-to-live (TTL) indicates the life of UDP multicast data packets. This parameter is valid only when the transport parameter is set to “UDP” and the server address parameter is set to “multicast address”.

Server address parameter indicates the address of the server communicating with the user. It, usually the multicast address, overwrites the address in the “host” field.

“Transport parameter”, “time-to-live”, “server address parameter”, and “method parameter” are URL parameters used only in a redirect address, that is the Contact field which will be mentioned later.

The following are some SIP URL examples.

Sip; 55500200@191.169.1.112;

“55500200” is a username. “191.169.1.112” is the IP address of an IP telephony gateway.

Sip; 55500200@127.0.0.1:5061; User=phone;

“55500200” is a username. “127.0.0.1” is the IP address of a host. “5061” is a port number of the host. The user parameter is “phone”, indicating the username is a telephone number.

Sip: alice@registrar.com; method=REGISTER;

“Alice” is a username. “registrar.com” is the domain name of a host. “Register” is a method to be used.

IV. User location

User location is based on registration. After a SIP user terminal is powered on, it starts to register to a registrar (SoftX3000). For that specific purpose, REGISTER request and registration procedure are defined in SIP.

V. Location service

A location service is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). Location services are offered by location servers. Location servers may be co-located with a SIP server, but the manner in which a SIP server requests location services is beyond the scope of this document. In the U-SYS Solution proposed by Huawei, SoftX3000 acts as a location server.

VI. Proxy, Proxy server

A proxy, or proxy server, is a logical network entity that acts as both a server and a client for the purpose of forwarding requests or responses on behalf of other clients. A proxy server may be in one of the states: Stateless, Stateful and Call Stateful. A proxy server attempts to forward requests to multiple addresses with a branch or cycle method.

A proxy server implements the functions of routing, authentication, charging monitoring, call control and service provision. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a proxy server.

VII. Redirect server

A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses, and returns these addresses to the client, so that the client can directly initiate requests to these new addresses again. A redirect server implements the routing function rather than receive or reject calls. The redirect server, in coordination with a registration process, can support personal mobility. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a redirect server.

VIII. Registrar

A register is a server that accepts REGISTER requests. A registrar is typically combined with a proxy or redirect server into a single application. A registrar needs to store the address mapping relationship in REGISTER requests in a database for subsequent call processes. A registrar may offer location services. In the U-SYS Solution proposed by Huawei, SoftX3000 also acts as a registrar.

IX. User agent

A logical entity that can initiates or receive SIP requests.

X. User agent client

A user agent client (UAC) is a client application that initiates the SIP request. An example of UAC is SIP phone.

XI. User agent server

A user agent server (UAS) is a server application that receives the SIP request. An example of UAS is SoftX3000.

Note: The distinguishing of UAC and UAS is based on one transaction.

3.1.3 Structure of Protocol Stack

The structure of SIP protocol stack is shown in Figure 3-1.

Figure 3-1 SIP protocol stack

SIP is designed as part of the overall IETF multimedia data and control architecture currently incorporating protocols such as the resource reservation protocol (RSVP) for reserving network resources, the real-time transport protocol (RTP) for transporting real-time data and providing quality of service (QoS) feedback, the real-time streaming protocol (RTSP) for controlling delivery of streaming media, the session announcement protocol (SAP) for advertising multimedia sessions through multicast and the session description protocol (SDP) for describing multimedia sessions. However, the functionality and operation of SIP does not depend on any of these protocols.

Transport-layer support: SIP lies in the layer above the IP layer. The network layer protocol is IP and the transport layer protocol is TCP or UDP. UDP is preferred.

3.1.4 Implementation in SoftX3000

Through SIP or Session Initiation Protocol for Telephones (SIP-T), SoftX3000 interworks with other SoftSwitch systems and other SIP domain equipment such as SIP phone and UniPhone. The implementation of SIP in SoftX3000 is illustrated in
Figure 3-2.

Figure 3-2 Implementation of SIP in SoftX3000

3.2 Protocol Messages

3.2.1 Message Types

SIP messages are encoded in a text form. There are two types of messages: request messages and response messages.

I. Request messages

Request messages are SIP messages sent from a client to a server, for the purpose of invoking a particular operation. They are INVITE, ACK, OPTIONS, BYE, CANCEL and REGISTER messages. The functions of these messages are listed in Table 3-1.

Table 3-1 Request messages

Request message	Function
INVITE	The INVITE message indicates that the user is being invited to participate in a session. The message body contains a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive as well as their parameters. A success response must indicate in its message body which media the callee wishes to receive and may indicate the media the callee is going to send. A server may automatically respond to an invitation for a conference the user is already participating in, identified either by the SIP Call-ID or a globally unique identifier within the session description, with a 200 (OK) response.
ACK	The ACK request confirms that the client has received a final response to an INVITE request. ACK is used only with INVITE messages.
BYE	The user agent client uses BYE to indicate to the server that it wishes to release the call.
CANCEL	The CANCEL request cancels a pending request, but does not affect a completed request. (A request is considered completed if the server has returned a final status response.)
REGISTER	A client uses the REGISTER request to register an address with a SIP server.
OPTIONS	The OPTIONS request is used to query servers about their capabilities.

II. Response messages

Response messages are used to respond to request messages, indicating the success or failure status of the call. The class of a response message is distinguished by a Status-Code. The Status-Code is a 3-digit integer. The first digit of the Status-Code defines the class of response. The last two digits indicate the response in detail. The classification of response messages and their meanings are shown in Table 3-2.

Table 3-2 Response messages

Serial No.	Status-Code	Message functions
1xx	Informational (provisional)	Request received, continuing to process the request.
	100	Trying
	180	Ringing
	181	Call Is Being Forwarded
	182	Queued
2xx	Success	The action was successfully received, understood, and accepted.
	200	OK
3xx	Redirection	Further action needs to be taken in order to complete the request.
	300	Multiple Choices
	301	Moved Permanently
	302	Moved Temporarily
	303	See Other
	305	User Proxy
	380	Alternative Service
4xx	Client error	The request contains bad syntax or cannot be fulfilled at this server.
	400	Bad Request
	401	Unauthorized
	402	Payment Required
	403	Forbidden
	404	Not Found
	405	Method Not Allowed
	406	Not Acceptable
	407	Proxy Authentication Required
	408	Request Timeout
	410	Gone
	413	Request Entity Too Large
	414	Request-URI Too Large
	415	Unsupported Media Type
	416	Unsupported URI Scheme
	420	Bad Extension
	421	Extension Required
	423	Interval Too Brief
	480	Temporarily Unavailable
	481	Call Leg/Transaction Does Not Exist
	482	Loop Detected
	483	Too Many Hops
	484	Address Incomplete
	485	Ambiguous
	486	Busy Here
	487	Request Terminated
	488	Not Acceptable Here
	491	Request Pending
	493	Undecipherable
5xx	Server error	The server failed to fulfill an apparently valid request.
	500	Server Internal Error
	501	Not Implemented
	502	Bad Gateway
	503	Service Unavailable
	504	Server Time-out
	505	Version Not Supported
	513	Message Too Large
6xx	Global failure	The request cannot be fulfilled at any server.
	600	Busy Everywhere
	603	Decline
	604	Does Not Exist Anywhere
	606	Not Acceptable

Both the request and the response messages contain SIP header fields and SIP message fields.

SDP message fields are added into SIP messages.

3.2.2 Message Structure

I. Request messages

1) Request format

Figure 3-3 illustrates the format for a SIP request that consists of a start line, a message header, and a message body. A line feed character distinguishes each parameter line in the message header. Some parameters are optional for different request messages.

Figure 3-3 Structure of a SIP request message

2) Request message parameters

The following section describes some frequently used parameter fields.

l Call-ID

The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client.

A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. A user might also receive several INVITEs to the same conference or call with different Call-IDs. The user judges the repetition of the INVITEs by identifications in the session description, for example, session identifier and version number carried in the o (source) field in the SDP.

Call-IDs have a generic format:

Call-ID: localID@host

in which, “host” is a domain name defined globally or an IP address routable globally. The local ID is composed of unique URI characters in the scope of “host". Otherwise, the local ID must be a globally unique value to ensure the global uniqueness of Call-ID. Call-IDs are case-sensitive.

Call-ID example:

Call-Id: call-973636852-4@191.169.150.101

“191.169.150.101” is the IP address of a host. “call-973636852-4” is a globally unique local ID.

l Form

All requests and responses must contain the From header field that indicates the initiator of the request. The server duplicates this field from the request message to response messages.

This field has a generic format:

From:Display-name;tag=xxxx

The “display-name” is meant to be rendered by a human user interface. A system should use the display name “Anonymous” if the identity of the client is to remain hidden. The “display-name” is optional. “tag” is a string of hexadecimal numbers in which the hyphen “-“ can be added. When two user instances sharing the same SIP address use the same Call-ID to initiate a call invitation, this tag should be used for distinguishing purposes. The tag value must be globally unique. A user should maintain the same Call-ID and tag value in the whole process of a call.

An example of the From field:

From: ;tag=1c17691

l To

The To header field specifies the logical recipient of the request. The format of the To header field is the same as that of the From header field except that the first key is replaced by “To”. All requests and responses must contain this field.

The tag parameter in the field distinguishes different user instances that are identified by the same SIP URL. A proxy server can concurrently deliver several requests, and the same request might reach different instances (for example, home telephone) of the user. Because the instances might all respond to the request, it is required to use the tag to distinguish the responses from different instances. The tag in the To header field is put by each instance in the response message.

Examples of the To field:

To:

To: ;tag=62beb3ca

In SIP, Call-ID, From, and To header fields identify one call branch. When a proxy server concurrently delivers requests, a call might have several call branches.

l CSeq

CSeq is command sequence. A CSeq header field in a request contains a command name and a single decimal sequence number. Request client defines the sequence number which is unique inside the Call-ID. The initial value of the sequence number is arbitrary. The subsequent values share the same Call-ID. For a request with a different command name and a different message body, the CSeq sequence number should be increased by one. A retransmitted request contains the same sequence number. The server duplicates the CSeq value from the request to the response message, used to correlate the request with the response it triggers.

The CSeq value (decimal sequence number) of an ACK or a CANCEL request is the same as that of the corresponding INVITE request. The CSeq sequence number of a BYE request should be higher than that of the corresponding INVITE request. The server must remember the highest sequence number of an INVITE request having the same Call-ID. Upon receipt of an INVITE request with a lower sequence number, the server sends a response and discards the INVITE request.

Several requests concurrently delivered by the agent server have the same CSeq value. Strictly speaking, CSeq is required for any request that is cancelled by a BYE or CANCEL and also for continuous requests with the same Call-ID sent by the client.

An example of the CSeq field:

Cseq: 1 INVITE

l Via

The Via header field indicates the path taken by the request. The field can avoid loops during the transport of the request and ensure the same path taken by the responses, for example, in firewall occasions.

The client originating a request must add its host name or network address in the Via header field of the request. If the client does not use the default port, it must add the used port number in the field. At requesting for forward, the proxy server must add its address in a new Via header field that is put before the existing Via. If the proxy server receives a request containing its address in a Via header field, the proxy server returns a response indicating a loop detection.

When a request is passing a Network Address Translation (NAT) entity (for example, firewall), the requested source address and the port number might be changed and thus the Via cannot be the base for routing responses. To avoid that, the proxy server should check the top Via header field. If the value of the top Via is different from the previous hop’s address that is detected by the proxy server, the server add a “receive” parameter in the Via which is thus called “Via header field tagged by the receiver”. For example:

Via:SIP/2.0/UDP softx3000.bell-telephone.com:5060

Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30

When the request from 10.0.0.1 passes a NAT point with the external address 191.169.12.30, the request reaches the proxy server—softx3000.bell-telephone.com. At noticing the mismatch between the previous hop’s address and the Via header field address, the proxy server adds the actual sending address, as a receiver’s tag, at the end of the top Via and then adds its own address in a new Via that is put at the topmost.

If the proxy server sends a request to multicast address, the proxy server must add a parameter “maddr” in the Via to indicate that.

The proxy server or the user agent client complies with the following rules to process the received Via:

Rule 1: The first Via header field should indicate the proxy server or the user agent client itself. If not, the proxy server or the user agent client discards the message; otherwise, the proxy server or the user agent client deletes the Via header field.

Rule 2: If there is no a second Via header field, the response should reach the destination. Otherwise, proceed as follows.

Rule 3: If the second Via header field contains a “maddr” parameter, the proxy server or the user agent client sends the response according to the multicast address indicated in the parameter. The used port number is specified in the “sent-by” parameter. If not specified, the proxy server or the user agent client uses a port number 5060. The lifetime of the response should be specified in the “ttl” parameter. If not specified, the proxy server or the user agent client sets it to “1”.

Rule 4: If the second Via header field does not contain a “maddr” parameter but has a field tagged by the receiver, the proxy server or the user agent client sends the response to the address specified in the “received” parameter.

Rule 5: If there is neither a “maddr” parameter nor a tag, the proxy server or the user agent client sends the response to the address specified in the “sent-by” parameter.

The Via header field has a generic format:

Via: sent-protocol sent-by; hidden, ttl; maddr; received; branch

The “sent-protocol” is expressed in the form of “protocol-name/protocol-version/transport”, in which the default values for “protocol-name” and “transport” are SIP and UDP. The “sent-by” is usually the host and port number of the sender. The “hidden” parameter has a key word—hidden. If there is a hidden parameter, it indicates that the field has been encrypted by the previous proxy for privacy purposes. For the meanings of the “maddr” and “received” parameters, see earlier descriptions. The “ttl” and “maddr” parameters are coordinated with each other. The “branch” parameter is used by the proxy server concurrently delivering requests to tag the branches. If the response reaches the destination, the proxy uses it to judge the branch from which the response comes.

An example of the Via field:

Via:SIP/2.0/UDP191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=z9hG4bkbc427dad6

l Contact

The Contact header field is present in INVITE, ACK, and REGISTER requests, success responses, call process responses, and redirection responses to provide an address for direct communication with the user.

The Contact header field in an INVITE or ACK request indicates the location from which the request is originated. With the field, the callee can directly send a request (for example, BYE) to that address, instead of asking a series of proxy servers to forward the request by using the Via header field.

A success response to INVITE might contain the Contact header field, which helps to send the subsequent SIP requests (for example, ACK) directly to that address specified in the field. That address usually indicates the host of the callee. If the host is behind a firewall, that address indicates the proxy server.

Call process response to an INVITE request contains a Contact header field that has the same meaning as the success response message. However, a CANCEL request cannot be directly sent to that address. Instead, the CANCEL must be forwarded through the same path of the original request.

The Contact header field in a REGISTER request indicates the reachable location of the user. The request also defines a wildcard Contact field “*” that can only be used with the “expires” field with a value of “0” to remove all registrations of a user. In the Contact field, the “expires” parameter (optional) can also be specified to indicate the expiration interval of the registration. If the parameter is not specified, the “expires” field value is taken as its default value. If neither case is adopted, it is considered that the expiration interval of the SIP URI is one hour.

The Contact header field in a success response to the REGISTER request returns all locations that are currently reachable for the user.

The Contact header field in a redirect response such as Moved Temporarily, Moved Permanently, or Address Ambiguous specifies other alternative addresses for retry, which can be used for a response to a BYE, INVITE or OPTIONS request.

The Contact header field has a generic format:

Contact: address; q; action; expires; extension

The “address” is expressed in the same form as To and From. The “q” parameter has a value range [0, 1] indicating the relative priority of the given location. The greater the value is, the higher the priority becomes. The “action” parameter is only used in a REGISTER request, indicating the server is required to perform the proxy service or redirection service on the subsequent requests to the client. If the Contact header field does not contain an “action” parameter, the action to be performed depends on the configurations of the server. The “expires” parameter indicates how long the URI is valid either in seconds or by SIP date. The “extension” attribute is actually the extension name.

An example of the Contact field:

Contact: ;q=0.7;expires=3600

l Max-Forwards

The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483 (Too Many Hops) error response.

The purpose of inserting this field is to avoid consuming proxy server resources in an event of loop. The initial field value is 70.

The Max-Forwards header field has a generic format:

Max-Forwards: decimal integer

l Allow

The Allow header field gives a list of request types that can all be supported by the proxy server.

An example of the Allow field:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

l Content-Length

The Content-Length header field indicates the size of the message body, in decimal number of octets, sent to the recipient. Applications use this field to indicate the size of the message body to the transferred, regardless of the media type of the entity. If the used transport protocol is based on streams, for example, TCP, this header field must be used.

The size of the message body does not include the Carriage Return Line Feed (CRLF) that separates the message header from the message body. The Content-Length value must be greater than or equal to 0. If a message does not contain a message body, the value of the Content-Length header field must be set to “0”.

SDP serves to construct the message body of a request or 2xx response.

The Content-Length header field has a generic format:

Content-Length: decimal value

An example of the Content-Length header field:

Content-Length: 349

That indicates the length of the message body is 349 bytes.

l Content-Type

The Content-Type header field indicates the media type of the message body sent to the recipient. If the message body is not empty, the Content-Type header field must be present. If the body is empty and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file).

An example of the Content-Type header field:

Content-Type: application/sdp

l Supported

Transportation of a 100 provisional response defined in SIP is not reliable. In other words, there is no guarantee that UAC can receive the provisional response sent by the UAS.

If the response is required to carry information about media, it must be guaranteed that the message can be reliably transported to the peer. “100rel” extension provides an appropriate mechanism for the reliable transportation of the 100 response. The acknowledgement request method for a provisional response in “100rel” is PRACK.

If the UAC supports the extension, the UAC adds a “Supported: 100rel” header field in the message transmitted. If the UAS supports the extension, the UAS adds a “Require: 100rel” header field in the 100 response transmitted. Upon receipt of the response, the UAC is required to send a PRACK request to the UAS, notifying the UAS of the receipt of the provisional response. The UAS sends a 2xx response to the UAC to terminate the acknowledgement process of the provisional response.

If a UA wants to send a provisional response carrying a SDP message body, the UAC and the UAS must support and use the “100rel” extension to guarantee the reliable transportation of the message.

For example:

Supported: 100rel

l User-Agent

The User-Agent header field contains information about the UAC originating the request.

Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Therefore, the User-Agent header field should be set to be a configurable option.

For example:

User-Agent: Softphone Beta1.5

l Expires

The Expires header field gives the relative time after which the message (or content) expires.

For example:

Expires: 5

l Accept-Language

The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server assumes all languages are acceptable to the client.

For example:

Accept-Language: en

l Authorization

The Authorization header field contains authentication credentials of a UA.

The following introduces a general process for a UA to request an authorization from the server.

If the server requires authorizing the user when the UA originates a request, a nonce is generated at the local end for this authorization and all parameters necessary for the authorization request header field are returned to the UA to initiate a user authorization process.

Upon receipt of the authorization request, the UA generates an encrypted response using a particular algorithm according to the information returned from the server and the user configurations. The UA sends the response through a new request message to the server.

Upon receipt of the new request with the authorization response, the server firstly checks the correctness of the nonce. If the nonce is not generated locally, the server returns a failure message. If the nonce is generated locally but the authorization expires, the server re-generates a nonce and re-initiates a user authorization procedure. The earlier nonce is returned with the cnonce parameter.

If the nonce passes the verification, the server generates a response with the same algorithm as the UA according to the nonce, username, password (the server can obtain the password of the user from the local user information), and URI. In addition, the server compares the generated response with the response carried in the request message. If the responses match, the user successfully passes the authorization. Otherwise, the authorization fails.

The Authorization field has a generic format:

Authorization: method username, realm, nonce, response, URI, cnonce, algorithm

The authorization methods include digest, basic, chap-password, and carddigest. Digest is an HTTP-digest method. Currently SoftX3000 supports only the HTTP-digest method. SoftX3000 will support the carddigest method to achieve Uniphone card number calls.

Username indicates the authenticated user.

Realm is used to identify the domain from which the authorization procedure is initiated.

Nonce is an encryption factor that is generated by the entity initiating the authorization procedure.

Response is a string of characters that the UA generates, by using a particular algorithm, according to the nonce, username, password, and URI from the server upon receipt of the authorization request. The string contains the encrypted password of the user. (During the authorization procedure, the UA and the server exchange other information, except password, in plain text in SIP messages.)

URI refers to the request-URI of the originated call request message. Upon receipt of an authorization request, the UA has to re-originate a request that carries the authorization response information to the server. In the request, some fields including request-URI might be changed at a passed network server. The URI parameter in the authorization header field serves to transfer the request-URI in the original message for authorization purposes when the UA originates the request. This is to ensure the correctness of the authorization procedure.

If the UA returns a new request message with the authorization response after expiration at the server, the server has to re-generate a nonce to authenticate the user. The nonce parameter carries the new nonce. The cnonce parameter carries the earlier nonce to the UA.

Algorithm is used to transfer the algorithm for generating the “response”.

For example:

Authorization: DIGEST USERNAME="6540012", REALM="huawei.com", NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6", URI="sip:191.169.150.30"

3) Example of request message

The following is an example of SIP request message.

INVITE sip:66500002@191.169.1.110 SIP/2.0

From: ;tag=1ccb6df3

To:

CSeq: 1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000

Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6

Contact:

Supported: 100rel,100rel

Max-Forwards:70

Allow:INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length:230

Content-Type: application/sdp

v: 0

o: HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.1.116

s: Sip Call

c: IN IP4 191.169.1.95

t: 0 0

m: audio 30000 RTP/AVP 8 0 4 18

a: rtpmap:8 PCMA/8000

a: rtpmap 0 PCMU/8000

a: rtpmap 4 G723/8000

a: rtpmap 18 G729/8000

The 1st line: This is the start line of the request. It indicates an INVITE request message for URI. The current address of the invited user is “sip:66500002@191.169.1.110”. The SIP protocol version is 2.0.

The 2nd line: This is a From header field. It indicates that the address of the request originator is “”. The tag is “1ccb6df3”. When several users sharing the same SIP address originate INVITEs with the same Call-ID, this is used to distinguish the users.

The 3rd line: This is a To header field. It indicates that the address of the request recipient is “”.

From the From and To header fields, we can find:

A terminal, 44510000, under the control of an MGC with the IP address “191.169.1.116” dials a terminal, 66500002, under the control of an MGC with the IP address “191.169.1.110”. The terminal type might be ESL connected to SIP, H.323, Integrated Access Device (IAD), or Access Gateway (AG).

The 4th line: This is a CSeq header field, used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCEL requests.

The 5th line: This is a Call-ID header field. This header field identifies an INVITE that is globally unique. The Call-ID is “20973e49f7c52937fc6be224f9e52543@sx3000” in which “sx3000” is the domain name of the SoftX3000 originating the call and “20973e49f7c52937fc6be224f9e52543” is the local identifier.

The 6th line: This is a Via header field. This header field indicates the path through which the request passes. “SIP/2.0/UDP” represents the protocol for the transmission, in which the protocol name is “SIP”, the protocol version is “2.0”, and the transport layer is “UDP”. “191.169.1.116:5061” indicates that the IP address of the SoftX3000, the sender, is “191.169.1.116” and the used port is “5061”. “branch=z9hG4bkbc427dad6” is the branch parameter. When concurrently delivering a request, SoftX3000 tags all the branches.

The 7th line: This is a Contact header field, indicating that the subsequent requests (for example, BYE) can be directly sent to without the help of a Via header field.

The 8th line: This is a 100rel extension. This header field provides a reliable transmission mechanism for 100 response.

The 9th line: This is a Max-Forwards header field, indicating that the maximum number of hops the request can transit on the way to its destination is 70.

The 10th line: This is an Allow header field. This header field lists the types of request messages that are supported by the SoftX3000 with a given IP address “191.169.1.116”.

The 11th line: This is a Content-Type header field, indicating that the body carried in the message is a single message body based on the SDP.

The 12th line: This is a white space. An SDP session description follows the white space.

The 13th line: This is the SDP protocol version number. Currently it is the version 0.

The 14th line: This line contains the session owner/creator and the session identifier, used to give the originator (username and host address) of the session, the session identifier, and the session version number. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. If the host does not support user identifier, this field is tagged to be a sign “-“. The first “1073741831” is the session identifier. The session identifier in the form of a digit string helps the multiple tuples (username, session identifier, network type, address type, and address) to construct the session’s globally unique identifier. The second “1073741831” is the version number of the session announcement, which is provided for the proxy server to detect the latest one from the several announcements of the same session. The basic principle is to increment that version number once the session data is modified. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” refers to the address type in the form of a text string. Currently “IP4” and “IP6” are defined. “191.169.1.116” is the IP address of the host that creates the session. If the address type is IP4, the IP address might be a full domain name or a dotted decimal IP4 address. If the address type is IP6, the IP address might be a full domain name or a compressed text IP6 address.

The 15th line: This line contains the session name. Each session description necessarily has one and only one session name.

The 16th line: This line contains the connection related data. Currently the network type and the address type are defined to be “IN” and “IP4”. “191.169.1.95” might be the IP address of a Media Gateway (MG) (the terminal type is ESL telephone connected to an IAD/AG) under the control of the SoftX3000 whose IP address is 191.169.1.116. “191.169.1.95” might also be the IP address of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone).

The 17th line: This line contains the time description. It provides a time segment when the session can be activated, allowing the session to periodically occur. “0” represents the start time. The format for the field is t:. The values of “start time” and “end time” are expressed in the decimal form of Network Time Protocol (NTP) time values. The unit is second.

The 18th line: This line contains the media-level description. It provides information that is suitable only for the media stream. “audio” refers to the media type. Currently five types of media are defined: audio, video, application, data, and control. “30000” represents the transport-layer port to which the media stream is transmitted, that is, the UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG) or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone). “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. “8 0 4 18” is, for audio and video, the media payload type that is defined in the RTP audio/video application document. It means that all the formats carried in the session might be used, but the first one is the default format for the session.

The whole line indicates that A-law PCM single-channel audio signal is used by default, its static payload type is numbered 8 in the RTP audio/video application document, and the signal is transmitted to a UDP port 30000.

The 19th to 22nd lines: These lines introduce rtpmap attributes, specifying the mapping correspondence from RTP payload type to encoding. The format of such a line is a: rtpmap:/[/]. In the format, refers to the number of audio channels. This parameter is unavailable to video signals.

II. Response messages

1) Response format

Figure 3-4 illustrates the format for a SIP response that is composed of a start line, a message header, and a message body. A line feed character distinguishes each parameter line in the message header. Some parameters are optional for different response messages.

Figure 3-4 SIP response format

2) Response message parameters

Refer to the earlier section describing the request message parameters.

3) Example of response message

The following is an example of SIP response message.

SIP/2.0 180 Ringing

From: ;tag=1ccb6df3

To: ;tag=58877b85

Cseq:1 INVITE

Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000

Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6

Require:100rel

RSeq:1

Contact:

Content-Length:157

Content-Type:application/sdp

v=0

o=HuaweisoftX3000 1073741824 1073741824 IN IP4 191.169.1.110

s=Sip Call

c=IN IP4 191.169.1.135

t=0 0

m=audio 30016 RTP/AVP 8

a=rtpmap:8 PCMA/8000

The 1st line: The SIP protocol. The protocol version is 2.0. The status code is 180. “Ringing” is a descriptive phrase, indicting to send the ringing tone to the callee.

The 2nd and 3rd lines: Refer to the example of SIP request.

The 4th line: This is a CSeq header field, used to correlate the INVITE request with the triggered responses and corresponding ACK and CANCLE requests. The CSeq header field in this response has the same meaning as that in the earlier described request. Both are “1 INVITE”, indicating the response is trigger by the previous request.

The 5th to 11th lines: Refer to the example of SIP request.

The 12th line: This is a white space. An SDP session description follows the white space.

The 13th line: This is the SDP protocol version number. Currently it is the version 0.

The 14th line: This line contains the session owner/creator and the session identifier, used to give the originator (username and host address) of the session, the session identifier, and the session version number. “HuaweiSoftX3000” is the username that is used by the user to log into the originating host. If the host does not support user identifier, this field is tagged to be a sign “-“. The first “1073741824” is the session identifier. The session identifier in the form of a digit string helps the multiple tuples (username, session identifier, network type, address type, and address) to construct the session’s globally unique identifier. The second “1073741824” is the version number of the session announcement, which is provided for the proxy server to detect the latest one from the several announcements of the same session. The basic principle is to increment that version number once the session data is modified. “IN” refers to network indicator in the form of a text string. The currently defined IN is Internet. “IP4” refers to the address type in the form of a text string. Currently “IP4” and “IP6” are defined. “191.169.1.110” is the IP address of the host that creates the session.

The 15th line: This line contains the session name. Each session description necessarily has one and only one session name.

The 16th line: This line contains the connection related data. Currently the network type and the address type are defined to be “IN” and “IP4”. “191.169.1.135” might be the IP address of an MG (the terminal type is ESL telephone connected to an IAD/AG) under the control of the SoftX3000 whose IP address is 191.169.1.110. “191.169.1.135” might also be the IP address of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone).

The 17th line: This line contains the time description. It provides a time segment when the session can be activated, allowing the session to periodically occur.

The 18th line: This line contains the media-level description. It provides information that is suitable only for the media stream. “audio” refers to the media type. “30016” represents the transport-layer port to which the media stream is transmitted, that is, the UDP port number of the MG (the terminal type is ESL phone connected to an IAD/AG) or the UDP port number of a SIP or H.323 terminal (the terminal type is SIP or H.323 phone). “RTP/AVP” is the transport layer protocol. Its value is associated with the type of address in the “c” line. For IP4, a great number of media service streams are transferred over RTP/UDP. There are two classes of protocols defined: RTP/AVP, audio/video application document, transported over UDP; Udp, the DUP protocol. “8” is the media payload type defined in the RTP audio/video application document.

The 19th line: This line introduces a rtpmap attribute, specifying the mapping correspondence from RTP payload type to encoding. The RTP payload type “8” represents PCMA.

3.3 Basic Message Procedures

3.3.1 SIP User Registration Procedure

When user powers on a SIP phone, the SIP phone must register itself to the associated server. When the address of a SIP client changes, the SIP phone must re-register itself to the associated server. The SIP must periodically update the registration information. The following scenario presents how a SIP phone registers itself to the SoftX3000 to illustrate the SIP user registration procedure.

In the following example, it is assumed that

l The IP address of SoftX3000 is 191.169.150.30;

l The IP address of SIP Phone is 191.169.150.251;

l SIP Phone requests to register itself to SoftX3000.

Figure 3-5 Registration procedure between SIP entity and SIP server

1) Event 1: SIP Phone originates a Register request to SoftX3000, notifying SoftX3000 of an on-power event or a restart event and requesting to register to MGC. The following is an example of Register request.

From: sip:6540012@191.169.150.30;tag=16838c16838

To: sip:6540012@191.169.150.30;tag=946e6f96

Call-Id: 1-reg@191.169.150.251

Cseq: 2762 REGISTER

Contact: sip:6540012@191.169.150.251

Expires: 100

Content-Length: 0

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.251

The 1st line: This is the start line of the request. It indicates a Register request message. The terminal is originating to register itself to the MGC whose IP address is 191.169.150.30. The SIP protocol version is 2.0.

The 2nd line: This is a From header field. It indicates that the Register originator is a SIP Phone controlled by the MGC whose IP address is 191.169.150.30.

The 3rd line: This is a To header field. It indicates the address of the Register recipient. In this example, the address of the Register recipient, MGC, is 191.169.150.30.

The 4th line: This is a Call-ID header field, This header field identifies an INVITE that is globally unique. The Call-ID is “1-reg@191.169.150.251” in which “191.169.150.251” is the IP address of SIP Phone originating the Register request and “1-reg” is the local identifier.

The 5th line: This is a CSeq header field, used to correlate the Register request with the responses it triggers.

The 6th line: This is a Contact header field. The Contact header field in the Register request indicates the reachable location of the user. It indicates that the current IP address of SIP Phone is “191.169.150.251” and the telephone number is “6540012”.

The 7th line: This line indicates that the lifetime of the Register is 100s.

The 8th line: This line indicates that the length of the message body of the request is null, that is, the message does not carry a session description.

The 9th line: This line indicates that English is the preferred language to mention the reason phrase, the session description, or the status answer contents carried in the answer message.

The 10th line: This line indicates that the message sender, a UA entity, supports sip-cc, sip-cc01, and timer extension protocols. “timer” represents that the terminal supports the session-timer extension protocol.

The 11th line: This line contains information of the user terminal that originates the request. In this example, the information includes the type and the version number of SIP Phone.

The 12th line: This is a Via header field. This header field indicates the path taken by the request. “SIP/2.0/UDP” represents the protocol used for the transmission, in which “SIP” is the protocol name, “2.0” is the protocol version number, and “UDP” is the transport layer. “191.169.150.251” represents the IP address of the request sender.

2) Event 2: SoftX3000 returns a 401 Unauthorized response, indicating that MGC requires authenticating the user. The WWW-Authenticate field carries the authorization method, “digest”, that is supported by MGC and the domain name of MGC, “huawei.com”. SoftX3000 generates a nonce required for this authorization. This response carries those parameters to the terminal to initiate an authorization procedure.

SIP/2.0 401 Unauthorized

From: ;tag=16838c16838

To: ;tag=946e6f96

CSeq: 2762 REGISTER

Call-ID: 1-reg@191.169.150.251

Via: SIP/2.0/UDP 191.169.150.251

WWW-Authenticate: Digest realm="huawei.com",nonce="200361722310491179922"

Content-Length: 0

3) Event 3: SIP Phone re-originates a Register request to SoftX3000. The request carries an Authorization header field that contains an authorization method (“digest”), SIP Phone’s user identifier (a telephone number in this example), MGC’s domain name, nonce, URI, and response parameters. (The contained response parameter contains a response that SIP Phone encrypts, upon receipt of the 401 Unauthorized response message, by using a particular algorithm according to the information returned from the server as well as the user configurations.) The following is an example of Register request.

From: sip:6540012@191.169.150.30;tag=16838c16838

To: sip:6540012@191.169.150.30;tag=946e6f96

Call-Id: 1-reg@191.169.150.251

Cseq: 2763 REGISTER

Contact: sip:6540012@191.169.150.251

Expires: 100

Content-Length: 0

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Authorization: DIGEST USERNAME="6540012", REALM="huawei.com", NONCE="200361722310491179922", RESPONSE="b7c848831dc489f8dc663112b21ad3b6", URI="sip:191.169.150.30"

Via: SIP/2.0/UDP 191.169.150.251

4) Event 4: Upon receipt of the Register request from SIP Phone, MGC checks the correctness of the nonce. If the received nonce is the same as that carried in the 401 Unauthorized response message, SIP Phone passes the check. Otherwise, MGC will return a failure message. Subsequently, MGC collects the nonce, username, password (obtained from the local user information), and URI and uses the same algorithm as used at the terminal to generate a new response parameter. MGC compares the new response parameter with that carried in the request message. If they are consistent, the user successfully passes the authorization; otherwise, the authorization fails. MGC returns a 200 OK response message, indicating the success of the terminal authorization.

SIP/2.0 200 OK

From: ;tag=16838c16838

To: ;tag=946e6f96

CSeq: 2763 REGISTER

Call-ID: 1-reg@191.169.150.251

Via: SIP/2.0/UDP 191.169.150.251

Contact: ;expires=3600

Content-Length: 0

3.3.2 Successful SIP User Call Procedure

An application example for a successful call procedure between two SIP users under the control of the same SoftX3000 is illustrated in Figure 3-6.

In the following example, it is assumed that

l The IP address of SoftX3000 is 191.169.200.61;

l The IP address of SIP Phone A is 191.169.150.101;

l The IP address of SIP Phone B is 191.169.150.100;

l SIP Phone A originates a call to SIP Phone B, and the calling party hooks on first;

l The telephone number of SIP Phone A is 1000, and the telephone number of SIP Phone B is 1001.

1) Event 1: SIP Phone A originates an INVITE request to MGC, requesting MGC to invite SIP Phone B to a session. The session description of the INVITE message carries SIP Phone A’s IP address (191.169.150.101), port number (8766), payload type, encoding information matching the payload type to MGC.

INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61

Call-Id: call-973598097-16@191.169.150.101

Cseq: 1 INVITE

Contact: sip:1000@191.169.150.101

Content-Type: application/sdp

Content-Length: 203

Accept-Language: en

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

v=0

o=Pingtel 5 5 IN IP4 191.169.150.101

s=phone-call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 96 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:96 telephone-event/8000/1

a=rtpmap:8 pcma/8000/1

For interpretation of the lines, refer to the example of request message in the Request Messages section.

2) Event 2: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone A of the receipt of the request and also that MGC is processing the request.

SIP/2.0 100 Trying

From: ;tag=1c12674

To:

CSeq: 1 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

3) Event 3: MGC sends a 407 Proxy Authentication Required response to SIP Phone A, indicating that MGC requires authenticating the user. The Proxy-Authenticate field carries the authorization method, “digest”, that is supported by MGC and the domain name of MGC, “huawei.com”. MGC generates a nonce required for this authorization. This response message carries those parameters to the terminal to initiate an authorization procedure.

SIP/2.0 407 Proxy Authentication Required

From: ;tag=1c12674

To: ;tag=de40692f

CSeq: 1 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Proxy-Authenticate: Digest realm="huawei.com",nonce="1056131458"

Content-Length: 0

4) Event 4: SIP Phone A sends an ACK message to MGC, acknowledging the receipt of the final response to the INVITE request from MGC.

ACK sip:1001@191.169.200.61 SIP/2.0

Contact: sip:1000@191.169.150.101

From: ;tag=1c12674

To: ;tag=de40692f

Call-Id: call-973598097-16@191.169.150.101

Cseq: 1 ACK

Accept-Language: en

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

5) Event 5: SIP Phone A re-originates an INVITE request to SoftX3000. The request carries a Proxy-Authorization field that contains an authorization method (“digest”), SIP Phone’s user identifier (a telephone number in this example), MGC’s domain name, nonce, URI, and response parameters. (The contained response parameter contains a response that SIP Phone A encrypts, upon receipt of the 407 response message, by using a particular algorithm according to the information returned from the server as well as the user configurations.)

INVITE sip:1001@191.169.200.61 SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61

Call-Id: call-973598097-16@191.169.150.101

Cseq: 2 INVITE

Contact: sip:1000@191.169.150.101

Content-Type: application/sdp

Content-Length: 203

Accept-Language: en

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Proxy-Authorization: DIGEST USERNAME="1000", REALM="huawei.com", NONCE="1056131458", RESPONSE="1b5d3b2a5441cd13c1f2e4d6a7d5074d", URI="sip:1001@191.169.200.61"

Via: SIP/2.0/UDP 191.169.150.101

v=0

o=Pingtel 5 5 IN IP4 191.169.150.101

s=phone-call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 96 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:96 telephone-event/8000/1

a=rtpmap:8 pcma/8000/1

6) Event 6: MGC returns a 100 Trying response to SIP Phone A, notifying SIP Phone A of the receipt of the request and also that MGC is processing the request.

SIP/2.0 100 Trying

From: ;tag=1c12674

To:

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

7) Event 7: MGC sends an INVITE message to SIP Phone B, requesting SIP Phone B to participate in the session. The INVITE message carries SIP Phone A’s session description to SIP Phone B.

INVITE sip:1001@191.169.150.100 SIP/2.0

From: ;tag=1fd84419

To:

CSeq: 1 INVITE

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact:

Supported: 100rel,100rel

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length: 183

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741833 1073741833 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.150.101

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

8) Event 8: SIP Phone B returns a 100 Trying response to MGC, notifying MGC of the receipt of the request and also that SIP Phone B is processing the request.

SIP/2.0 100 Trying

From: ;tag=1fd84419

To: ;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact: sip:1001@191.169.150.100

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

9) Event 9: SIP Phone B receives the ringing tone and returns a 180 Ringing response to MGC.

SIP/2.0 180 Ringing

From: ;tag=1fd84419

To: ;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Contact: sip:1001@191.169.150.100

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

10) Event 10: MGC sends a 180 Ringing response to SIP Phone A. SIP Phone A receives the ringback tone.

SIP/2.0 180 Ringing

From: ;tag=1c12674

To: ;tag=e110e016

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Contact:

Content-Length: 0

11) Event 11: SIP Phone B sends a 200 OK response to MGC, notifying that SIP Phone B has successfully received and processed the INVITE request. The message carries its IP address (191.169.150.101), port number (8766), payload type, encoding information matching the payload type to MGC.

SIP/2.0 200 OK

From: ;tag=1fd84419

To: ;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 1 INVITE

Content-Type: application/sdp

Content-Length: 164

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK8fd4310b0

Session-Expires: 36000

Contact: sip:1001@191.169.150.100

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY

User-Agent: Pingtel/1.0.0 (VxWorks)

v=0

o=Pingtel 5 5 IN IP4 191.169.150.100

s=phone-call

c=IN IP4 191.169.150.100

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 pcmu/8000/1

a=rtpmap:8 pcma/8000/1

12) Event 12: MGC sends a 200 OK response to SIP Phone A, notifying that MGC has successfully received and processed the INVITE request, and MGC sends the session description of SIP Phone B to SIP Phone A.

SIP/2.0 200 OK

From: ;tag=1c12674

To: ;tag=e110e016

CSeq: 2 INVITE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Contact:

Content-Length: 183

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741834 1073741834 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.150.100

t=0 0

m=audio 8766 RTP/AVP 0 8

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

13) Event 13: SIP Phone A sends an ACK message to MGC, acknowledging the receipt of the final response to the INVITE request from MGC.

ACK sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0

Contact: sip:1000@191.169.150.101

From: ;tag=1c12674

To: ;tag=e110e016

Call-Id: call-973598097-16@191.169.150.101

Cseq: 2 ACK

Accept-Language: en

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

14) Event 14: MGC sends an ACK message to SIP Phone B, acknowledging the receipt of the final response to the INVITE request from SIP Phone B.

Now, the calling and called parties know both session descriptions and then starts a conversation.

ACK sip:1001@191.169.150.100 SIP/2.0

From: ;tag=1fd84419

To: ;tag=4239

CSeq: 1 ACK

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK44cfc1f25

Max-Forwards: 70

Content-Length: 0

15) Event 15: SIP Phone A hooks on and sends a BYE message to MGC, requesting to terminate the session.

BYE sip:1001@191.169.200.61:5061;transport=UDP SIP/2.0

From: sip:1000@191.169.200.61;tag=1c12674

To: sip:1001@191.169.200.61;tag=e110e016

Call-Id: call-973598097-16@191.169.150.101

Cseq: 4 BYE

Accept-Language: en

Supported: sip-cc, sip-cc-01, timer

User-Agent: Pingtel/1.2.7 (VxWorks)

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

16) Event 16: MGC returns a 487 response to SIP Phone A, indicating the termination.

SIP/2.0 487 Request Terminated

From: ;tag=1c12674

To: ;tag=e110e016

CSeq: 4 BYE

Call-ID: call-973598097-16@191.169.150.101

Via: SIP/2.0/UDP 191.169.150.101

Content-Length: 0

17) Event 17: MGC receives the BYE from SIP Phone A and knows the on-hook event. MGC sends a BYE request to SIP Phone B, requesting to terminate the session.

BYE sip:1001@191.169.150.100 SIP/2.0

From: ;tag=1fd84419

To: ;tag=4239

CSeq: 2 BYE

Call-ID: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd

Max-Forwards: 70

Content-Length: 0

18) Event 18: SIP Phone B hooks on and sends a 200 OK response to MGC, indicating that the session is successfully terminated.

SIP/2.0 200 OK

From: ;tag=1fd84419

To: ;tag=4239

Call-Id: 1746ac508a14feaaccb35e4a35ea1768@sx3000

Cseq: 2 BYE

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKf5dbf00dd

Contact: sip:1001@191.169.150.100

Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY

User-Agent: Pingtel/1.0.0 (VxWorks)

CONTENT-LENGTH: 0

3.3.3 Successful SIP Trunk Call Procedure

Figure 3-7 illustrates an example of a successful SIP trunk call procedure where two SoftX3000s communicate with each other through SIP.

In the following example, it is assumed that

l The IP address of SoftX3000 A is 191.169.1.112;

l The IP address of SoftX3000 B is 191.169.1.110;

l SIP Phone A controlled by SoftX3000 A has a telephone number 66600003;

l SIP Phone B controlled by SoftX3000 B has a telephone number 5550045;

l SIP Phone A originates a call to SIP Phone B, and the called party hooks on first.

Figure 3-7 SIP trunk call procedure

1) Event 1: SIP Phone A controlled by SoftX3000 A hooks off and originates a call to SIP Phone B controlled by SoftX3000 B. SoftX3000 A sends an INVITE message to SoftX3000 B, inviting SoftX3000 to the session. The session description of the INVITE message carries SoftX3000 A’s IP address (191.169.200.61), SIP Phone A’s IP address (191.169.200.101), port number (30014), supported payload type, encoding information matching the payload type to SoftX3000 B.

INVITE sip:5550045@191.169.100.50 SIP/2.0

From: ;tag=64e3f587

To:

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact:

Supported: 100rel,100rel

Max-Forwards: 70

Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER

Content-Length: 184

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741831 1073741831 IN IP4 191.169.200.61

s=Sip Call

c=IN IP4 191.169.200.101

t=0 0

m=audio 30014 RTP/AVP 8 0

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

2) Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request.

SIP/2.0 100 Trying

From: ;tag=64e3f587

To:

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Content-Length: 0

3) Event 3: SoftX3000 B sends a 180 Ringing response to SoftX3000 A, notifying SoftX3000 A of the ringing event at SIP Phone B.

SIP/2.0 180 Ringing

From: ;tag=64e3f587

To: ;tag=2dc18caf

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact:

Content-Length: 0

4) Event 4: SoftX3000 B sends a 200 OK response to SoftX3000 A, notifying that SoftX3000 B has successfully received and processed the INVITE request. The message carries its IP address (191.169.100.50), SIP Phone B's IP address (191.169.100.71), port number (40000), supported payload type, encoding information matching the payload type to SoftX3000 A.

SIP/2.0 200 OK

From: ;tag=64e3f587

To: ;tag=2dc18caf

CSeq: 1 INVITE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bKff661c627

Contact:

Content-Length: 159

Content-Type: application/sdp

v=0

o=HuaweiSoftX3000 1073741826 1073741826 IN IP4 191.169.100.50

s=Sip Call

c=IN IP4 191.169.100.71

t=0 0

m=audio 40000 RTP/AVP 0

a=rtpmap:0 PCMU/8000

5) Event 5: SoftX3000 A sends an ACK message to SoftX3000 B, acknowledging the receipt of the final response to the INVITE request from SoftX3000 B.

ACK sip:5550045@191.169.100.50:5061;transport=udp SIP/2.0

From: ;tag=64e3f587

To: ;tag=2dc18caf

CSeq: 1 ACK

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.200.61:5061;branch=z9hG4bK7d4f55f15

Max-Forwards: 70

Content-Length: 0

6) Event 6: SIP Phone B hooks on. SoftX3000 B sends a BYE message to SoftX3000 A, requesting to terminate the session.

BYE sip:66600003@191.169.200.61:5061 SIP/2.0

From: ;tag=2dc18caf

To: ;tag=64e3f587

CSeq: 1 BYE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a

Max-Forwards: 70

Content-Length: 0

7) Event 7: SoftX3000 A returns a 487 response to SoftX3000 B, indicating the termination.

SIP/2.0 487 Request Terminated

From: ;tag=2dc18caf

To: ;tag=64e3f587

CSeq: 1 BYE

Call-ID: 9e62b921769c9ae546ed4329a3c04182@sx3000

Via: SIP/2.0/UDP 191.169.100.50:5061;branch=z9hG4bK2a292692a

Content-Length: 0

3.3.4 Successful SIP-T Trunk Call Procedure

SIP-T is not a new protocol. Based on SIP, SIP-T provides an extension mechanism of how to achieve the interworking between SIP network and PSTN network. There are three application models: PSTN-IP, IP-PSTN, and PSTN-IP-PSTN.

SIP-T has the following characteristics:

l Encapsulation: SIP message body carries ISUP messages.

l Mapping: mapping between ISUP signaling and SIP messages and mapping between ISUP parameters and SIP header fields. The mapping between ISUP signaling and SIP messages can be simply described in the following way:

IAM = INVITE

ACM = 180 RINGING

ANM = 200 OK

RLS = BYE

RLC = 200 OK

The following takes the PSTN-IP-PSTN model as an example to illustrate the call procedure where PSTN messages are transparently transported through SIP-T messages. A successful SIP-T trunk call procedure is shown in Figure 3-8.

Figure 3-8 Successful SIP-T call procedure (PSTN-IP-PSTN)

1) Event 1: The calling PSTN user hooks off and dials the called number. An Initial Address Message (IAM) is sent to MGC through Signaling Gateway (SG) A controlled by SoftX3000 A.

Upon receipt of the IAM from SG A, SoftX3000 A encapsulates the IAM into the message body (SDP) of an INVITE message and sends it to SoftX3000 B to invite SoftX3000 B to participate in a session. The session description of the INVITE message carries SG A’s IP address (191.169.200.188), port number (30014), supported payload type, encoding information matching the payload type to SoftX3000 B.

2) Event 2: SoftX3000 B returns a 100 Trying response to SoftX3000 A, notifying SoftX3000 A of the receipt of the request and also that SoftX3000 B is processing the request.

3) Event 3: The called PSTN user receives the ringing tone. Meanwhile, SG B sends an Address Complete Message (ACM) to SoftX3000 B. Upon receipt of the ACM, SoftX3000 B encapsulates the ACM in a 180 Ringing response message and sends it to SoftX3000 A. The session description of the 180 Ringing message carries SG B’s IP address (191.169.150.1), port number (13304), supported payload type, encoding information matching the payload type to SoftX3000 A.

Upon receipt of the 180 Ringing message, SoftX3000 A extracts the ACM from the 180 Ringing message and transfers the extracted ACM to SG A. SG A receives the ACM, and meanwhile the calling PSTN user receives the ringback tone.

4) Event 4: The called PSTN user hooks off. SG B sends an Answer Message (ANM) to SoftX3000 B. Upon receipt of the ANM, SoftX3000 B encapsulates the ANM to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A.

Upon receipt of the 200 OK message, SoftX3000 A extracts the ANM from the 200 OK message and transfers the extracted ANM to SG A.

5) Event 5: SoftX3000 A sends an ACK message to SoftX3000 B, acknowledging the receipt of the final response to the INVITE request from SoftX3000 B.

Now, a bi-directional signaling channel is set up between the calling and called parties for them to make a conversation.

6) Event 6: The calling PSTN user hooks on. SG A sends a Release (REL) message to SoftX3000 A. Upon receipt of the REL message, SoftX3000 A encapsulates the REL in the message body (SDP) of a BYE request message and sends it to SoftX3000 B.

Upon receipt of the BYE message, SoftX3000 B extracts the REL from the BYE message and transfers the extracted REL to SG B.

7) Event 7: Upon receipt of the REL message, SG B knows that the calling PSTN user has hooked on, and then transfers the REL to the associated PSTN switch. The PSTN switch receives the message and sends the busy tone to the called PSTN user. The called PSTN user hooks on. SG B sends a Release Complete Message (RLC) to SoftX3000 B. Upon receipt of the RLC, SoftX3000 B encapsulates the RLC to the message body (SDP) of a 200 OK response message and sends it to SoftX3000 A.

Upon receipt of the 200 OK response, SoftX3000 A extracts the RLC from the 200 OK response and transfers the extracted RLC to SG A.

Telecommunication Protocol