HUAWEI CSOFTX3000

Signaling Protocols Contents

Contents

13 SIP .............................................................................................................................................13-1
13.1 Description of SIP .....................................................................................................................................13-2
13.1.1 Related Terms ..................................................................................................................................13-2
13.1.2 SIP Addressing.................................................................................................................................13-3
13.2 SIP Message Types....................................................................................................................................13-4
13.2.1 Request Messages ............................................................................................................................13-4
13.2.2 Response Messages..........................................................................................................................13-5
13.3 SIP Message Structure...............................................................................................................................13-7
13.3.1 Request Message Structure ..............................................................................................................13-8
13.3.2 Request Message Examples ...........................................................................................................13-13
13.3.3 Response Message Structure..........................................................................................................13-14
13.3.4 Response Message Examples.........................................................................................................13-15
13.4 SIPI..........................................................................................................................................................13-16
13.4.1 Introduction to SIPI........................................................................................................................13-16
13.4.2 Encapsulation.................................................................................................................................13-16
13.4.3 Mapping .........................................................................................................................................13-17
13.5 SIP Signaling Procedures ........................................................................................................................13-17
13.5.1 Flows of Mobile Originated Calls Through SIP Trunks.................................................................13-17
13.5.2 SIPI Signaling Procedure ...............................................................................................................13-19

Issue 03 (2007-06-30) Huawei Technologies Proprietary i

 HUAWEI CSOFTX3000
Figures Signaling Protocols

Figures

Figure 13-1 Structure of a SIP request message ...............................................................................................13-8

Figure 13-2 Structure of a SIP response message...........................................................................................13-15
Figure 13-3 SIP flowchart of an MOC through the SIP trunks.......................................................................13-18

Figure 13-4 A successful SIPI procedure (PSTN-IP-PSTN) ..........................................................................13-19

ii Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols Tables

Tables

Table 13-1 Request messages ...........................................................................................................................13-5

Table 13-2 Response messages.........................................................................................................................13-5

Issue 03 (2007-06-30) Huawei Technologies Proprietary iii

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

13 SIP

About This Chapter

The following table lists the contents of this chapter.

Section Describes

13.1 Description of SIP
13.2 SIP Message Types
13.3 SIP Message Structure
13.4 SIPI
13.5 SIP Signaling Procedures
Application and related terms of the SIP protocol.
SIP message types.
SIP message structure.
Application of SIPI.
Examples of the SIP signaling procedures.

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-1

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

13.1 Description of SIP

SIP is an application-layer control protocol that can establish, modify, and terminate sessions
or calls. These sessions include multimedia conferences, Internet telephony, and similar
applications. SIP is one of the key protocols that implement the voice over IP (VoIP).
SIP supports the following services:
z Name mapping
z Redirection
z Integrated services digital network (ISDN) services
z Intelligent network services
These services also enable personal mobility. That is, end users can originate and receive calls
and access subscribed telecommunication services from any location at any time.
SIP supports five aspects of establishing and terminating multimedia communication:
z User location: determining the end system to be used for communication
z User capabilities: determining the media and media parameters to be used
z User availability: determining the willingness of the called party to engage in
communications
z Call setup: sending ring back tones to the called party and establishing call parameters at
both called and calling parties
z Call handling and control: including redirection, transfer, and termination of calls
SIP can also initiate multi-party calls using a multipoint control unit (MCU) or fully meshed
interconnection instead of multicast. Internet telephony gateways that connect public switched
telephone network (PSTN) parties can also use SIP to set up calls between them.
SIP can use services provided by several underlying protocols. The lower layer can provide
either a packet or a byte stream service with reliable or unreliable service. SIP can use user
datagram protocol (UDP) and transmission control protocol (TCP) as transport protocols;
UDP is preferred.

13.1.1 Related Terms

Call
A call consists of all the participants in a conference invited by a common source. An SIP call
is identified by a globally unique Call-ID.
Therefore, if several people invite a user to the same multicast session, each of these
invitations will be a call. A point-to-point Internet telephony conversation maps into a single
SIP call.

