Huawei Csoftx3000 Signaling Protocols

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-16 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 02 (2007-01-15)
Huawei Technologies Proprietary
Figures
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 SIP trunks ............................................................................13-18 Figure 13-4 A successful SIPI procedure (PSTN-IP-PSTN) ..........................................................................13-19
ii
Issue 02 (2007-01-15)
Tables
Tables
Table 13-1 Request messages ...........................................................................................................................13-5 Table 13-2 Response messages.........................................................................................................................13-5
Issue 02 (2007-01-15)
iii
13 SIP
13
About This Chapter
The following table lists the contents of this chapter. Section 13.1 Description of SIP 13.2 SIP Message Types 13.3 SIP Message Structure 13.4 SIPI 13.5 SIP Signaling Procedures Describes Application and related terms of the SIP protocol. SIP message types. SIP message structure. Application of SIPI. Examples about the SIP signaling procedures.
SIP
Issue 02 (2007-01-15)
13-1
13 SIP
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 such services as:
z z z z
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:
z z z z z
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 in communications Call setup: sending ring back tones to the called party and establishing call parameters at both 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 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 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 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 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 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
Issue 02 (2007-01-15)
13 SIP
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 sent from 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 a transaction 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 final response 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 a location service to obtain the possible location of a called party beyond the scope of this document. However, the manner in which a SIP server requests location services is beyond the scope of this 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 the message.
Redirect Server
A redirect server performs the following:
z z z
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 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 identifier (URIs) are used within SIP messages to indicate the originator (From), current destination (Request-URI), and final recipient (To) of a SIP request, and to specify redirection addresses (Contact).
Issue 02 (2007-01-15)
13-3
13 SIP
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-param
The components of a SIP URI have the following meanings:

z z z z z z z
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, because the 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 default is UDP. 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. method-param: specifies methods or operations to be used. 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". 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 z z z z z
z z
transport-param user-param method-param ttl-param maddr-param 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 describes the functions of these messages.
13-4
Issue 02 (2007-01-15)
13 SIP
Table 13-1 Request messages Message INVITE Function 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 should specify the media type that it supports and related parameters. The called party should also specify the media type that is supports through the response message. In addition, the called party can specify the media type that it will send. Confirm that the client receives a final response to an INVITE request. ACK messages are used only with INVITE message. BYE CANCEL Indicate that the client wishes to release a call already set up. 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 OPTIONS Register an address with a SIP server. Query a server about its capabilities.
ACK
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 shows the classification of response messages and their meanings. Table 13-2 Response messages Serial No. 1xx Function Informational (provisional), indicating that the request is received and the system continues to process the request Status Code 100 180 181 182 183 2xx Indicating the request is successfully received, understood, and accepted. 200 Message Function Trying Ringing Call is being forwarded Queued Session progress OK
Issue 02 (2007-01-15)
13-5
13 SIP
Serial No. 3xx
Function Redirection, indicating further action requires to be taken in order to complete the request
Status Code 300 301 302 305 380
Message Function Multiple Choices Moved Permanently Moved Temporarily User Proxy Alternative Service Bad Request Unauthorized Payment Required Forbidden Not Found Method Not Allowed Not Acceptable Proxy Authentication Required Request Timeout Gone Request Entity Too Large Request-URI Too Large Unsupported Media Type Unsupported URI Scheme Bad Extension Extension Required Interval Too Brief Temporarily Unavailable Call Leg/Transaction Does Not Exist Loop Detected Too Many Hops Address Incomplete Ambiguous Busy Here Request Terminated
4xx
Client error, indicating the request contains bad syntax or cannot be fulfilled at this server
400 401 402 403 404 405 406 407 408 410 413 414 415 416 420 421 423 480 481 482 483 484 485 486 487
13-6
Issue 02 (2007-01-15)
13 SIP
Serial No.
Function
Status Code 488 491 493
Message Function Not Acceptable Here Request Pending Undecipherable Server Internal Error Not Implemented Not Implemented Bad Gateway Service Unavailable Server Time-out Version Not Supported Message Too Large Busy Everywhere Decline Does Not Exist Anywhere Not Acceptable
5xx
Server error, indicating the server failed to fulfill an valid request
500 501 502 503 504 505 513
6xx
Global failure, the request cannot be fulfilled at any server
600 603 604 606
Both the request and the response messages contain SIP header fields and SIP message fields. SDP message fields are added into SIP messages.
13.3 SIP Message Structure

