01-14 sip

8/8/2019 01-14 SIP

1/20

HUAWEI CSOFTX3000

Technical Manual Signaling Protocols Contents

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

Contents

14 SIP .............................................................................................................................................14-1

14.1 Description of SIP................................................................ .................................................................... .14-2

14.1.1 Related Terms ........................................................... ..................................................................... ..14-2

14.1.2 SIP Addressing.................................................................................................................................14-4

14.2 SIP Message Types....................................................................................................................................14-4

14.2.1 Request Messages ............................................................... ............................................................. 14-5

14.2.2 Response Messages..........................................................................................................................14-5

14.3 SIP Message Structure...............................................................................................................................14-6

14.3.1 Request Message Structure .............................................................. ................................................ 14-6

14.3.2 Response Message Structure..........................................................................................................14-12

14.4 Introduction to SIP-T ............................................................ .................................................................. 14-13

14.5 SIP Signaling Procedures ............................................................... ......................................................... 14-14

14.5.1 Flows of Mobile Originated Calls Through SIP Trunks................................................................. 14-14

14.5.2 SIP-T Signaling Procedure.............................................................................................................14-16

8/8/2019 01-14 SIP

2/20

Figures

HUAWEI CSOFTX3000

Technical Manual Signaling Protocols

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

Figures

Figure 14-1 Structure of a SIP request message................................................................................ ...............14-7

Figure 14-2 Structure of a SIP response message...........................................................................................14-13

Figure 14-3 SIP flowchart of an MOC through SIP trunks ............................................................... .............14-15

Figure 14-4 A successful SIP-T procedure (PSTN-IP-PSTN).................................................... ....................14-16

8/8/2019 01-14 SIP

3/20

HUAWEI CSOFTX3000

Technical Manual Signaling Protocols Tables

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

Tables

Table 14-1 Request messages .............................................................. ............................................................. 14-5

Table 14-2 Response messages.........................................................................................................................14-6

8/8/2019 01-14 SIP

4/20

HUAWEI CSOFTX3000

Technical Manual Signaling Protocols 14 SIP

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

14 SIPAbout This Chapter

The following table lists the contents of this chapter.

Section Describes

14.1 Description of SIP Application and related terms of SIP protocol.

14.2 SIP Message Types SIP message types.

14.3 SIP Message Structure SIP message structure.

14.4 Introduction to SIP-T Application of SIP-T.

14.5 SIP Signaling Procedures Examples about the SIP signaling procedures.

8/8/2019 01-14 SIP

5/20

14 SIP

HUAWEI CSOFTX3000


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

14.1 Description of SIP

SIP is an application-layer control protocol that can establish, modify, and terminate sessionsor 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 such services as:

Name mapping

Redirection

Integrated services digital network (ISDN) services

Intelligent network services

These facilities also enable personal mobility. That is, end users can originate and receive

calls and access subscribed telecommunication services in any location at any time.

SIP supports five facets of establishing and terminating multimedia communications:

User location: determining the end system to be used for communication

User capabilities: determining the media and media parameters to be used

User availability: determining the willingness of the called party to engage incommunications

Call setup: sending ring back tones to the called party and establishing call parameters atboth called and calling parties

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 meshedinterconnection instead of multicast. Internet telephony gateways that connect public switchedtelephone network (PSTN) parties can also use SIP to set up calls between them.

SIP makes minimal assumptions about the underlying transport and network-layer protocols.

The lower layer can provide either a packet or a byte stream service, with reliable orunreliable service. SIP can use user datagram protocol (UDP) and transmission control

protocol (TCP) as transport protocols. UDP is preferred.

14.1.1 Related Terms

This section depicts some terms related to SIP.

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.

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 singleSIP call.

8/8/2019 01-14 SIP

6/20

HUAWEI CSOFTX3000



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.

Transaction

A SIP transaction occurs between a client and a server. It comprises all messages from the

first request sent from the client to the server up to a final (non-1xx) response message sentfrom the server to the client.

The CSeq sequence number within a call leg identifies a transaction. However, an ACK

request has the same CSeq number as the corresponding INVITE request, but comprises atransaction of its own.

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 finalresponse is received, requiring no response. Call termination contains one request BYE.

Location Service

Location services are offered by location servers. A SIP redirect or proxy server uses alocation service to obtain the possible location of a callee beyond the scope of this document.