Call Leg
The combination of Call-ID, To, and From identifies a call leg. For example, for a call
between A and B, the requests sent from A to B and from B to A use the same Call-ID
belonging to the same call leg. A call leg is actually a path of messages for a call.

13-2 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

Transaction
An SIP transaction occurs between a client and a server. It comprises all messages sent from
the client to the server, that is, from the first request to the final (non-1xx) response message,
and from the server to the client.
The Cseq sequence number within a call leg identifies a transaction. An ACK request,
however, has the same Cseq number as the corresponding INVITE request, but is a different
transaction.
A normal call includes three transactions. Call initiation consists of two requests: INVITE and
ACK. The former requires a response. The latter is an acknowledgement that the final
response is received, which requires no response. Call termination contains one request, BYE.

Location Service
Location services are offered by location servers. An SIP redirect or proxy server uses a
location service to obtain the possible location of a called party, which is beyond the scope of
this document. The manner in which an SIP server requests location services is, however,
beyond the scope of this manual.

Proxy Server
A proxy server is an intermediary program. It acts as a server and a client to route SIP
requests to destinations. A proxy server may process requests internally or pass them on to
other proxy servers. It interprets, and if necessary, rewrites a request before forwarding the
message.

Redirect Server
A redirect server performs the following:
z Accepts an SIP request.
z Maps the address into zero or more new addresses.
z Returns these addresses to the client.
Thus, the client can directly initiate requests to these new addresses again.
A redirect server implements the routing function instead of receiving or rejecting calls.

Registrar
A registrar is a server that accepts REGISTER requests. It is located with a proxy or redirect
server. A registrar must store the address mapping relationship in REGISTER requests in a
database for subsequent call processes. It can offer location services.

User Agent
A user agent is a logical entity that initiates or receives SIP requests.

13.1.2 SIP Addressing

Uniform resource identifiers (URIs) are used within SIP messages to indicate the originator
(From), current destination (Request-URI), and final recipient (To) of an SIP request, and to
specify redirection addresses (Contact).

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-3

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

Generally, an SIP URL has the following syntax:

SIP:user:password@host:port;transport-param|user-param|method-param|
ttl-param|maddr-param|other-param

The components of an SIP URI have the following meanings:

z SIP: indicates that SIP is used for the communication with a specified end system.
z user: consists of any characters in the form of e-mail address or telephone number.
z password: can be included in an SIP URL. The use is not recommended because the
passing of authentication information in texts is a security risk.
z host: can be a host domain name or an IP address.
z port: indicates the port number to which a request is sent. The default is 5060, a public
SIP port number.
z transport-param: indicates the transport protocol that has to be used, TCP or UDP. The
default is UDP.
z user-param: can be a telephone number. A special function of SIP URL is to allow the
host to be an IP telephony gateway with a telephone number as the username. 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.
z method-param: specifies methods or operations to be used.
z ttl-param: designates the time-to-live (TTL) of a UDP multicast data packet. This
parameter is valid only when the Transport parameter is "UDP" and the maddr parameter
is "multicast address".
z maddr-param: provides the server address to be contacted for a user, overriding the
address supplied in the host field. This address is typically a multicast address.

The following parameters are optional:

z transport-param
z user-param
z method-param
z ttl-param
z maddr-param
z other-param

13.2 SIP Message Types

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

13.2.1 Request Messages

Request messages are sent from a client to a server to activate a specific operation. They are
INVITE, ACK, BYE, CANCEL, REGISTER, and OPTIONS. Table 13-1 lists the functions of
these messages.

13-4 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

Table 13-1 Request messages

Message Function

INVITE Initiate a session request to invite a user to participate in a session. The