Both 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.
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 02 (2007-01-15)
13-7
13 SIP
Response header fields Proxy-Authenticate | Retry-After | Server | Unsupported | Warning | WWW-Authenticate
Entity header fields Allow | Content-Encoding | Content-Length | Content-Type | Expires
z z
An empty line indicating the end of the header fields 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 should contain the header field. The message body is optional, and whether to contain the message body is determined by the type of the SIP message and the service.
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 line
Method
Request-URI Call-ID: value From: value To: value Cseq: value Via: value Contact: value
SIP-Version
Message header
Max-Forwards: value Content-Length: value Content-Type: value ....... CRLF SDP 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.
13-8
Issue 02 (2007-01-15)
13 SIP
Methods contain the following request message names:

z z z z z z
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 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 only shows some parameters possibly contained in the message header of a request message.
The following describes some 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, if a user invites 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 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 "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 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. This field is generally in such a format as
From: display-name <SIP-URL>;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.
Issue 02 (2007-01-15)
13-9
13 SIP
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. A CSeq field in a request contains the request method and a decimal sequence number unique within a Call-ID. The initial value of a sequence number is arbitrary. Consecutive request messages that differ in request methods, headers, or bodies but have the same Call-ID must contain monotonically increasing and contiguous sequence numbers. Retransmissions of the same 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 a higher sequence number. A server remembers 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 such a format as
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 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 to receive 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 address as a new Via field before any existing Via fields.
13-10
Issue 02 (2007-01-15)
13 SIP
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 the topmost Via field, the server will transfer the request message to the multicast address listed 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 source address and port number of a request message. In this case, the Via field cannot be relied on to route response messages. To prevent this, a proxy server must check the top-most Via field. If the value of Via field 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 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. 2. 3. Notices the mismatch. Adds a "received" parameter to the Via field of previous hop, containing the address that the packet actually came from. 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 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 none is 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 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:
Via: SIP/2.0/UDP 191.169.1.116:5061;ttl=16;maddr=191.169.10.20;branch=a7c6a8dlze
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 communications.
Issue 02 (2007-01-15)
13-11
13 SIP
INVITE and ACK request messages contain Contact fields indicating from which location 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. This field is generally in such a format as
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 only applicable 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 how long a uniform resource identifier (URI) is valid. This parameter 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: <Sip:66500002@191.169.1.110:5061>;q=0.7;expires=3600
Max-Forwards
This field limits the number of times for which 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 (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. This field is generally in such a format as
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. If no body is present in a message, the Content-Length header field must be set to zero.
13-12
Issue 02 (2007-01-15)
13 SIP
This field is generally in such a format as

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:
Content-Type: application/sdp
Expires
This field gives the time after which the message content expires.
13.3.2 Request Message Examples

An example of SIP request message is:
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 details the example:

z
Line 1: Request-Line The Method is INVITE, followed by the Request-URI "sip:66500002@191.169.1.110" and SIP-Version "2.0".
Line 2: From field It indicates the address of the request initiator is "sip:44510000@191.169.1.116". "tag" is "1ccb6df3", differentiating the users who share a SIP address and make call invitations with the same Call-ID.
Line 3: To field It specifies the address of the request recipient is "sip:66500002@191.169.1.110". Line 4: Cseq field
Issue 02 (2007-01-15)
13-13
13 SIP
z
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, 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, identifying branches when the CSOFTX3000 distributes request messages concurrently.
Line 7: Contact field It indicates subsequent request messages such as BYE can be directly sent to "sip:44510000@191.169.1.116: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 the request 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 the SDP.
z z z
The following briefs the message body. 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:
z z z z
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.
13-14
Issue 02 (2007-01-15)
13 SIP
Figure 13-2 Structure of a SIP response message

SIPVersion ReasonPhrase Status line
Status-Code Call-ID: value From: value To: value Cseq: value Via: value Contact: value
Message header
Max-Forwards: value Content-Length: value Content-Type: value ....... CRLF SDP Message 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, respectively defining 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 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 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
Issue 02 (2007-01-15)
13-15
13 SIP
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, indicating to send the ringing tone 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, 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 9th lines: 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
The 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 SIP message bodies contain ISUP messages, including two cases:
z z
A SIP message does not carry SDP. ISUP messages are encapsulated within the SIP message body, which type is Application/ ISUP. 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.4.3 Mapping
ISUP-SIP message mapping
SIPI specifies the rules that govern the mapping between ISUP and SIP messages. 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:
z z z
IAM = INVITE ACM = 180 RINGING ANM = 200 OK
13-16
Issue 02 (2007-01-15)

z z
13 SIP
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. SIPI defines the procedure for mapping of 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 CSOFTX3000 devices. Figure 13-3 shows the flowchart.
Issue 02 (2007-01-15)
13-17
13 SIP
Figure 13-3 SIP flowchart of an MOC through SIP trunks

BSS CSOFTX3000 CM_SERVICE_REQ CSOFTX3000
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 CSOFTX3000 devices is as follows: 1. 2. 3. 4. An ordinary mobile subscriber initiates a CM_SERVICE_REQ. The CSOFTX3000 sends an ASS_REQ to the BSS. The BSS returns an ASS_CMP. 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 an INVITE containing the calling bearer information in the message body. The called office returns the CSOFTX3000 a 100 Trying, indicating that it receives the request message and message processing is in progress. The CSOFTX3000 receives a 180 Ringing. If the called subscriber hooks off, the called office sends the local CSOFTX3000 a 200 OK, containing the called bearer information in the message body.
5. 6. 7.
13-18
Issue 02 (2007-01-15)
13 SIP
8. 9.
After the MGW fulfils bearer setup under the control of the local CSOFTX3000, the local CSOFTX3000 sends the peer office an ACK, indicating setup of the signaling path. If the calling subscriber hooks on, the CSOFTX3000 receives a CLEAR_REQ. At the time, it sends a BYE to the called office and a CLEAR_CMD to the BSS at the calling side. 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 local CSOFTX3000. 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 a CLEAR_CMP.
13.5.2 SIPI 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 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 200 OK ANM ACK ANM
REL
BYE REL RLC
RLC
200 OK
Issue 02 (2007-01-15)
13-19
13 SIP
The procedure for transparently transmitting the PSTN message through SIPI is as follows: 1. 2. 3. 4. 5. A PSTN subscriber dials, LS A sends an IAM to CSOFTX3000 A. CSOFTX3000 A preserves the received IAM in an INVITE message body that it sends to CSOFTX3000 B. CSOFTX3000 B extracts the IAM from the INVITE and sends the IAM to LS B. CSOFTX3000 B returns CSOFTX3000 A a 100 Trying, indicating that it receives the request message and message processing is in progress. 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 to CSOFTX3000 A. 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 ring back tones. 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. CSOFTX3000 A extracts the ANM from the received 200 OK and forwards the ANM to LS A. CSOFTX3000 A sends an ACK to CSOFTX3000 B, acknowledging receipt of the final message from CSOFTX3000 B in response to the INVITE.
6.
7.
8. 9.
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 receipt of 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
Issue 02 (2007-01-15)

Huawei Csoftx3000 Signaling Protocols

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Huawei Csoftx3000 Signaling Protocols

Uploaded by

Copyright:

Available Formats

HUAWEI CSOFTX3000 Signaling Protocols

Huawei Technologies Proprietary