However, the manner in which a SIP server requests location services is beyond the scope ofthis manual.

Proxy Server

A proxy server is an intermediary program. It acts as both 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 themessage.

Redirect Server

A redirect server performs the following:

Accepts a SIP request.

Maps the address into zero or more new addresses.

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 co-located with a proxy or

redirect server. A registrar needs to store the address mapping relationship in REGISTERrequests 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.

8/8/2019 01-14 SIP

7/20

14 SIP

HUAWEI CSOFTX3000



14.1.2 SIP Addressing

Uniform resource locators (URLs) are used within SIP messages to indicate the originator

(From), current destination (Request-URI), and final recipient (To) of a SIP request, and tospecify redirection addresses (Contact).

Commonly, a SIP URL has a syntax as follows:

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

ttl-param|maddr-param|other-paramThe components of a SIP URI have the following meanings:

SIP: indicates that SIP is used for the communication with a specified end system.

user: consists of any characters in a form of e-mail address or telephone number.

password: can be included in a SIP URL. However, the use is not recommended, becausethe passing of authentication information in texts is a security risk.

host: can be a host domain name or an IP address. port: indicates the port number to which a request is sent. The default is 5060, a public

SIP port number.

transport-param: indicates which transport protocol to be used, TCP or UDP. The defaultis UDP.

user-param: can be a telephone number. A special function of SIP URL is to allow thehost 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 telephonygateway.

method-param: specifies methods or operations to be used.

ttl-param: designates the time-to-live (TTL) of a UDP multicast data packet. Thisparameter is valid only when the Transport parameter is "UDP" and the maddr parameteris "multicast address".

maddr-param: provides the server address to be contacted for a user, overriding theaddress supplied in the host field. This address is typically a multicast address.

The following parameters are optional:

transport-param

user-param

method-param

ttl-param

maddr-param

other-param

Currently, CSOFTX3000 supports SIP URLs in the format of E.164 number@IP address:port.

For example:

Sip:[email protected]:5060;

8/8/2019 01-14 SIP

8/20

HUAWEI CSOFTX3000



14.2 SIP Message Types

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

14.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 14-1 describes thefunctions of these messages.

Table 14-1Request messagesMessage FunctionINVITE Initiate a session request to invite a user to participate in a session.

ACK Confirm that the client receives a final response to an INVITE request.ACK messages are used only with INVITE message.

BYE Indicate that the client wishes to release a call already set up.CANCEL Cancel a pending request.

CANCEL messages do not affect a completed request. A request isconsidered completed if the client receives a final response from the

server.

REGISTER Register an address with a SIP server.OPTIONS Query a server about its capabilities.

14.2.2 Response Messages

After receiving and interpreting a request message, a server returns a response message to aclient.

There are two types of response messages:

Provisional responseProvisional responses indicate progress, but do not terminate SIP transactions.

Final response

The 1xx responses are provisional, whereas other responses are considered final.

1xx: informational a request received, continuing to process the request.

2xx: success the action was successfully received, understood, and accepted.

3xx: redirection further action needs to be taken in order to complete the request.

4xx: client error the request contains bad syntax or cannot be fulfilled at thisserver.

5xx: server error a SIP server fails to fulfill an apparently valid request.

6xx: global failure the request cannot be fulfilled at any SIP server.

8/8/2019 01-14 SIP

10/20

HUAWEI CSOFTX3000



14.3.1 Request Message Structure

Figure 14-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-returnline-feed (CRLF) distinguishes each parameter line in the message header.

Figure 14-1Structure of a SIP request message

Method Request-URI SIP-Version

Call-ID: value

From: value

To: value

Cseq: value

Via: value

Contact: value

Content-Length: value

Content-Type: value

Max-Forwards: value

.......

CRLF

SDP

Statusline

Messageheader

Message

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.

Methods contain the following request message names:

INVITE

ACK

OPTIONS

BYE

CANCEL

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

8/8/2019 01-14 SIP

11/20

14 SIP

HUAWEI CSOFTX3000



Figure 14-1 only shows some parameters possibly contained in the message header of a request

message.

Parameter DescriptionsThe following describes some common parameters in the message header of a request

message.

Call-ID

This field uniquely identifies a SIP call. A Call-ID is generally in such a format as

Call-ID:local-id@host

The "host" is a host domain name or an IP address. The "local-id" is a unique identifier

within "host". Call-IDs are case-sensitive.