session descriptor is contained in the message body. For a session
between two parties, the calling party must specify the media type that it
supports and the related parameters. The called party must also specify
the media type that it supports through the response message. In addition,
the called party can specify the media type that it sends.
ACK Confirm that the client receives a final response to an INVITE request.
ACK messages are used only with INVITE message.
BYE Indicates that the client wishes to release a call that is already set up.
CANCEL Cancel a pending request.
CANCEL messages do not affect a completed request. A request is
considered completed if the client receives a final response from the
server.
REGISTER Register an address with an SIP server.
OPTIONS Query a server about its capacity.

13.2.2 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. Table 13-2 lists the classification of the
response messages and their meanings.

Table 13-2 Response messages

Serial Function Status Message Function
No. Code

1xx Informational (provisional), 100 Trying

indicating that the request is
received and the system 180 Ringing
continues to process the
181 Call is being forwarded
request
182 Queued
183 Session progress
2xx Indicating that the request is 200 OK
successfully received,
realized, and accepted.

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-5

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

Serial Function Status Message Function

No. Code

3xx Redirection, indicating that 300 Multiple Choices

further action requires to be
taken in order to complete the 301 Moved Permanently
request
302 Moved Temporarily
305 User Proxy
380 Alternative Service
4xx Client error, indicating that 400 Bad Request
the request contains bad
syntax or cannot be fulfilled at 401 Unauthorized
this server
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

13-6 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

Serial Function Status Message Function

No. Code

488 Not Acceptable Here

491 Request Pending
493 Undecipherable
5xx Server error, indicating that 500 Server Internal Error
the server failed to fulfill an
valid request 501 Not Implemented Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
6xx Global failure, indicating that 600 Busy Everywhere
the request cannot be fulfilled
on any server 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 to SIP messages.

13.3 SIP Message Structure

The request and response messages consist of the following:
z A start line
The start line of a request message is a Request-Line, whereas that of a response message
is a Status-Line.
z One or more header fields
Header fields include general-header, request-header, response-header, and entity-header.
The header fields contain different parameters.
− General header fields
Accept | Accept-Encoding | Accept-Langrage | Call-ID | Contact | Cseq | Date |
Encryption | From | Record-Route | Require | Supported | Timestamp | To |
User-Agent | ViaRequest header fields
Authorization | Contact | Hide | Max-Forwards| Organization | Priority |
Proxy-Authorization | Proxy-Require | Route | Require | Response-Key | Subject

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-7

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

− Response header fields

Proxy-Authenticate | Retry-After | Server | Unsupported | Warning |
WWW-Authenticate
− Entity header fields
Allow | Content-Encoding | Content-Length | Content-Type | Expires
z An empty line indicating the end of the header fields
z An optional message body
A message body can use session description protocol (SDP) as the description format of a
session. In addition, a message body can encapsulate ISDN user part (ISUP) messages.
All SIP messages must contain the header field. The message body is optional. The type of the
SIP message and the service determines whether it requires containing the message body.

13.3.1 Request Message Structure

Figure 13-1 shows the structure of a SIP request message, consisting of a request line,
message header, a message header, an empty line, and a message body. A carriage-return
line-feed (CRLF) distinguishes each parameter line in the message header.

Figure 13-1 Structure of a SIP request message

Status
Method Request-URI SIP-Version
line
Call-ID: value

From: value

To: value

Cseq: value

Via: value Message

header
Contact: value

Max-Forwards: value
Content-Length: value
Content-Type: value
.......

CRLF
Message
SDP
body

The Request-Line begins with a method token, followed by the Request-URI identifying the
peer URI and the SIP-Version identifying the protocol version, and ending with a CRLF.
Single space (SP) characters separate the elements.

13-8 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

Methods contain the following request message names:

z INVITE
z ACK
z OPTIONS
z BYE
z CANCEL
z REGISTER
The message header of a request message can be a general header, a request header, or an
entity header. The order of message header parameters is not fixed. Each parameter consists of
its name followed by a colon and a value. The value and colon are separated by a space.
A message header ends with a CRLF, followed by a message body.

Figure 13-1 shows only certain parameters that are possibly present in the message header of a request
message.

The following describes certain common parameters in the message header of a request
message.

Call-ID
This field uniquely identifies a SIP call.
A single multimedia conference can give rise to several calls with different Call-IDs. For
example, a user inviting a single individual several times to the same (long-running)
conference. A user may also receive several INVITEs to the same conference or call with
different Call-IDs. The user judges the repetition of the INVITEs from the identifications in
the session description, such as session identifier and version number carried in the o (source)
field of SDP.
Call-IDs have a generic format:
Call-ID: localID@host
"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 the 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 global local ID.

From
Request and response messages must contain a From general-header field, indicating the
initiator of a request message. A server copies the field from a request message to its response
message. Generally, this field is in the following format:
From: display-name <SIP-URL>;tag=xxxx

The "display-name" is characters displayed on the user interface. The display-name is

"Anonymous" if the system does not display a name. Display-name is an optional field.

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-9

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

The "tag" may appear in the From field of a request message. The “display-name” is optional.
“tag” is a string of hexadecimal numbers in which the hyphen “-“ can be added. It must be
present when two instances of a user sharing a SIP address make call invitations with the
same Call-ID. The "tag" value must be globally unique. The user maintains the same tag
throughout the call identified by the Call-ID.
Example:
From: <sip:1000@191.169.200.61>;tag=1c17691

To
This field specifies the logical recipient of a request message with the same syntax as the
From field. Request and response messages must contain a To general-header field.
Examples:
To: <Sip:1000@191.169.200.61>
To: <sip:1001@191.169.200.61>;tag=62beb3ca

Command sequence (Cseq)

Clients must add the Cseq general-header field to every request message. The Cseq field
contains the command name and a decimal sequence number. This decimal sequence number
is unique within the range of Call-ID.
The initial value of a sequence number is arbitrary. The subsequent request message that
differs in request method, header, or body, but has the same Call-ID must have a sequence
number incremented by one. The retransmitted request message carries the same sequence
number.
A server copies the Cseq value from a request message to its response message.
ACK and CANCEL request messages must contain the same Cseq value as that in the
corresponding INVITE request message, whereas a BYE request message must have a higher
sequence number.
A server records the highest sequence number for any INVITE request message with the same
Call-ID value. The server responds to, and then discards any INVITE request message with a
lower sequence number.

Via
This field is generally in the following format:
Via:sent-protocol sent-by;via-params comment
Where,
sent-protocol=protocol-name / protocol-version / transport,via-params=via-hidden |
via-ttl | via-maddr | via-received | via-branch.

The Via field indicates the existing path of a request message. This prevents request looping
and ensures that response messages take the same path as its corresponding request messages,
which assists in firewall traversal and other unusual routing situations.
The client originating a request message must insert a Via field containing its host name or
network address into the request message. The client must also insert the port number on
which the response messages have to be received if the request message does not use the
default port number.

13-10 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