From

Request and response messages must contain a From general-header field, indicating theinitiator of a request message. A server copies the field from a request message to itsresponse message. This field is generally in such a format as

From: display-name ;tag=xxxx

The "display-name" is characters rendered by a human-user interface. The system must

use the display name "Anonymous" if the identity of the client is to remain hidden.

The "tag" may appear in the From field of a request message. It must be present whentwo 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 thecall identified by the Call-ID.

To

This field specifies the recipient of a request message, with the same syntax as the Fromfield. Request and response messages must contain a To general-header field.

In SIP, the combination of Call-ID, From, and To fields identify a call leg.

Command sequence (Cseq)

Clients must add the CSeq general-header field to every request message. A CSeq fieldin a request contains the request method and a decimal sequence number unique within aCall-ID.

The initial value of a sequence number is arbitrary. Consecutive request messages thatdiffer in request methods, headers, or bodies but have the same Call-ID must containmonotonically increasing and contiguous sequence numbers. Retransmissions of thesame request message carry 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 ahigher sequence number.

A server remembers the highest sequence number for any INVITE request message withthe same Call-ID value. The server responds to, and then discards, any INVITE requestmessage with a lower sequence number.

Via

This field is generally in such a format as

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

Where,

8/8/2019 01-14 SIP

12/20

HUAWEI CSOFTX3000



sent-protocol=protocol-name / protocol-version / transport,via-params=via-hidden

| via-ttl | via-maddr | via-received | via-branch.

The Via field indicates the path taken by a request message so far. This prevents request

looping and ensures response messages take the same path as its request messages,

which assists in firewall traversal and other unusual routing situations.The client originating a request message must insert into the request message a Via field

containing its host name or network address, and the port number at which it wishes toreceive response messages if it does not use the default port number.

In the process of sending a request onwards, each proxy server must add its own addressas 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 an "maddr" parameter in thetopmost Via field, the server will transfer the request message to the multicast addresslisted in the "maddr" parameter.

Normally, every host that sends or forwards a SIP message adds a Via field indicating the

path traversed. However, network address translators (NATs) may change the sourceaddress and port number of a request message. In this case, the Via field cannot be reliedon to route response messages.

To prevent this, a proxy server must check the top-most Via field. If the value of Viafield mismatches the previous hop address seen from 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 softx3000.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 softx3000.bell-telephone.com. Theproxy sever does the following:

1. Notices the mismatch.2. Adds a "received" parameter to the Via field of previous hop, containing the

address that the packet actually came from.

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 thefollowing rules:

The first Via field should indicate the proxy or client 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 there, using the port indicated in "sent-by", or port 5060 if noneis present. The TTL of the response message should be the value indicated in the "ttl"parameter. If that parameter is not present, set it to "1".

If the second Via field contains a "received" but not a "maddr" parameter, send themessage 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:

Via: SIP/2.0/UDP 191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=a7c6a8dlze

Contact

8/8/2019 01-14 SIP

13/20

14 SIP

HUAWEI CSOFTX3000



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 forfurther communications.

INVITE and ACK request messages contain Contact fields indicating from which

location a request message originates. This allows the called subscriber to send futurerequest messages, such as BYE, directly to the caller rather than through a series ofproxy servers.


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 isonly applicable to REGISTER request messages. It indicates whether a server expectsfuture 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 how long a uniform resource identifier (URI) is valid. Thisparameter can be a number indicating seconds or a quoted string containing a SIP-date.The "extension-attribute" is an extension name.

An example of the Contact field is:

Contact: ;q=0.7;expires=3600

Max-Forwards

This field limits the number of times for which a request message is allowed to beforwarded.

Each proxy server or gateway recipient of a request message containing a Max-Forwardsfield 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 destinationaddress, the server returns 483 (too many hops) and terminates this request.

The purpose of setting this field is to prevent consuming proxy server resources in thecase of loop during message transfer.


Max-Forwards: decimal integrals

Allow

This field lists the set of methods supported by proxy servers.

An example of the Allow field is:

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

Content-Length

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

If TCP serves as the transport protocol, the message header must contain this field.

An empty line separating a message header and a message body is beyond the scope of

the Content-Length. Any Content-Length greater than or equal to zero is a valid value. Ifno body is present in a message, the Content-Length header field must be set to zero.


Content-Length: decimal number of octets

Content-Type