In the process of sending a request, each proxy server must add its own address as a new Via
field before any existing Via fields.
A proxy sending a request to a multicast address must add the "maddr" parameter to its Via
field. If a server receives a request message containing a "maddr" parameter in the topmost
Via field, the server transfers the request message to the multicast address listed in the
"maddr" parameter.
Generally, every host that sends or forwards a SIP message adds a Via field indicating the path
traversed. Network address translators (NATs), however, may change the source address and
port number of a request message. In this case, the Via field cannot be relied on to route the
response messages.
To prevent this, a proxy server must check the top-most Via field. If the value of Via field
does not match the previous hop address of the proxy server, the proxy adds a "received"
parameter to the Via field inserted by the previous hop. For example:
Via:SIP/2.0/UDP CSOFTX3000.bell-telephone.com:5060
Via:SIP/2.0/UDP 10.0.0.1:5060;received=191.169.12.30
In this example, the message originates from 10.0.0.1 and traverses a NAT with the IP address
199.172.136.3 to reach the proxy server CSOFTX3000.bell-telephone.com. The proxy sever
does the following:
1. Notices the mismatch.
2. Adds a "received" parameter to the Via field of the previous hop, containing the
originating address of the packet.
3. Appends its own address at the top as a new Via field.
A proxy server or a client processes the Via field in a response message according to the
following rules:
The first Via field specifies the proxy or client that is processing this response message. If it
does not, discard the message; otherwise, delete this Via field.
If there is no second Via field, this response message reaches its destination. Otherwise, the
processing depends on whether the Via field contains a "maddr" or a "receiver" parameter.
If the second Via field contains a "maddr" parameter, send the response message to the
multicast address listed in the second Via field. The port used is indicated by the "sent-by"
parameter, and port 5060 is used if the "sent-by" parameter does not specify the port. The TTL
of the response message should be the value indicated in the "ttl" parameter. If this parameter
is not present, set it to "1".
If the second Via field contains a "received" but not a "maddr" parameter, send the message to
the address indicated in the "received" parameter.
If neither of the previous cases applies, send the message to the address indicated by the
"sent-by" value in the second Via field.
An example of the Via field is as follows:
Via: SIP/2.0/UDP 191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=a7c6a8dlze

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-11

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

Contact
This field can appear in INVITE, ACK, and REGISTER request messages, and in 1xx, 2xx,
and 3xx response messages. It provides a URL where a user can be reached for further
communication.
INVITE and ACK request messages contain Contact fields, indicating the location from
which a request message originates. This allows the called subscriber to send future request
messages, such as BYE, directly to the caller rather than through a series of proxy servers.
Generally, this field exists in the following format:
Contact:name-addr;q=value;action= “proxy” |
“redirect”;expires=value;extension-attribute

The "name-addr" form is the same as that in the To and From fields. The "q" value ranges
from 0 to 1. Higher values indicate higher preference. The "action" parameter is applicable
only to REGISTER request messages. It indicates whether a server expects future requests to
the client for the server proxy or redirection service.
If this parameter is not specified, the action taken depends on server configuration. The
"expires" parameter indicates the duration in which a uniform resource identifier (URI) is
valid. This parameter can be a number that indicates seconds or a quoted string that contains a
SIP-date. The "extension-attribute" is an extension name.
An example of the Contact field is as follows:
Contact: <Sip:66500002@191.169.1.110:5061>;q=0.7;expires=3600

Max-Forwards
This field limits the number of times a request message is allowed to be forwarded.
Each proxy server or gateway recipient of a request message containing a Max-Forwards field
must check and update the value of the field before forwarding the request. The initial value is
70. It is subtracted by 1 every time a request message traverses a proxy server or gateway.
If the received value is zero (0) and the request message does not reach its destination address,
the server returns 483 (indicating too many hops) and terminates this request.
The purpose of setting this field is to prevent consuming proxy server resources in the case of
loop during message transfer.
Generally, this field exists in the following format:
Max-Forwards: decimal integrals

Allow
This field lists the set of methods supported by proxy servers.
An example of the Allow field is as follows:
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

Content-Length
This field indicates the size of a message-body using a decimal number of octets. Applications
use this field to indicate the size of a message-body to be transferred.

13-12 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

If TCP serves as the transport protocol, the message header must contain this field.
Content-Length does not involve any line that separates a message header and a message body.
Any Content-Length greater than or equal to zero is a valid value. If the body is not present in
a message, the Content-Length header field must be set to zero.
Generally, this field exists in the following format:
Content-Length: decimal number of octets

Content-Type
This field indicates the media type of the message-body sent to the recipient. If the
message-body is not null, it must contain the Content-Type field.
An example of the Content-Type field is as follows:
Content-Type: application/sdp

Expires
This field indicates the time after which the message content expires.

13.3.2 Request Message Examples

An example of a SIP request message is as follows:
INVITE sip:66500002@191.169.1.110 SIP/2.0
From: <sip:44510000@191.169.1.116>;tag=1ccb6df3
To: <sip:66500002@191.169.1.110>
Cseq: 1 INVITE
Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6
Contact: <sip:44510000@191.169.1.116:5061>
Max-Forwards:70
Content-Length:230
Content-Type: application/sdp

v: 0
o: HuaweiCSOFTX3000 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 following provides details of the example:

z Line 1: Request-Line
The Method is INVITE. The URI of the peer end is "sip:66500002@191.169.1.110" and
the SIP version is "2.0".
z Line 2: From field

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-13

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

It indicates that the address of the request initiator is "sip:44510000@191.169.1.116" and

"tag" is "1ccb6df3", which differentiates the users (sharing the same SIP address) who
initiate call invitations with the same Call-ID.
z Line 3: To field
It specifies that the address of the request recipient is "sip:66500002@191.169.1.110".
z Line 4: Cseq field
z Line 5: Call-ID field
It is globally unique, identifying a specific invitation.
z Line 6: Via field
It indicates the path taken by the request. "SIP/2.0/UDP" specifies the sent protocol, in
which "SIP" is the protocol name, "2.0" is the protocol version, and "UDP" is the
transport layer. "191.169.1.116:5061" indicates that the CSOFTX3000 IP address of the
sender is "191.169.1.116" and port number is "5061". "branch=z9hG4bkbc427dad6" is
the "branch" parameter, which identifies the branch when the CSOFTX3000 distributes
request messages concurrently.
z Line 7: Contact field
It indicates subsequent request messages, such as BYE, which can be directly sent to
"sip:44510000@191.169.1.116:5061" rather than through the Via field.
z Line 8: Max-Forwards field
It specifies that the maximum number of intermediate proxy servers or gateways that the
request message is allowed to traverse is 70.
z Line 9: Content-Length field
It indicates the length of the message body.
z Line 10: Content-Type field
z It indicates that the message contains a single message body SDP.
z Line 11: an empty line
It indicates that the message header ends. and below is the message body described by
the SDP.
The following lists the message body that is described by the SDP. For details, see
SDP-related documents.
v=<protocol version>
o=<user name><session ID><version><network type><address type><address>
s=<subject>
c=<network type><address type><connection address>
t=<start time><end time>
m=<media><port><transport layer><format list>
a=rtpmap:<payload type><encoding><code>

13.3.3 Response Message Structure

Figure 13-2 shows the structure of a SIP response message, consisting of the following:
z A status line
z A message header

13-14 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

z An empty line
z A message body
A line feed character distinguishes each parameter line in the message header. Parameters
vary with response messages.

Figure 13-2 Structure of a SIP response message

SIP- Reason- Status

Status-Code
Version Phrase line
Call-ID: value

From: value
To: value

Cseq: value

Via: value Message

header
Contact: value

Max-Forwards: value
Content-Length: value
Content-Type: value
.......

CRLF
Message
SDP
body

A Status-Line consists of a SIP protocol version, a Status-Code, and its associated textual
phrase (Reason-Phrase). The Status-Code is a 3-digit integer code that indicates the type of a
request message. The Reason-Phrase gives a short textual description of the Status-Code.
The Status-Code includes 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx, which define six types of SIP
response messages. For full definitions, see section 13.2.2 "Response Messages".
The parameters in the header of a response message are the same as those in a request
message header. For details, see section 13.3.1 "Request Message Structure".

13.3.4 Response Message Examples

An example of a SIP request message is as follows:
SIP/2.0 180 Ringing
From: <sip:44510000@191.169.1.116>;tag=1ccb6df3
To: <sip:66500002@191.169.1.110>;tag=58877b85
Cseq:1 INVITE
Call-ID: 20973e49f7c52937fc6be224f9e52543@sx3000
Via: SIP/2.0/UDP 191.169.1.116:5061;branch=z9hG4bkbc427dad6
Contact:<sip:66500002@191.169.1.110:5061;transport=udp>
Content-Length:157

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-15

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