8/8/2019 01-14 SIP

14/20

HUAWEI CSOFTX3000



This field indicates the media type of the message-body sent to the recipient. If themessage-body is not null, it must contain the Content-Type field.

An example of the Content-Type field is:

Content-Type: application/sdp

Expires

This field gives the time after which the message content expires.

Request Message Examples

An example of SIP request message is:

INVITE sip:[email protected] 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:

Max-Forwards:70

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/8000a: rtpmap 0 PCMU/8000

a: rtpmap 4 G723/8000

a: rtpmap 18 G729/8000

The following details the example:

Line 1: Request-Line

The Method is INVITE, followed by the Request-URI "sip:[email protected]"and SIP-Version "2.0".

Line 2: From field

It indicates the address of the request initiator is "sip:[email protected]".

"tag" is "1ccb6df3", differentiating the users who share a SIP address and make callinvitations with the same Call-ID.

Line 3: To field

It specifies the address of the request recipient is "sip:[email protected]".

Line 4: Cseq field

Line 5: Call-ID field

It is globally unique, identifying a specific invitation.

Line 6: Via field

It indicates the path taken by the request. "SIP/2.0/UDP" specifies the sent protocol, inwhich "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

8/8/2019 01-14 SIP

15/20

14 SIP

HUAWEI CSOFTX3000



sender is "191.169.1.116" and port number is "5061". "branch=z9hG4bkbc427dad6" isthe "branch" parameter, identifying branches when the CSOFTX3000 distributes requestmessages concurrently.

Line 7: Contact field

It indicates subsequent request messages such as BYE can be directly sent to"sip:[email protected]:5061" rather than through the Via field.

Line 8: Max-Forwards field

It specifies that the maximum number of intermediate proxy servers or gateways that therequest message is allowed to traverse is 70.

Line 9: Content-Length field

It indicates the length of the message body.

Line 10: Content-Type field

It indicates the message contains a single message body SDP.

Line 11: an empty line

It indicates that the message header ends and below is the message body described by theSDP.

The following briefs the message body. For details, see SDP-related documents.

v=

o=

s=

c=

t=

m=

a=rtpmap:

14.3.2 Response Message Structure

Figure 14-2 shows the structure of a SIP response message, consisting of:

A status line

A message header

An empty line

A message body

A line feed character distinguishes each parameter line in the message header. Parameters

vary with response messages.

8/8/2019 01-14 SIP

16/20

HUAWEI CSOFTX3000



Figure 14-2Structure of a SIP response messageSIP-

VersionStatus-Code

Reason-Phrase

Call-ID: value

From: value

To: value

Cseq: value

Via: value

Contact: value

Content-Length: value

Content-Type: value

Max-Forwards: value

.......

CRLF

SDP

Statusline

Messageheader

Messagebody