Content-Type:application/sdp

v=0
o=HuaweiCSOFTX3000 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”
indicates that the ringing tone is sent to the called party.
The 2nd and 3rd lines: See section 13.3.2 "Request Message Examples."
The 4th line: This is a Cseq header field, which is 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. The
response message and the request message have the same Cseq field, that is "1 INVITE',
indicating that the response is triggered by the previous request.
The 5th to 9th line: See section 13.3.2 "Request Message Examples."
For details about the description of the message body, see section 13.3.2 "Request Message
Examples."

13.4 SIPI
13.4.1 Introduction to SIPI
SIP with encapsulated ISUP (SIPI) is an extension of SIP. It is a set of mechanisms for
encapsulating ISUP signaling within SIP. The purpose of SIPI is to provide better PSTN-SIP
interconnection. There are three call models: PSTN-IP, IP-PSTN, and PSTN-IP-PSTN.
In the CDMA2000 network, the CSOFTX3000 interworks with other CSOFTX3000s through
SIPI to connect the call and control the bearer. For details about the SIPI signaling procedure,
see section 13.5.2 "SIPI Signaling Procedure."
SIPI adopts SIP message structures and flows. Two techniques, namely, encapsulation and
mapping apply to SIPI.

13.4.2 Encapsulation
Encapsulation means that the SIP message bodies contain the ISUP messages, including the
following two cases:
z A SIP message does not carry SDP. The ISUP messages are encapsulated within the SIP
message body whose type is Application/ ISUP.
z A SIP message that carries SDP contains multiple message bodies. The type of the
message body with ISUP encapsulated in it is Application /ISUP.

13-16 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

13.4.3 Mapping
ISUP-SIP message mapping
SIPI specifies the rules that govern the mapping between the ISUP and the SIP messages. For
example, an IAM must be sent after receiving an INVITE and a REL for BYE.
A mapping between the ISUP and the SIP messages is as follows:
z IAM = INVITE
z ACM = 180 RINGING
z ANM = 200 OK
z REL = BYE
z RLC = 200 OK for BYE

ISUP parameter-SIP header mapping

A SIP request message that is used to set up a call contains information that enables the
message to be correctly routed to its destination, for example, a called number. SIPI defines
the procedure for mapping information from ISUP to SIP. For example, the called number in
an ISUP IAM must be mapped onto the SIP "To" header field.

13.5 SIP Signaling Procedures

13.5.1 Flows of Mobile Originated Calls Through SIP Trunks
The following describes the procedure of a mobile originated call (MOC) through the SIP
trunks between the CSOFTX3000 devices. Figure 13-3 shows the flowchart.

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-17

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

Figure 13-3 SIP flowchart of an MOC through the SIP trunks

BSS CSOFTX3000 CSOFTX3000

CM_SERVICE_REQ

ASS_REQ

ASS_CMP
INVITE

100 Trying

180 Ringing

200 OK

ACK

CLEAR_REQ

BYE
CLEAR_CMD

200 for BYE

CLEAR_CMP

The procedure of a mobile originated call (MOC) through the SIP trunks between the
CSOFTX3000 devices is as follows:
1. An ordinary mobile subscriber initiates a CM_SERVICE_REQ.
2. The CSOFTX3000 sends an ASS_REQ to the BSS.
3. The BSS returns an ASS_CMP.
4. After number analysis, the CSOFTX3000 determines that the outgoing office interacts
with the ingoing office through SIP. At the same time, the CSOFTX3000 sends an
INVITE containing the calling bearer information in the message body to the called
office.
5. The called office returns a 100 Trying to the CSOFTX3000, indicating that it receives
the request message and the message processing is in progress.
6. The CSOFTX3000 receives a 180 Ringing.
7. If the called subscriber picks up the phone, the called office sends a 200 OK to the local
CSOFTX3000, containing the called bearer information in the message body.

13-18 Huawei Technologies Proprietary Issue 03 (2007-06-30)

HUAWEI CSOFTX3000
Signaling Protocols 13 SIP

8. After the MGW fulfils bearer setup under the control of the local CSOFTX3000, the
local CSOFTX3000 sends an ACK to the peer office, indicating the setup of the
signaling path.
9. If the calling subscriber hangs up, the CSOFTX3000 receives a CLEAR_REQ. At the
same time, it sends a BYE to the called office and a CLEAR_CMD to the BSS on the
calling side. On receiving the BYE, the called office sends a 200 for BYE to the
CSOFTX3000. The BSS sends a CLEAR_CMP to confirm the disconnection of the call.
10. If the called subscriber hangs up, the called office sends a BYE to the local
CSOFTX3000. On receiving the BYE, the local CSOFTX3000 returns a 200 for BYE.
At the same time, it sends a CLEAR_CMD to the BSS on the calling side. The BSS
returns a CLEAR_CMP.

13.5.2 SIPI Signaling Procedure

The following figure illustrates the call flow of transparency across points of PSTN-SIP
interconnection in terms of the PSTN-IP-PSTN call model. Figure 13-4 shows the flowchart.

Figure 13-4 A successful SIPI procedure (PSTN-IP-PSTN)

LS A CSOFTX3000 A CSOFTX3000 B LS B

IAM
INVITE
IAM
100 Trying

ACM
180 Ringing
ACM ANM
200 OK
ANM
ACK

REL
BYE
REL

RLC
200 OK
RLC

The procedure for transparently transmitting the PSTN message through SIPI is as follows:
1. After a PSTN subscriber dials, LS A sends an IAM to CSOFTX3000 A.
2. CSOFTX3000 A preserves the received IAM in an INVITE message body that it sends
to CSOFTX3000 B.
3. CSOFTX3000 B extracts the IAM from the INVITE and sends the IAM to LS B.

Issue 03 (2007-06-30) Huawei Technologies Proprietary 13-19

 HUAWEI CSOFTX3000
13 SIP Signaling Protocols

4. CSOFTX3000 B returns a 100 Trying to CSOFTX3000 A, indicating that it receives the

request message and the message processing is in progress.
5. The called PSTN phone rings. At the same time, LS B sends an ACM to CSOFTX3000
B. CSOFTX3000 B preserves the received ACM in a 180 Ringing response message and
then sends the message to CSOFTX3000 A.
6. CSOFTX3000 A extracts the ACM from the received 180 Ringing and forwards the
ACM to LS A. LS A receives the ACM. The calling PSTN subscriber hears the ring back
tones.
7. If the called PSTN subscriber hooks off, LS B sends an ANM to CSOFTX3000 B.
CSOFTX3000 B preserves the received ANM in a 200 OK that it sends to CSOFTX3000
A.
8. CSOFTX3000 A extracts the ANM from the received 200 OK and forwards the ANM to
LS A.
9. CSOFTX3000 A sends an ACK to CSOFTX3000 B, acknowledging the receipt of the
final message from CSOFTX3000 B in response to the INVITE.
10. At this time, both parties can communicate through an established bidirectional signaling
path.
11. If the calling PSTN subscriber hooks on, LS A sends a REL to CSOFTX3000 A.
CSOFTX3000 A preserves the received REL in a BYE message body that it sends to
CSOFTX3000 B.
12. CSOFTX3000 B extracts the REL from the received BYE and forwards the REL to LS
B.
13. On receiving the REL, LS B sends busy tones to the called PSTN subscriber. If the
calling PSTN subscriber hooks on, LS B sends a RLC to CSOFTX3000 B.
14. CSOFTX3000 B preserves the received RLC in a 200 OK message body that it sends to
CSOFTX3000 A.
15. CSOFTX3000 A extracts the RLC from the received 200 OK and forwards the RLC to
LS A.

13-20 Huawei Technologies Proprietary Issue 03 (2007-06-30)