A Status-Line consists of a SIP protocol version, a Status-Code, and its associated textualphrase (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, respectively defining six types ofSIP response messages. For full definitions, see section 14.2.2 "Response Messages".

The parameters in the header of a response message are the same as those in a requestmessage header. For details, see section 14.3.1 "Request Message Structure".

14.4 Introduction to SIP-T

The session initiation protocol for telephones (SIP-T) is an extension of SIP. It is a set of

mechanisms for encapsulating ISUP signaling within SIP. The purpose of SIP-T is to providebetter PSTN-SIP interconnection. There are three call models: PSTN-IP, IP-PSTN, andPSTN-IP-PSTN.

SIP-T adopts SIP message structures and flows. Two techniques, namely, encapsulation andmapping apply to SIP-T.

Encapsulation means that SIP message bodies contain ISUP messages, including two cases:

A SIP message does not carry SDP. ISUP messages are encapsulated within the SIPmessage body, which type is Application/ ISUP.

A SIP message that carries SDP contains multiple message bodies. The type of themessage body with ISUP encapsulated in it is Application /ISUP.

8/8/2019 01-14 SIP

17/20

14 SIP

HUAWEI CSOFTX3000



Mapping includes:

ISUP-SIP message mapping

Gateways must generate a specific ISUP message for each SIP message received.

Conversely, gateways can also generate a specific SIP message for each ISUP message

received. SIP-T specifies the rules that govern the mapping between ISUP and SIPmessages. For example, an IAM must be sent on receipt of an INVITE, a REL for BYE,and so on.

A mapping between ISUP and SIP messages can be as follows:

IAM = INVITE

ACM = 180 RINGING

ANM = 200 OK

REL = BYE

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. SIP-T

defines the procedure for mapping of information from ISUP to SIP. For example, thecalled number in an ISUP IAM must be mapped onto the SIP "To" header field.

14.5 SIP Signaling Procedures

This session does not describe the procedure that the CSOFTX3000 controls media gateways (MGWs)to set up bearers.

14.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 CSOFTX3000 devices. Figure 14-3 shows the flowchart.

8/8/2019 01-14 SIP

18/20

HUAWEI CSOFTX3000



Figure 14-3SIP flowchart of an MOC through SIP trunksBSS CSOFTX3000 CSOFTX3000

CM_SERVICE_REQ

ASS_REQ

ASS_CMP

INVITE

100 Trying

180 Ringing

200 OK

ACK

CLEAR_REQ

CLEAR_CMDBYE

200 for BYE

CLEAR_CMP

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 finds that the outgoing office interacts with the

ingoing office through SIP. At the time, the CSOFTX3000 sends the called office anINVITE containing the calling bearer information in the message body.

5. The called office returns the CSOFTX3000 a 100 Trying, indicating that it receives therequest message and message processing is in progress.

6. The CSOFTX3000 receives a 180 Ringing.

7. If the called subscriber hooks off, the called office sends the local CSOFTX3000 a 200OK, containing the called bearer information in the message body.

8. After the MGW fulfils bearer setup under the control of the local CSOFTX3000, thelocal CSOFTX3000 sends the peer office an ACK, indicating setup of the signaling path.

8/8/2019 01-14 SIP

19/20

14 SIP

HUAWEI CSOFTX3000



9. If the calling subscriber hooks on, the CSOFTX3000 receives a CLEAR_REQ. At thetime, it sends a BYE to the called office and a CLEAR_CMD to the BSS at the callingside. On receipt of the BYE, the called office sends a 200 for BYE to CSOFTX3000.The BSS sends a CLEAR_CMP to confirm the completion of calling party disconnect.

10. If the called subscriber hooks on, the called office sends a BYE to the localCSOFTX3000. On receipt of the BYE, the local CSOFTX3000 returns a 200 for BYE.Meanwhile, it sends a CLEAR_CMD to the BSS at the calling side. The BSS returns aCLEAR_CMP.

14.5.2 SIP-T Signaling Procedure

The following illustrates the call flow of transparency across points of PSTN-SIP

interconnection in terms of the PSTN-IP-PSTN call model. Figure 14-4 shows the flowchart.

Figure 14-4A successful SIP-T procedure (PSTN-IP-PSTN)LS A CSOFTX3000 A CSOFTX3000 B LS B

IAM

ACM

ANM

INVITE

100 Trying

IAM

ACM

180 Ringing

ANM

200 OK

ACK

RELBYE

REL

RLC200 OK

RLC

1. 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 sendsto CSOFTX3000 B.

3. CSOFTX3000 B extracts the IAM from the INVITE and sends the IAM to LS B.

4. CSOFTX3000 B returns CSOFTX3000 A a 100 Trying, indicating that it receives therequest message and message processing is in progress.

5. The called PSTN phone rings. Meanwhile, LS B sends an ACM to CSOFTX3000 B.CSOFTX3000 B preserves the received ACM in a 180 Ringing that sends toCSOFTX3000 A.

8/8/2019 01-14 SIP

20/20

HUAWEI CSOFTX3000



6. CSOFTX3000 A extracts the ACM from the received 180 Ringing and forwards theACM to LS A. LS A receives the ACM. The calling PSTN subscriber hears ring backtones.

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

8. CSOFTX3000 A extracts the ANM from the received 200 OK and forwards the ANM toLS A.

9. CSOFTX3000 A sends an ACK to CSOFTX3000 B, acknowledging receipt of the finalmessage from CSOFTX3000 B in response to the INVITE.

10. At this time, both parties can communicate through an established bidirectional signalingpath.

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 toCSOFTX3000 B.

12. CSOFTX3000 B extracts the REL from the received BYE and forwards the REL to LSB.

13. On receipt of the REL, LS B sends busy tones to the called PSTN subscriber. If thecalling 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 toCSOFTX3000 A.

15. CSOFTX3000 A extracts the RLC from the received 200 OK and forwards the RLC toLS A.

01-14 sip

Documents