0% found this document useful (0 votes)

210 views131 pages

Sip Conformance Test List: Revision History Document Number: 803-93732-T005-DF Date Authors Comments

This document provides a comprehensive set of test cases for SIP conformance testing. It lists 59 test cases with objectives to validate various SIP functions supported by the MGC 5020, including acting as a UAC, UAS, stateful/stateless proxy, and B2BUA. The test cases cover call flows, handling of SIP methods and headers, responses to errors, and support for features like LNP. The test environment diagram shows ITE SIP endpoints connecting via SIP links to the MGC shelf under test.

Uploaded by

Sujatha

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLS, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

210 views131 pages

Sip Conformance Test List: Revision History Document Number: 803-93732-T005-DF Date Authors Comments

Uploaded by

Sujatha

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as XLS, PDF, TXT or read online on Scribd

You are on page 1/ 131

SIP CONFORMANCE TEST LIST

REVISION HISTORY
Document Number: 803-93732-T005-DF
Date Authors Version Comments
19-Jun-07 Jyothi Laxmish 0.1 Initial Draft
Vimala Suresh
Nirmal

Scope:
This document addresses the comprehensive set of test cases identified for SIP Conformance Test
suite.

References:

[1] TRS - SIP Basic Call ED-01 215-95207-9JAAA-DT

{2} TRS - SIP_ISUP INTERWORKING ED-01 215-87116-9JAA-DT
[3] SIP - UA 01P01 803-93491-T007-DF
[4] SIP - Redirect Server 01P01 803-93491-T008-DF
[5] SIP - Proxy Server 01P01 803-93491-T009-DF
[6] Alcatel -SIP Conformance test list 01P01 803-93439-T200-DF

Traceability:
As mentioned in SIP-BASIC and SIP_ISUP Interworking sheets.

Test Environment:

IP/ SIP Link

ITE SIP 1

MGC 5020

(Shelf 16)

ITE SIP 2
IP/ SIP Link
Traceability used indicates the section numbers from TRS [1]
TC # OBJECTIVES

1 Establish a basic SIP-SIP call. Verify that MGC acts like UAC and UAS.
INVITE is sent from originator with via and contact headers having
FQDN. Verify that in terminator INVITE, VIA and contact header fields
are presented in IPV4 address format. This verifies that MGC accepts
2 FQDN for incoming invite and supports only IP addresses.
To verify that 5020 MGC dynamically decides for each request either
3 take the role of stateful proxy,stateless proxy and Register.
SEND an INVITE and verify 100 TRYING response is received from
4 MGC. This verifies that MGC acts as a stateful proxy.
SEND an OPTIONS method and verify 200 OK is received from MGC.
5 This verifies that MGC acts as a stateless proxy.
Establish a basic SIP - SIP call and verify that 5020 acts as a B2BUA and
6 following methods are supported: INV, ACK, BYE.
Send an INVITE and CANCEL. Verify that 200 OK is received and call
7 routing is not processed further.
Establish a basic call. Send 1xx response with request URI from the
8 terminator. Verify that response is ignored.
Configure more than one outbound proxy list in MGC. Send an INVITE
and verify that MGC takes this pre loaded route configured for the
9 outbound proxy.
Establish an LNP call. Verify that INVITE for the proted number has hex
10 digit D in the request URI.
Send an INVITE with request URI with format D xxx NSN or XXXX.
11 Verify that call scenario continues.
Send an INVITE with request URI containing domain names in the host
part of the URI. Verify that call scenario continues and DNS query is
12 used for routing
Send an INVITE containing tel-URI in the To header and verify that
13 proper error message is received.
Send an INVITE with TO header with format D xxx NSN or XXXX.
14 Verify that call scenario continues.
Send an INVITE with TO header containing domain names in the host
15 part of the URI. Verify that call scenario continues
Send an INVITE with FROM header with format D xxx NSN or XXXX.
16 Verify that call scenario continues.
Send an INVITE with FROM header containing domain names in the
17 host part of the URI. Verify that call scenario continues
Send an INVITE with FROM header with format +CC NSN for an
18 internation call. Verify that call scenario continues.
Send an INVITE with Max-forwards=0 and verify that MGC sends a 483
19 response.
Establish a basic SIP-SIP call. Verify that terminating INVITE has orig-
20 sub, term-sub, orig-tg and term-tg in VIA header.
Send an INVITE with CONTACT header with format +CC NSN for an
21 internation call. Verify that call scenario continues.
Send an INVITE with CONTACT header containing domain names in
22 the host part of the URI. Verify that call scenario continues
Send an INVITE with CONTACT header with format D xxx NSN or
23 XXXX. Verify that call scenario continues.
Send an INVITE with SUPPORTED header and verify that invite is
24 processed successfully.
Make the SIP/IP link inactive. Verify that request sent are rejected with
25 503 error response for transaction layer errors.
To verify that MGC shall discard the responses,if more than one Via
26 header field present in the response,

Send an INVITE with via header with domain name in the host part.e.g-
alcatel-lucent.com:5060.verify that MGC supports this via header.Verify
27 that terminating INVITE contains the via header with Ip address.
From terminator send 301/302 response. Verify that MGC proceses it
sucessfully and also verify that new request formulated by MGC is based
28 on redirect request.
From terminator send 300,305,380 responses and verify that MGC sends
29 a appropariate error response.
Send an INVITE with 2 Contact header.The first contact header is
cofigured such a way that MGC should fail to reach this.Configure the
second header which is reached by MGC.Verify that the 5020 MGC
30 responds with the second next contact address.
Send a 302 response and verify that request originted by MGC has same
31 FROM, TO and CALL-ID.
Send two different INVITE messages one after other.Verify that 5020
MGC accepts both the invite and processes.This verifies that 5020
32 supports SIP Requests that are reattempted is considered as failures.
Send an INVITE with the format RURI sip:user@host?subject=foo&call-
Info=<http://www.foo.com/>.Verify that 5020 MGC gives proper
response.This verifies that 5020 supports appending of HTTP URL to
33 Call-Info header field values if required.
Send an INVITE with some malformed header which are optional.Verify
that 5020 MGC ignores malformed header fields that are not necessary
34 for processing requests.
Send an INVITE with unrecongized header field in the To header
field.To verify that the 5020 MGC acting as a UAS shall accept received
requests with an unrecognized URI scheme in the To header field. The
35 MGC as an UAS shall not reject it with 403.
Send an INVITE wirh R Uri with LNP ( hex digit “D” shall be in the
number string of the user part of the URI.) verify that 5020 MGC acceps
36 and gives response.
Send two same INVITE messages one after other.Verify that MGC issues
482 error repsonse when FROM, CALLID and CSEQ of a request
37 matches that of an ongoing transaction.
Send an Invite with Require header and verify that 5020 MGC accepts
38 and gives 100 trying response.
Make a sip to sip call.Send an INVITE without Require and Proxy
require header.Send Ack(200 O.K) with Require and proxy require
39 header. 5020 Just ignores these require and proxy require header.
Make a sip to sip call.Send an INVITE with Require and Proxy require
header.Send Ack(200 O.K) with Require and proxy require header. 5020
40 processes these require and proxy require header.
Send INVITE with Content-Disposition header.Verify that 5020 sends
41 100 trying response.
Send an INVITE with Content-Language header.Vierify that 5020
42 MGC gives 100 trying response.
Send an INVITE without the desired extension required for processing.
43 Verify that 421 error response is issued.
Send non-INVITE request to 5020 MGC.verify that 1xx responses are
not generated by the MGC.This verifies that Provisional responses are
44 generated only for the INVITE.
Send an INVITE to 5020 MGC.Verify that the MGC shall not add a TO
45 tag in the 100 Trying response.
Verify that MGC does not generate any 3xx responses since it does not
46 act like a redirect server.
Send an INVITE .To verify that 5020 MGC must not send Provisitionl
47 (1xx) responses if it is a STATELESS Proxy.
Send an INVITE.To verify that 5020 MGC must not retransmit responses
48 if it is a stateless
49 To verify 5020 MGC must ignore ACK responses (stateless)
50 To verify 5020 must ignore CANCEL (stateless)
Make a SIP to SIP call.Don’t send an ACK.Verify that 5020 MGC gives
51 a 408 REQ Timeout.
Send an INVITE and then CANCEL.Verify that the MGC should send a
52 200 O.k for the CANCEL.
To verify the registrar function supported by the MGC shall be co-
53 located with the proxy function supported by the MGC.

Send an OPTIONS method to MGC.Verify that 5020 Respond with 200

54 O.K and also verify that message body is not included in the response..
Send an OPTIONS messages from originator with contact header and
ACCEPT field. Verify that OPTIONS messages when farwarded to
55 terminator does not have accept and contact header field.

Send any appropriate 4xx or 5xx repsonse from terminator for the options
56 messages. Verify that the same is farwarded to the orginator by MGC.
Make an SIP to SIP call.Don’t send 180 ringing from terminator.MGC
57 shall release a call.
Make a sip to sip call. Send an INVITE and ACK with C-seq values 1,2
respectively.MGC accepts and the call is through.This verifies that MGC
supports If the CSeq number is higher than the remote sequence number
58 by more than one.
Send an INVITE and do not send any repsonse from the terminator.
59 Verify that 408 is issued.
Send an INVITE with SDP and without content-type.(ex application
60 /SDP) .5020 MGC responds with 488 Not Acceptable here.
Establish a SIP to SIP call. When the call is ongoing, verify that MGC
61 shall not generate any Re-INVITE.
Establish a SIP to SIP call. When the call is ongoing, send a Re-invite
with and without SDP from originator and verify that MGC sends the Re-
INVITE to the terminator. Also verify that Alert-Info header or a body
62 with Content-Disposition alert is not added to the Re-INVITE
Do not send a response for the Re-invite from terminator. Verify that the
63 MGC attempt the Re-INVITE once more, if the call is not released.

If the new session description is acceptable, the MGC as a UAS shall

64 reject it by sending a 488 response and a Warning header is not included.
Verify that MGC as a UAS shall not generate a 180 Ringing for a Re-
65 INVITE.
Send an 100 TRYING with TO TAG from terminator. Verify that call is
66 released with BYE from MGC.
To verify that the MGC as a UAC is receiving a 2xx and sending a
67 CANCEL at the same time, shall sent a BYE to the UAS..
To verify that MGC should not terminate the session for a confirmed
68 dialog until it has received an ack for its 2xx response.
69 To verify that 5020 MGC should not send a BYE to a early dialog.
To verify that 5020 MGC sends a 403 Forbidden if the UAC reject a call
70 before its answered.
71 To verify that 5020 MGC rejects BYE sent without tags.
To verify that 5020 MGC supports the client transaction (in the MGC)
shall inform the TU that a transport failure has occurred, and the client
72 transaction shall transition directly to Terminated state.
Send an INVITE messages with Via as mandatory header field and verify
73 that a branch parameter in unique across the calls.
To verify that 5020 MGC supports backward compatibility for branch
74 parameter.(rfc 2543)

To verify The 5020 MGC sending a request over TCP and receiving an
75 ICMP Not Supported or TCP connection reset, shall not retry using UDP.

Send an INVITE messages with a token parameter maddr in the route and
76 record route header field and verify that the MGC should not support it.
To verify that 5020 MGC as a client supports for TCP transport must be
prepared to receive responses on the source IP addresses from which the
77 request is sent.
Send an INVITE message to MGC, in media parameter set the transport
78 as TCP and verify that UAC receives the response.
To verify that 5020 disgards the response if any mismatch found in the
79 "sent-By " parameter of Request.
To verify that the 5020 MGC shall be prepared to receive requests on any
IP address, port and on either UDP or TCP transport combination.SIPS
80 shall not be supported by the MGC.

Send an INVITE message to MGC without mandatory header filds like

81 To,From,Via,Csec and verify that MGC shall generate 400 bad request.
To verify that the 5020 MGCsupports transport layer in the MGC shall
82 inform the transport user of a failure in sending.
Verify that when an INVITE message is sent by the UAC, MGC should
83 never send 401 response to UAC.
Send an INVITE message with IPv4 in orginator of the message body
and check the syntax of the message, Verify that MGC proceds the
84 message sucessfully.
Send an INVITE message with "lr" token in the route and record reoute
85 header field and verify that it should be supported by the MGC.

Verify that when INVITE is send to MGC with Route and Record-Route
86 header the MGC should be able to proceed the request sucessfully.
To verify The MGC shall use the parameter value phone . If the MGC
receives a SIP URI without the phone parameter shall interpret the part
before the @ as a telephone number, if the user string is a telephone
87 number.
Send an INVITE to MGC with the header fields and check the syntex of
the message body and verify the accuracy of requested descriptive header
88 fields.
Send an INVITE with the Tel URI in TO header and verify that the MGC
89 issues proper error response.
Send an INVITE with the requested URI as Tel URI and verify that the
90 MGC should support the syntax of the message sucessfully.
Send an INVITE to MGC with the Require,Supported,Proxy-
require,Unsupported header fields and verify that the option Tags are
91 supported by MGC.
Send an INVITE to MGC and verify that the required Tag parameters are
added by the MGC in From and To header fields while the message
92 passes through it.
Send an INVITE to MGC with Call-ID header field and verify that the
93 MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Call Info header field and verify that the
94 MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with contact header field and verify that the
95 MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Content-dispositon header field and verify
96 that the MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Content-encoding header field and verify
97 that the MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Content-language header field and verify
98 that the MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Content-type header field and verify that
99 the MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with C-seq,Date header field and verify that
100 the MGC shall sucessfully procedes the requested message.
Send an INVITE to MGC with Error-info,Expires,From,Max-
forward,Min-expires header field and verify that the MGC shall
101 sucessfully procedes the requested message.
Send an INVITE to MGC with Mime-version,organisation header field
and verify that the MGC shall sucessfully procedes the requested
102 message.
Send an INVITE message with domain name as alcatel-lucent.com in the
request URI and verify that MGC shall support the domain names in the
103 host part.
Send an INVITE message to MGC with multiple Route header and verify
that MGC shall support the top-most Route header with AS IP address
104 while processing the message to the next entity.
Send an INVITE message with domain name as alcatel-lucent.com in the
105 Route header and verify that MGC shall support the domain names.
To verify that the second Route-header shall be sent by the MGC with
the own IP address and the original dialog-ID.(e.g. odi@MGC_IP-
address:5060;lr).The coding of the odi uses the last bit as call side flag:
106 xxxx xxx0 orig-half call xxxx xxx1 term half call.
Send an INVITE message with the IP-address of MGC and Route header
along with the orginal dialog-ID, Verify that MGC should support the
107 same.
If the AS initiates a call, the MGC shall receive the Route header with the
IP-address of the MGC without original dialog-ID oid but with 'orig'
108 parameter (e.g. MGC_IP-address:5060;lr;orig)
Send 1xx response(100,180) with SDP parameter to MGC.Verify that
109 MGC process the response.
To verify that 5020 MGc shall support 181 call is being forwarded
110 response. Note 5020 is not a Redirect server.
To verify that the 5020 MGC shall not generate 182 response
code, but be transparent as a proxy I.e send 182 response from terminator
111 and verify that the same is farwarded.
Send 300 multiple choice from terminator.Verify that MGC processes it
112 successfully.
To verify that The 5020 MGC as a UAS shall support 301 Moved
Permanently response.The MGC shall support rerouting either as a
proxy or if rerouting shall take place in the TDM part (in this case only
113 the E.164 number of the Contact header will be used by the MGC).
Send a 302 moved temporarily from terminator with maddr/host
parameter of conatct header is PSTN number. Verify that new call is not
114 orignated by MGC fro the ported number.
Send a 302 moved temporarily from terminator with maddr of conatct
header is SIP UA. Verify that new call is orignated by MGC for the
115 ported number using maddr.
Send a 302 moved temporarily from terminator without maddr of conatct
header is SIP UA. Verify that new call is orignated by MGC for the
116 ported number using host parameter.
For Request failure 4xx ,to verify that the 5020 MGC as a UAC shall not
117 retry the same request without modification.
To verify thst 5020 MGC shall generate the 403 response as a UA
118 according to Q.1912.5
Send INVITE with incorrect Request URI.Verify that MGC sends 404
119 Not Found to originating UA.
Send INVITE with Request URI which is not available .Verify that MGC
120 sends 410 Gone to originating UA.
Send INVITE message with large SDP body. Verify that MGC sends 413
121 Request Entity Too Large.
Send INVITE message with unsupported media type in SDP. Verify that
122 MGC sends 415 Unsupported Media Type.
Send INVITE message with Min-Expires=0 in Contact header.Verify that
123 MGC sends 423 Interval Too Brief responses.
Send 480 from terminating UA.Verify that MGC process it and send it to
124 originating UA.
Send a message with different transaction ID or dialog ID.Verify that
125 MGC sends 481 Transaction doesn’t exist.
Send two invite message with same VIA header including branch. Verify
126 that MGC does not generate 482 loop detected error response.
Send an INVITE message with Max-Forward header set to "0".Verify
127 that MGC sends 483 Too Many Hops
Send INVITE message with incomplete Request URI.Verify that MGC
128 sends 484 Address Incomplete responses.
Send INVITE message with ambiguous Request URI.Verify that MGC
129 sends 484 Ambiguous responses.
Generate a scenario where UA B & C are in a call.Then send an INVITE
message with address of UA B in Request URI.Verify that MGC sends
130 486 Busy here.
Send 486 from terminating UA.Verify that MGC process it and send it to
131 originating UA.
Send 491 from terminating UA.Verify that MGC process it and send it to
132 originating UA.
Send 493 from terminating UA.Verify that MGC process it and send it to
133 originating UA.
Send 500 response from terminating UA to MGC.Verify that MGC sends
134 it to originating UA
Trigger terminating UA to send 501 response to MGC.Verify that MGC
135 sends it to originating UA

To verify that 5020 MGC shall support 502 Bad Gateway responses.The
136 MGC shall generate the 502 response as a UA according to Q.1912.5.
Trigger terminating UA to send 503 response to MGC.Verify that MGC
137 sends it to originating UA
To verify that 5020 MGC shall support as a proxy shall forward the 503
138 if received.
To verify that 5020 MGC shall support 503 Service Unavailabe response
and a UAS shall not indicate in a Retry-After header field when the client
139 shall retry the request.
140 To verify that 5020 MGC shall support 504 Server Time-out response.
Send an INVITE method with v=3 in SDP.Verify that MGC sends 505
Version Not Supported response to originating UA received from
141 terminating UA
142 Send a lengthy INVITE .Verify that MGC sends 513 response.
Verify that MGC sends 600 Busy Everywhere response to originating
143 UA after receiving from terminating UA.
Verify that MGC sends 603 Decline response to originating UA after
144 receiving from terminating UA.
Verify that MGC sends 604 Doesn’t Exist Anywhere response to
145 originating UA after receiving from terminating UA.
Send the INVITE with unsupported media,bandwidth.Verify that MGC
sends 606 Not acceptable to originating after receiving from terminating
146 UA
Send an INVITE method containing user credential in Proxy-
147 Authorization header field.Verify that MGC process the method.
Veirfy that icid value more than 29 characters is rejected by mgc and
148 proper error is issued
Verify that icid value with format machineid-
149 yyyymmddhhmmssqqqqqqqq is accepted and call scenario proceeds
150 Verify that a valid REFER method is routed to the next HOP address
Verify that SDP can be exchanged using UPDATE method before final
151 response
Verify that SDP cannot be exchanged using UPDATE method after final
152 response I.e. proper error response is issued
Verify that UPDATE with valid session expires value is processed
153 properly and the session is kept alive
Verify that UPDATE with invalid session expires value is rejected with
154 proper error response (422 - session interval too small)
Verify that number format in history info header of the invite message is
155 in the format +CC NSN. Verify that invite is processed successfully.
Create a forking scenario and send a 200 OK from any one branch.
Generate a CANCEL with reason header field as
Reason:SIP;cause=200;text="call completed elsewhere" and verify that
156 cancel message is accepted by MGC.
SDP received in 200 OK is not acceptable. UAC sends a ACK and BYE
with reason header as Reason:SIP;cause=488;text=not acceptable here.
157 Verify that bye is accepted.
SS7 to SIP call. SS7 user releases first. Verify that BYE is generated with
158 reason header as Reason:Q.850;cause=16;text=terminated
SS7 to SIP call . IAM with calling party number presentation allowed is
sent. Verify that INVITE is received with P-asserted ID=CGPN and
Privacy=none (assumption:p-asserted / privacy header is enabled in SIP
159 profile)

SS7 to SIP call . IAM with calling party number restricted is sent. Verify
that INVITE is received with P-asserted ID=CGPN and Privacy=id
160 (assumption:p-asserted / privacy header is enabled in SIP profile)
SS7 to SIP call . IAM with calling party number presentation allowed is
sent. Verify that INVITE is received without P-asserted ID
161 (assumption:p-asserted / privacy header is disabled in SIP profile)
SS7 to SIP call . IAM with calling party number restricted is sent. Verify
that INVITE is received without P-asserted ID (assumption:p-asserted /
162 privacy header is disabled in SIP profile)
Send an invite with P-asserted Identity and verify that same is farwarded
163 to the terminating side.
SIP to SIP call. Send an invite with P-preferred identity and verify that
same is reflected in the P-asserted ID and privacy as ID in the
164 terminating invite and also the P-preferred header is removed

Simulate a CALL TRANSFER - Attended scenario. Verify that INVITE

165 with REPLACES header is processed successfully to replace the dialog
Simulate a CALL TRANSFER - attaended scenario. Verify that INVITE
with REPLACES header that has a dialog that does not exit is rejected
166 with proper error response.(481)
Simulate a CALL TRANSFER - attaended scenario. Verify that INVITE
with REPLACES header that has semantic error is rejected with proper
167 error response.(400)
Send an invite with supported : replaces header and verify that call
168 scenario continues
Simulate a CALL TRANSFER - attaended scenario. Verify that INVITE
with REPLACES header that has an early-only flag for a confirmed
169 dialog is rejected with proper error response.(486)
Build any message such as PRACK, NOTIFY, SUBS etc.. With replaces
170 header and verify that it is rejected with proper error response
send an invite with tel URI with trkgrp and trunk context parameters in
contact header. Verify that invite is not processed and proper error
171 message is issued
send an invite with SIP URI with trkgrp and trunk context parameters in
contact header. Verify that invite is processed and call scenario
continues. Also verify that terminating invite has destination trkgrp
172 attribute in contact header field.
send an invite with SIP URI with trkgrp and trunk context parameters in
lowercase in contact header. Verify that invite is processed and call
173 scenario continues.
send an invite with SIP URI with trkgrp and trunk context parameters in
upper case in conatct header. Verify that invite is rejected with error
174 response .
send an invite with SIP URI with trkgrp and trunk context parameters in
lower case in contact header. Trunk context should be either domain/sub
175 domain/host. Verify that invite is processed successfully
send an invite with SIP URI with trkgrp and trunk context parameters in
lower case in contact header. Trunk context as global number. Verify that
176 invite is rejected with proper error response
send an invite with SIP URI with trkgrp and trunk context parameters in
lower case in R_URI. . Verify that invite is processed successfully and
177 the trkgrp details are ignored
SIP to SS7 call. Send an invite with all supported cpc values (inlcuding
16 ISUP) and verify that call is processed and IAM with respective CPC
178 value is received in terminator

SIP to SS7 call. Send an invite without cpc value. verify that call is
179 processed and IAM with CPC value as ordinary is received in terminator
SIP to SS7 call. Send an invite with two diff cpc value in FROM and P-
asserted identity. verify that call is processed and IAM with CPC value
180 as defined in P-asserted identity is received in terminator
SIP to SS7 call. Send an invite with cpc value in FROM and without cpc
in P-asserted identity. verify that call is processed and IAM with CPC
181 value as defined in FROM is received in terminator
Verify that an INVITE having content-type as uninterpreted binary data
must have the subtype as "application/octet-stream" and the call
182 scenario continues.
Verify that an INVITE having content-type as any PostScript material
must have the subtype defined as "application/PostScript" and the call
183 scenario continues.
Verify that an INVITE can have content-type as different applications
such as spreadsheets,data for mail-based scheduling systems,languages
for "active"(computational) messaging and word processing formats and
184 the call scenario continues.
Verify that an INVITE having content-type as "application/PostScript"
and active messaging may have security considerations and the call
185 scenario continues.
Verify that when an INVITE having content-type as "text" with subtypes
as "plain"/"enriched text"/"richtext" etc is sent, an error
186 response(406/415/420/485/488/501)is sent by the MGC 5020.
Verify that when an INVITE having content-type as "image" with
subtypes as "jpeg"/"gif" is sent, an error
187 response(406/415/420/485/488/501)is sent by the MGC 5020.
Verify that when an INVITE having content-type as "audio" with
subtypes as "basic" is sent, an error
188 response(406/415/420/485/488/501)is sent by the MGC 5020.
Verify that when an INVITE having content-type as "video" with
subtypes as "mpeg" is sent, an error
189 response(406/415/420/485/488/501)is sent by the MGC 5020.
Verify that an INVITE having content-type as multipart
("application/mixed") contains a generic mixed set of parts and the call
190 scenario continues.
Verify that when an INVITE having content-type as multipart
("application/alternative") data which can be represented in multiple
formats is sent ,an error response(406/415/420/485/488/501)is sent by
191 the MGC 5020.
Verify that an INVITE having content-type as multipart
("application/parallel") parts which are intended to be viewed
simultaneously is sent, an error response(406/415/420/485/488/501)is
192 sent by the MGC 5020.
Verify that an INVITE having content-type as multipart
("application/digest") multipart entities in which each part has a default
type of "message/rfc822" is sent, an error
193 response(406/415/420/485/488/501)is sent by the MGC 5020.
Verify that an INVITE having content-type as message ("application/rfc
822") contains encapsulated contents as a rfc 822 message itself and the
194 call scenario continues.
Verify that an INVITE having content-type as message
("application/partial") contains partial rfc 822 message and is able to
permit the fragmented transmission of bodies that are too large to be
195 passed through the transport facilities in one piece
Verify that an INVITE can have content-type as "application/ISUP" and
196 the call scenario continues.(reference rfc 3204)
Verify that an INVITE treats any unrecognised subtypes in content-type
197 as "application/octet-stream" and the call scenario continues.
Verify that in an INVITE the "multipart" Content-type header field must
support the parameter "boundary"=Alcatel-boundary and must look
like---Content- Type: multipart/ mixed; boundary=Alcatel-boundary
198 and the call scenario continues.
Verify that in an INVITE the "multipart" Content-type header field
doesnt use an linear whitespace after the boundary line and the call
199 scenario continues.
Verify that in an INVITE the "multipart" Content-type header field
doesnt use hyphens as to define the boundary delimeter line(Instead "="
200 should be used) and the call scenario continues.
Verify that if in an INVITE the "multipart" Content-type header field
uses any colons/semi-colons/comma etc in between a boundary
parameter unless the latter is enclosed by "", then an error response is
201 being sent by the MGC 5020.

Verify that in an INVITE any unrecognised multipart subtypes be treated

202 as Content-type "multipart/mixed" and the call scenario continues.
Verify that in an INVITE the Content-type "multipart/mixed" is used
when the body parts are independent and need to be bundled in a
203 particular order.
Verify that in an INVITE the Content-type treat unrecognised subtypes of
"message" as equivalent to "application/octet-stream" and the call
204 scenario continues.
Verify that in an INVITE Content-type, subtypes of "message" intended
for use with email should be restricted to "7bit" encoding and the call
205 scenario continues.
Verify that in an INVITE Content-type, a subtype other than "message"
is used if restriction to "7bit" is not possible and the call scenario
206 continues.
Verify that in an INVITE Content-type ,the media type value starts with
prefix "X-" for any format without a rigorous and public definition(i.e
207 any private format) and the call scenario continues.
Verify that in an INVITE Content-type ,the media type value doesnt start
208 with prefix "X-" for any publicly specified values.
1. Verify that the SDP in an INVITE is not encrypted and no
209 encryption keys are announced(i.e all the sessions are public).
Verify that the SDP in an INVITE doesn't contain any URI for obtaining
210 more informations about the session.
Verify that the SDP in an INVITE has version "v" parameter with the
211 protocol version as theValue.
Verify that the SDP in an INVITE has origin "o" parameter with the user
name as "-"(no user id should be present)and session identifier as the
values whereas the network is IP4 and supported by the dotted decimal
212 values.
Verify that the SDP in an INVITE has session"s" parameter with session
213 name s=SDP data as the value.
Verify that the SDP in an INVITE may have connection information "c"
parameter with the connection information as the value whereas the
network is IP4 and supported by the dotted decimal values and the IP
214 address is unicast(multicast Address is not
Verify that the SDP in an INVITE has time "t" parameter with t= 0 0 as
215 theValue.
Verify that the SDP in an INVITE may have the bandwidth information
216 "b" parameter with b=AS:<bandwidth> as the value.
Verify that the SDP in an INVITE has media "m" parameter with media
name and transport address as the value with the format a=audio 4010
217 RTP/AVP 8.
Verify that the SDP in an INVITE may have the attribute "a" parameter
with a=ptime:x, where x is the packetization time in ms, or a=rtpmap:0
218 0 PCMA/8000. as the value.

219 Verify tht the SDP in INVITE doesnt support k-line for encryption keys.
Verify that the SDP in an INVITE supports the SDP grammar(reference
220 Appendix A rfc 2327).
221 Verify that the INFO request can be sent in between an existing call.
Verify that the UAS replies a final response(2xx/4xx/5xx/6xx) to an
222 INFO request.
Verify that the UAS replies with 481 Call Leg/Transaction Does Not
Exist message if the INFO request does not match any existing call
223 leg.
Verify that the UAS replies with 415 Unsupported Media Type message
to a INFO request which contains a body that the server does not
224 understand.
Verify that the UAS server replies with an error response(4xx/5xx) to an
INFO having a body which changes the Call state or Session state of
225 the call.
Verify that an INFO request with a message body can be sent to the UAS
through MGC 5020 and the UAS replies with a final
226 response(2xx/4xx/5xx/6xx) to it.
227 Verify that an INFO request can be cancelled by UAC/proxy.
Verify that an UAS receiving a CANCEL for an INFO request responds
to the INFO with a "487 Request Cancelled" response if a final
response has not been sent to the INFO and then behave as if the
228 request were never received.
Verify that when INFO is sent to the redirect server,it replies with 405
229 Method not allowed.
Verify that the the C-Seq in INFO messages increments with a new
INFO message but it is not counted to determine the sequence of INFO
230 information.
Verify that when an INVITE with Supported/Require:100Rel is sent ,the
MGC 5020 as a UAS sends 1xx provisional responses to the UAC once
in every two and half minutes till PRACK is not sent to the UAS. half
231 minutes.
Verify that the MGC 5020 uses the reliable provisional responses for
232 extending transactions.
Verify that the reliable provisional responses contain a RSeq header field
and the value of the header field for the first reliable provisional
response in a transaction MUST be between 1 and 2**31 - 1 and
233 should be chosen uniformly in this range.
Verify that the RSeq numbering space is within a single transaction and
Provisional responses from the 5020 MGC for different requests shall
234 use the same values for the RSeq number.
Verify that when a Reliable provisional response is sent with a body, the
235 MGC 5020 processes the same and doesnt discard the response.
Verify that no more retransmission of reliable provisional response to the
MGC 5020 is possible when a matching PRACK is received by the
MGC.(A matching PRACK is defined as one within the same dialog as
236 the response, and whose method, CSeq-num, and
Verify that if a reliable provisional response is retransmitted for 64*T1
seconds without reception of a corresponding PRACK, the 5020 MGC
237 as the UAS SHOULD reject the original request with a 5xx response.
Verify that after the first reliable provisional response for a request has
been acknowledged, the 5020 MGC as UAS shall send additional
238 reliable provisional responses.
Verify that the 5020 MGC as UAS shall not send a final response to the
initial request before having received PRACKs for all unacknowledged
239 reliable provisional responses.
Verify that the 5020 MGC as UAS shall not continue to retransmit the
unacknowledged reliable provisional response if it has already sent a
240 final response when reliable responses are still unacknowledged.
Verify that a PRACK with message body can be sent and not discarded
241 by the MGC with an error response.
Verify that the MGC 5020 as UAC does not retransmit the PRACK
request when it receives a retransmission of the provisional response
242 being acknowledged.
Verify that the MGC 5020 as UAC discards retransmissions of a reliable
243 provisional responsewhich is already recieved.
Verify that the 5020 MGC as UAC shall discard reliable provisional
244 responses received after the final response.
Verify that the UAS replies the answer to the offer (sent in the INVITE
245 by UAC) in the reliable provisional response.
Verify that the UAS send sthe Offer in the 1st reliablet provisonal
response to the UAC if there was no Offer sent in the INVITE from UAC
246 and the UAC should reply with the ANSWER in the PRACK.

Verify that there is a Rack header in the PRACK request and is the
247 combination of Rseq + Cseq and in the format of Rack: 123 456 PRACK
Verify that a SUBSCRIBE/NOTIFY is forwarded by the MGC 5020
acting as a proxy.It also supports the Expires and Event headers in
248 SUBSCRIBE.
Verify that the MGC 5020 acting as an UA does not support Event
header in a SUBSCRIBE and replies with 489 Bad Event to a
249 SUBSCRIBE.
Verify tht the "id" parameter is presnt in the Event header in the
250 SUBSCRIBE.
Verify that the MGC 5020 acting as a subscriber sends a new
SUBSCRIBE on the same dialog with a Expire value and Cseq and same
251 "id" parameter in the Event header to refresh the Subscription.
Verify that the upon recieveing a unsubscribe request the MGC 5020
acting as a notifier sends a NOTIFY with subscription state=terminated
252 and reason=timeout.
Verify that the SUBSCRIBE contains Event,Allow-Event and Expire
253 headers.
Verify that the UAS replies with a final response(200/202/4xx/5xx/6xx)
254 to the SUBSCRIBE.
Verify that the MGC 5020 replies with 423 Interval too brief when the
Expires header value is smaller than the specified in the MGC and when
receiving 423 Interval too brief from peer side it send the SUBSCRIBE
255 once again with the value in Expire mention
Verify that the MGC 5020 sends a NOTIFY with Subscription-
state=terminated and reason=timeout whenever the expire time limit
256 expires without a refresh SUBSCRIPTION.
11. Verify that the "id" parameter present in the Event header of
257 SUBSCRIBE is also present in the corresponding NOTIFY messages.
1Verify that if the Event package in the Event Header of NOTIFY is not
258 supported then the SUBSCRIBER responds with 489 Bad Event.
Verify that upon recieveing the SUBSCRIBE message for a subscripition
if the NOTIFIER understands and accepts the same then it replies with a
259 cooresponding NOTIFY.
Verify that upon receiving the corresponding NOTIFY,the
260 SUBSCRIBER replies with 202 accepted.
Verify that an early dialog is already created at the UAC by the Reliable
261 Provisional Response by the time the Callee sends the UPDATE.
Verify that the Rel Prov Response contains an Allow header having
262 UPDATE method.
Verify that if the Caller/Callee recieves any non-@xx final response to
263 the UPDATE then the session parameters remain unchanged.
Verify that if the UAC recieves 491 for a UPDATE then it should send
the UPDATE again upon the firing the Timer set if it still wants for the
264 session updation.
Verify that an UAS which recieves an UPDATE before it generates a
final response to an previous UPDATE on the same dialog,replys with
500 error response to the new UPDATE with a Retry-After header
265 having value between 0 to 10 seconds.
Verify tht the UAS generates 491 to a new UPDATE received if it has
not received answers to an other request(UPDATE,INVITE,PRACK)
266 which it had sent before.
Verify that the UAS rjects a new Session Description with 488 Not
acceptable here containing an Warning header if the Sesson description is
267 not acceptable.
Verify that the UPDATE cant contain a offer if the Caller/Callee has to
answer any other request (UPDATE,PRACK,INVITE) or if it has to get
268 the answer from the other party.
Verify that the MGC 5020 supports Tel URI format in the From,Contact
269 or Request URI fields.
Verify that the MGC 5020 doesn’t add any Call-Info,Organization and
270 Server header to the request.
Verify that for the request the MGC 5020 removes all the Via Headers
till itself and puts one single Via header representing all(any anonymous
271 URI).Check that there is no "Via stripping" incase of responses.
Verify that the MGC 5020 removes the Contact URI and puts an
272 anonymous URI which is of derefence to itself.

Verify that the MGC 5020 removes the Record-route headers from the
273 request and puts the same in the response in order alongwith its own URI.
Verify that the MGC 5020 removes any non-essential
informational headers likes Subject,Call-Info,Organization, User-Agent,
Reply-To
274 and In-Reply-To from the request.
Verify that the MGC 5020 removes the value of From Header and puts
275 an anonymous value.
Verify that the MGC 5020 may remove the Call-ID value and puts a new
value in the request and again in the response puts the original value(thus
276 acting like a B2BUA).
Verify that the User prepares the call-ID by not putting his IP address or
277 domain name,rather by some aribitrary name.

Verify that if the critical privacy level is present in the Privacy header of
a
requestand the MGC 5020 is incapable of performing all of the levels of
privacy specified in the Privacy header,then the MGC 5020 replies with
278 500(Server Error).
TRACEABILITY

5.5(Sec 4)

5.5(Sec 5)

5.5(Sec 6)

5.5(Sec 7)

5.5(Sec 7.2)

5.5(Sec 8.1.1.1)

5.5(Sec 8.1.1.2)

5.5(Sec 8.1.1.3)

5.5(Sec 8.1.1.3)
5.5(Sec 8.1.1.3)

5.5(Sec 8.1.1.6)

5.5(Sec 8.1.1.7)

5.5(Sec 8.1.1.8)

5.5(Sec 8.1.1.9)

5.5(Sec 8.1.3.1)

5.5(Sec 8.1.3.3)

5.5(Sec 8.1.3.4)

5.5(Sec 8.1.3.4)
5.5(Sec 8.2.2)

5.5(Sec 8.2.2.1)

5.5(Sec 8.2.2.2)

5.5(Sec 8.2.2.3)

5.5(Sec 8.2..4)

5.5(Sec 8.2.6.1)

5.5(Sec 8.2.6.2)

5.5(Sec 8.3)

5.5(Sec 8.2.7)

5.5(Sec 8.2.7)
5.5(Sec 8.2.7)
5.5(Sec 8.2.7)
5.5(Sec 9.2)

5.5(Sec 9)

5.5(Sec 10.1)

5.5(Sec 11)

5.5(Sec 11.1)

5.5(Sec 11.2)

5.5(Sec 20.16)

5.5(Sec 21.4.9)

5.5(Sec 21.4.6)

5.5(Sec 14)

5.5(Sec 14.1)

5.5(Sec 14.2)

5.5(Sec 15)
5.5(Sec 15)

5.5(Sec 13.2.1)
5.5(Sec 13.2.1)

5.5(Sec 21.4.4)
5.5(Sec 15.1.2)

5.5(Sec 17.1.4)

5.5(Sec 17.2.1)

5.5 (Sec 8.1.1.7)

5.5(Sec 18.1.1)

5.5(Sec 19.1.5)

5.5(Sec 18.1.1)

5.5(Sec 18.2.1)

5.5(Sec 21.4.1)

5.5(Sec 18.4)

5.5(Sec 21.4.2)

5.5(Sec 17.1.1.1)
5.5(Sec 20.20)

5.5(Sec 20.20)

5.5(Sec 18.1.1)

5.5(Sec 18.1.2)

5.5(Sec 18.1.1.2)

5.5(Sec 18.1.2)

5.5(Sec 18.1.1.4)

5.5(Sec 18.2.6.2)

5.5(Sec 18.1.1.8)

5.5(Sec 18.2.6.2)

5.5(Sec 17.1)

5.5(Sec 17.1)
5.5(Sec 17.1)

5.5(Sec 17.1)

5.5(Sec 20.34)

5.5(Sec 20.34)
5.5(Sec 21.1.1 and
Sec 21.1.2)

5.5(Sec 21.1.3)

5.5(Sec 21.1.4)

5.5(Sec 21.3.1)

5.5(Sec 21.3.2)

5.5(Sec 21.3.3)

5.5(Sec 21.3.3)
5.5(Sec 21.3.3)

5.5(Sec 21.4)

5.5(Sec 21.4.4)

5.5(Sec 21.4.5)

5.5(Sec 21.4.10)

5.5(Sec 21.4.11)

5.5(Sec 21.4.15)

5.5(Sec 21.4.17)

5.5(Sec 21.4.18)

5.5(Sec 21.4.19)

5.5(Sec 21.4.20)

5.5(Sec 21.4.21)

5.5(Sec 21.4.22)

5.5(Sec 21.4.24)

5.5(Sec 21.4.27)

5.5(Sec 21.4.28)

5.5(Sec 21.5.1)
5.5(Sec 21.5.2)

5.5(Sec 21.5.3)

5.5(Sec 21.5.4)

5.5(Sec 21.5.4)
5.5(Sec 21.5.4)

5.5(Sec 21.5.6)
5.5(Sec 21.5.7)

5.5(Sec 21.6.1)

5.5(Sec 21.6.2)

5.5(Sec 21.6.3)

5.5(Sec 21.6.4)

5.5(Sec 7)

RFC 3455

RFC 3455
RFC 3515

RFC 3960

RFC 3960
RFC 4244

RFC 3326

RFC 3325

RFC 3891

RFC 3891
RFC 3891

RFC 3891

Draft_iptel_trkgrp

5.18(Section 2)

5.18(Section 3)

5.18(Section 4)

5.18(Section 4)
5.2(Section 3)

5.2(Section 3)

5.2(Section 5.1)

5.2(Section 5.1)
5.2(Section 5.1)

5.2(Section 5.1)

5.2(section 4.5.3)

5.2(section 5.1.1)

5.2(Section 5.1.3)

5.2(Section 5.2.4)

5.2(Section 5.2.4)
5.2(Section 6)

5.2(Section 6)

5.3(Section 5.3)

5.3(Section 5.4)

5.3(Section 6)

5.3(Appendix A)
5.4(Section 2)

5.4(Section 2.2)

5.4(Section 2.2)
5.4(Section 2.2)

5.4(Section 2.2)

5.4(Section 2.3)
5.4(Section 2.4)

5.4(Section 2.4)

5.4(Section 2.5.3)

5.4(Section 3)

5.6(Section 3)

5.6(Section 3)
5.6(Section 3)

5.6(Section 3)

5.6(Section 4)

5.6(Section 5)

5.6(Section 7.2)

5.8(Section
1.1,3.1.1,3.1.2)

5.8(Section 3.1.2)

5.8(Section 3.1.4--
3.1.4.1 + 3.1.4.2))
5.8(Section 3.1.4.3)

5.8

5.8(Section 3.1.6)

5.8

5.8(Section 3.2.4)

5.8

5.9(Section 4)

5.9(Section 5.2)

5.9(Section 5.2)
5.9(Section 5.2)

5.9

RFC 2806

5.11(Section 5.1)

5.10.
Collection Name TestList Name TestList Description

215 92046 AAAA PK DTAG_SIP_ORIG SIP ORIG UA CONFORMANCE TEST

Testcase Name Area SubArea RCR TRS INC FDT Ext.Link QTPrefix

SIP_ORIG_01 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_02 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_03 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_04 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_05 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_06 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_07 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_08 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_09 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_10 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_11 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_12 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_13 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_14 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_15 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_16 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_17 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_18 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_19 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_20 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_21 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_22 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_23 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_24 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_25 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_26 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_27 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_28 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_29 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_30 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_31 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_32 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_33 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_34 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_35 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_36 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_37 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_38 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_39 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_40 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_41 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_42 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_43 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_44 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_45 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_46 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_47 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_48 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_49 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_50 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_51 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_52 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_53 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_54 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_55 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_56 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_57 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_58 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_59 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_60 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_61 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_62 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_63 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_64 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_65 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_66 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_67 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_68 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_69 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_70 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_71 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_72 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_73 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_74 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_75 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_76 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_77 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_78 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_79 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_80 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_81 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_82 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_83 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_84 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_85 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_86 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_87 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_88 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_89 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_90 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_91 IP_PROT SIP 00 BL DTAG_SIP

SIP_ORIG_92 IP_PROT SIP 00 BL DTAG_SIP

QTVariant Testcase Description
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including non-understood uri-parameters in SIP-URI of the From
header, ignores it and sends an ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including header parameters in the SIP-URI of the Contact
header, sends an ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (299 OK) response with non-defined last two digits, sends an ACK request.

Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 PERFECT) response with an unknown reason phrase, sends an ACK request.

Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including headers named with upper and lower cases, sends an
ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including headers set with values preceded by several leading
white space and properly extended over multiple lines, sends an ACK req

Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including a headers set with short names, sends an ACK
request.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including escaped characters in the SIP-URI of the From header, sends a Success (200 OK)
response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including escaped delimiters in the SIP-URI of the From header, sends a Success (200 OK)
response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including non-understood uri-parameters in the SIP-URI of the BYE Request-URI, sends a
Success (200 OK) response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including an unknown header, ignores it and sends a Success (200 OK) response.

Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including headers named with upper and lower cases sends a Success (200 OK) response.

Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including headers set with values preceded by several leading white space and properly
extended over multiple lines, sends a Success (200 OK) response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including headers set with short names, sends a Success (200 OK) response.

Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
65.535 bytes long Success (200 OK) response including session description parameters that
it can accept, transported by UDP, sends an ACK request.

Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including transport parameters in the From and To headers,
ignores them and sends an ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response with a ttl parameter in the From and To headers, ignores them
and sends an ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response with an URI including a header parameter in the To and From
headers ignores them and sends an ACK request.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response with a method parameter in the To and From headers ignores
them and sends an ACK request.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including header parameters in the SIP-URI of the From and To headers ignores them and
sends a Success (200 OK) response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including method parameters set to “CANCEL” parameter in the SIP-URI of the From and To
headers ignores them and sends a Success (200 OK) response.
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including an In-Reply-To header ignores it and sends a Success (200 OK) response.

Ensure that the IUT, when an INVITE client transaction is in the Calling state while a
message-oriented (UDP) transport is used, on receipt of a Success (200 OK) response
including a body part shorter than the length indicated in the Content-Length header

Ensure that the IUT, when an INVITE client transaction is in the Calling state while a
message-oriented (UDP) transport is used, on receipt of a Success (200 OK) response
including a body part longer than the length indicated in the Content-Length header

Ensure that the IUT, to establish a call sends an INVITE request including at least To, From,
Cseq, Call-ID, Max-Forwards, Contact and Via headers.
Ensure that the IUT, to establish a call sends an INVITE request with a Request-URI set to
the same URI value of the To header.
Ensure that the IUT, to establish a call sends an INVITE request including a To header set to
an address of the callee and without TAG parameter.
Ensure that the IUT, to establish a call sends an INVITE request including a From header with
a TAG parameter.
Ensure that the IUT, to establish a call sends an INVITE request including a Cseq header with
a method that matches "INVITE".
Ensure that the IUT, to establish a call sends a INVITE request including a Max-Forward
header set to 70.
Ensure that the IUT, to establish a call sends an INVITE request including a Via header with a
protocol name set to SIP, a protocol version set to 2.0 and a branch parameter set to a value
beginning with "z9hG4bK".
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Trying (100 Trying) response enters in the Proceeding state.
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Session Progress (183 Session Progress) response enters in the Proceeding state

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Unknown (199 Unknown) response enters in the Proceeding state.
Ensure that the IUT when an INVITE client transaction is in the Proceeding state, on receipt of
a Trying (100 Trying) response stays in the Proceeding state
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response sends an ACK request
Ensure that the IUT when an INVITE client transaction is in the Proceeding state, on receipt of
a Success (200 OK) response sends an ACK request.
Ensure that the IUT when an INVITE client transaction is in the Proceeding state, on receipt of
a Success (200 OK) response with more than one Via header value does not send an ACK
request, discards the response
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response sends an ACK request with the same CSeq sequence number as
in the original INVITE request and the CSeq method field value set to “ACK”

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response sends an ACK request with the To header set to the same value
as in the received final response
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response including a To header without TAG sends an ACK request with a
To header without TAG.
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of
Success (200 OK) responses differing only on the tag in the To header, sends an ACK
request with a To header identical to the received one for each received Succe

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Success (200 OK) response sends an ACK request with the same Call-ID and From headers
as in the original INVITE request.
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Not Found (404 Not Found) response sends an ACK request with the same Call-ID, From
headers and Request-URI as in the original INVITE request and the same Tag i

Ensure that the IUT when an INVITE client transaction is in the Proceeding state, on receipt of
a Not Found (404 Not Found) response sends an ACK request with the same Call-ID, From
headers and Request-URI as in the original INVITE request and the same Ta

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Gone (410 Gone) response sends an ACK request with the same Call-ID, From headers and
Request-URI as in the original INVITE request and the same Tag in the To h

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Temporarily Unavailable (480 Temporarily Unavailable) response sends an ACK request with
the same Call-ID, From headers and Request-URI as in the original INVIT

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Busy Here (486 Busy Here) response sends an ACK request with the same Call-ID, From
headers and Request-URI as in the original INVITE request and the same Tag i

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Server Internal Error (500 Server Internal Error) response sends an ACK request with the
same Call-ID, From headers and Request-URI as in the original INVITE re

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Busy Everywhere (600 Busy Everywhere) and a Server Internal Error (500 Server Internal
Error) responses with different branch parameter value on the top Via hea

Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Decline (603 Decline) response sends an ACK request with the same Call-ID, From headers
and Request-URI as in the original INVITE request and the same Tag in th

Ensure that the IUT having already received a non 2XX final response to its INVITE request,
on receipt of a Decline (603 Decline) response, with the same Via branch parameter and
CSeq header method as in the INVITE request, sends an ACK message.
Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a
Unknown (699 Unknown) response sends an ACK request with the same Call-ID, From
headers and Request-URI as in the original INVITE request and the same Tag in th

Ensure that the IUT while is establishing a call, sends a unique session description either in
the INVITE request or in the ACK request to answer the initial offers given then in the final
2XX response.
Ensure that the IUT while is establishing a call, sends a Content-Length header set to the size
of the body in the message that contains the session description.
Ensure that the IUT while is establishing a call, sends a Content-Type header in the message
that contains the session description.
Ensure that the IUT while is establishing a call, sends a Content-Encoding header only in the
message that contains the session description.
Ensure that the IUT while is establishing a call on receipt of in 2XX a not acceptable session
description, sends an ACK request immediately followed by a BYE request.
If an unreliable transport (UDP) is used, ensure that the IUT, when an INVITE client
transaction is in the Calling state repeats its INVITE request on the timeout condition of timer
A set with a value of T1.
If an unreliable transport (UDP) is used, ensure that the IUT, when an INVITE client
transaction is in the Calling state having already repeated its INVITE wait for a timer A set with
a value of 2*T1 before sending it again.
If an unreliable transport (UDP) is used, ensure that the IUT, when an INVITE client
transaction is in the Calling state retransmits its INVITE request with intervals that double after
each transmission.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, when timer B
set to a value of 64*T1 expires, does not send an ACK.
Ensure that the IUT, when an INVITE client transaction is in the Calling state, when timer B
set to a value of 64*T1 expires, considers the transaction terminated.
Ensure that the IUT, when an INVITE client transaction is in the Proceeding state, does not
repeat its INVITE request.
If an unreliable transport is used, ensure that the IUT, when an INVITE client transaction is in
the Completed state, on receipt of final responses that matches the transaction, still answer
with an ACK request until timer D set to at least 32 second exp

If an unreliable transport is used, ensure that the IUT, when an INVITE client transaction is in
the Completed state, on receipt of new final responses with different Via branch parameter
value, does not repeat its ACK request until timer D set to at leas

Ensure that the IUT, when an INVITE client transaction has been in the Terminated state, on
receipt of a retransmitted Success (200 OK) responses sends an ACK request until 64*T1
duration expires.
Ensure that the IUT, when an INVITE client transaction has been in the Terminated state,
after 64*T1 duration expires, on receipt of a retransmitted Success (200 OK) responses does
not send an ACK request.
Ensure that the IUT,once a dialog has been established, to release it sends a BYE request
with a To header set to the same value as in the last received a final response.

Ensure that the IUT,once a dialog has been established with a final response in which the
TAG in the To header was omitted, to release it sends a BYE request with an identical To
header without TAG value.
Ensure that the IUT, once a dialog has been established, to release it sends a BYE request
with the same Call-ID, From header as in the original INVITE message.
Ensure that the IUT, once a dialog has been established, to release it sends a BYE request
with an incremented of on Cseq value, a method field in the Cseq header set to "BYE".

Ensure that the IUT, once a dialog has been established with a Success(200OK) response
including no Record-Route header set, to release it send a BYE request with the Request-URI
set to the Contact URI included in the received final response and with no R

Ensure that the IUT, once a dialog has been established, having sent a BYE request, on
receipt of a Success (200OK) response considers the session and the dialog terminated.

Ensure that the IUT, once a dialog has been established, having sent a BYE request, on
receipt of a Call Leg/Transaction Does Not Exist ( 481) considers the session and the dialog
terminated.
Ensure that the IUT having received a Trying ( 100Trying) response to its INVITE request, to
give up the call, sends a CANCEL request.
Ensure that the IUT having received a Trying (100Trying) response to its INVITE request, to
give up the call, sends a CANCEL request with the same Request-URI, Call-ID, From,To
header as in the original INVITE message.
Ensure that the IUT having received a Trying (100Trying) response to its INVITE request,
sends a CANCEL request with the same numberic part of Cseq as in the original INVITE
message and with a method field in the Cseq header set to "CANCEL".

Ensure that the IUT having received a Trying (100 Trying) response to its INVITE request,
sends a CANCEL request with a single Via header value matching the top Via value of the Via
header of the original INVITE message.
Ensure that the IUT having receive a Trying ( 100 Trying) response to its INVITE request, to
give up the call, send a CANCEL request without Require or Proxy Requrire header.

Ensure that the IUT having received a Trying (100 Trying) response to its INVITE request, to
give up the call having sent a CANCEL request, on receipt of a 2XX response to the original
INVITE sends an ACK request
Ensure that the IUT, once a dialog has been established, on receipt of a CANCEL request
followed by a BYE request, sends a Success (200 OK) response to the BYE request.

If an unreliable transport is used, ensure that the IUT, having sent a BYE request on an
established dialog, repeats its request after timer E set to T1 value expires.
If an unreliable transport is used, ensure that the IUT, having sent twice times a BYE request
on an established dialog, repeats its request after timer E set to the MIN(2*T1,T2) value
expires.
If an unreliable transport is used, ensure that the IUT, having sent three times a BYE request
on an established dialog, repeats its request after timer E set to the MIN(4*T1,T2) value
expires.
If an unreliable transport is used, ensure that the IUT does not repeat a BYE request on an
established dialog, after timer F set to 64*T1 expires.
Ensure that the IUT, when a BYE client transaction is in the Proceeding state, repeats its BYE
request after timer E set to T1 value expires.
Ensure that the IUT, when a BYE client transaction is in the Proceeding state and BYE
request have been already repeated in this state, repeats its BYE request after timer E set to
T2 value expires.
Ensure that the IUT, when a BYE client transaction is in the Proceeding state, does not repeat
a BYE request on an established dialog, after timer F set to 64*T1 expires.
Ensure that the IUT, when a BYE client transaction is in the Trying state, considers the
transaction terminated after 64*T1 duration expires without receiving any final response.

Ensure that the IUT, having sent an INVITE, on receipt of a re-INVITE on this dialog, sends a
Request Pending (491 Request Pending) response.
Ensure that the IUT when an INVITE client transaction is in the Proceeding state, on receipt of
an re-INVITE on this dialog, sends a Request Pending (491 Request Pending) response.
SIP_MG_OE_V_001

SIP_MG_OE_V_002

SIP_MG_OE_V_003

SIP_MG_OE_V_004

SIP_MG_OE_V_005

SIP_MG_OE_V_006

SIP_MG_OE_V_007

SIP_MG_OE_V_008

SIP_MG_OE_V_009

SIP_MG_OE_V_010

SIP_MG_OE_V_011

SIP_MG_OE_V_012

SIP_MG_OE_V_013

SIP_MG_OE_V_014

SIP_MG_OE_V_015

SIP_MG_OE_I_001

SIP_MG_OE_I_002
SIP_MG_OE_I_003

SIP_MG_OE_I_004

SIP_MG_OE_I_006

SIP_MG_OE_I_007

SIP_MG_OE_I_008

SIP_MG_OE_I_009

SIP_MG_OE_I_010

SIP_CC_OE_CE_V_001

SIP_CC_OE_CE_V_002

SIP_CC_OE_CE_V_003

SIP_CC_OE_CE_V_004

SIP_CC_OE_CE_V_005

SIP_CC_OE_CE_V_006

SIP_CC_OE_CE_V_007

SIP_CC_OE_CE_V_009

SIP_CC_OE_CE_V_010

SIP_CC_OE_CE_V_011

SIP_CC_OE_CE_V_012

SIP_CC_OE_CE_V_013

SIP_CC_OE_CE_V_014

SIP_CC_OE_CE_V_015
SIP_CC_OE_CE_V_016

SIP_CC_OE_CE_V_017

SIP_CC_OE_CE_V_018

SIP_CC_OE_CE_V_019

SIP_CC_OE_CE_V_020

SIP_CC_OE_CE_V_032

SIP_CC_OE_CE_V_033

SIP_CC_OE_CE_V_034

SIP_CC_OE_CE_V_035

SIP_CC_OE_CE_V_036

SIP_CC_OE_CE_V_037

SIP_CC_OE_CE_V_038

SIP_CC_OE_CE_V_039

SIP_CC_OE_CE_V_040
SIP_CC_OE_CE_V_042

SIP_CC_OE_CE_V_044

SIP_CC_OE_CE_V_045

SIP_CC_OE_CE_V_046

SIP_CC_OE_CE_V_047

SIP_CC_OE_CE_V_048
SIP_CC_OE_CE_TI_001

SIP_CC_OE_CE_TI_003

SIP_CC_OE_CE_TI_004

SIP_CC_OE_CE_TI_005

SIP_CC_OE_CE_TI_006

SIP_CC_OE_CE_TI_007

SIP_CC_OE_CE_TI_008

SIP_CC_OE_CE_TI_010

SIP_CC_OE_CE_TI_011

SIP_CC_OE_CE_TI_012

SIP_CC_OE_CR_V_001

SIP_CC_OE_CR_V_002

SIP_CC_OE_CR_V_003
SIP_CC_OE_CR_V_004

SIP_CC_OE_CR_V_005

SIP_CC_OE_CR_V_008

SIP_CC_OE_CR_V_009

SIP_CC_OE_CR_V_010

SIP_CC_OE_CR_V_011

SIP_CC_OE_CR_V_012

SIP_CC_OE_CR_V_013

SIP_CC_OE_CR_V_014

SIP_CC_OE_CR_V_015

SIP_CC_OE_CR_I_001
SIP_CC_OE_CR_TI_001

SIP_CC_OE_CR_TI_002

SIP_CC_OE_CR_TI_003

SIP_CC_OE_CR_TI_004

SIP_CC_OE_CR_TI_005

SIP_CC_OE_CR_TI_006

SIP_CC_OE_CR_TI_007
SIP_CC_OE_CR_TI_008

SIP_CC_OE_SM_V_001

SIP_CC_OE_SM_V_002
Collection Name TestList Name TestList Description

215 92046 AAAA PK DTAG_SIP_TER SIP TERM UA CONFORMANCE TEST

Testcase Name Area SubArea RCR TRS INC FDT Ext.Link QTPrefix QTVariant

SIP_TERM_01 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_02 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_03 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_04 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_05 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_06 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_07 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_08 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_09 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_10 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_11 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_12 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_13 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_14 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_15 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_16 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_17 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_18 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_19 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_20 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_21 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_22 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_23 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_24 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_25 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_26 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_27 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_28 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_29 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_30 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_31 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_32 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_33 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_34 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_35 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_36 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_37 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_38 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_39 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_40 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_41 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_42 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_43 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_44 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_45 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_46 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_47 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_48 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_49 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_50 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_51 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_52 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_53 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_54 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_55 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_56 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_57 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_58 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_59 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_60 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_61 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_62 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_63 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_64 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_65 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_66 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_67 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_68 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_69 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_70 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_71 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_72 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_73 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_74 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_75 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_76 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_77 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_78 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_79 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_80 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_81 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_82 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_83 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_84 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_85 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_86 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_87 IP_PROT SIP 00 BL DTAG_SIP

SIP_TERM_88 IP_PROT SIP 00 BL DTAG_SIP

Testcase Description
Ensure that the IUT on receipt of an INVITE request including escaped characters in the SIP- SIP_MG_TE_V_001
URI of the Contact header, sends a Success (200 OK) response preceded optionally by
informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including escaped delimiters in the SIP- SIP_MG_TE_V_002
URI of the Contact header, sends a Success (200 OK) response preceded optionally by
informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including non-understood uri-parameters SIP_MG_TE_V_003
in the SIP-URI of the Contact header, sends a Success (200 OK) response preceded
optionally by informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including a header parameter in the SIP- SIP_MG_TE_V_004
URI of the Contact header, sends a Success (200 OK) response preceded optionally by
informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including a method parameter set to SIP_MG_TE_V_005
“INVITE” in the SIP-URI of the Contact header, sends a Success (200 OK) response
preceeded optionally by informational (1XX) response.
Ensure that the IUT on receipt of a request including a non-supported Method, sends a SIP_MG_TE_V_006
Method not allowed (405 Method Not Allowed) response including an Allow header that lists
the set of method supported.
Ensure that the IUT on receipt of an INVITE request including an unknown header, ignores SIP_MG_TE_V_007
them and sends a Success (200 OK) response preceded optionally by informational (1XX)
response.
Ensure that the IUT on receipt of an INVITE request including headers named with upper and SIP_MG_TE_V_008
lower cases, sends a Success (200 OK) response preceded optionally by informational (1XX)
response.
Ensure that the IUT on receipt of an INVITE request including headers set with values SIP_MG_TE_V_009
preceded by several leading white space and properly extended over multiple lines, sends a
Success (200 OK) response preceded optionally by informational (1XX) response.

Ensure that the IUT on receipt of an INVITE request including a Via header set with multiple SIP_MG_TE_V_010
values separated by a comma, sends a Success (200 OK) response preceded optionally by
informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including multiple Via headers, sends a SIP_MG_TE_V_011
Success (200 OK) response preceded optionally by informational (1XX) response.

Ensure that the IUT on receipt of an INVITE request including a branch parameter named with SIP_MG_TE_V_012
upper and lower cases of Via header, sends a Success (200 OK) response preceded
optionally by informational (1XX) response.
Ensure that the IUT on receipt of a 65.535 bytes long INVITE request including session SIP_MG_TE_V_014
description parameters that it can accept, transported by UDP, sends a Success (200 OK)
response, preceded optionally by informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request with SIP-version in lower case, sends a SIP_MG_TE_I_001
Success (200 OK) response preceded optionally by informational (1XX) response.

Ensure that the IUT on receipt of an INVITE request including a maddr parameter in the From SIP_MG_TE_I_002
and To headers, ignores them and sends a Success (200 OK) response without maddr
parameter, preceded optionally by informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including header parameters in the SIP- SIP_MG_TE_I_003
URI of the From and To headers, ignores them and sends a Success (200 OK) response,
preceded optionally by informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request including method parameters set to SIP_MG_TE_I_004
“CANCEL” in the SIP-URI of the From and To headers, ignores them and sends a Success
(200 OK) response, preceded optionally by informational (1XX) response.
Ensure that the IUT on receipt of an INVITE request without Call-ID header sends a Bad SIP_MG_TE_I_005
Request (400 Bad Request) response.
Ensure that the IUT on receipt of an INVITE request including header field Retry-After, ignores SIP_MG_TE_I_006
it and sends a Success (200 OK) response, preceded optionally by informational (1XX)
response.
Ensure that the IUT, on receipt of an INVITE request, while a message-oriented (UDP) SIP_MG_TE_I_007
transport is used, including a body part shorter than the length indicated in the Content-Length
header field, sends a Bad Request (400 Bad Request) response.

Ensure that the IUT, on receipt of an INVITE request, while a message-oriented (UDP) SIP_MG_TE_I_008
transport is used, including a body part longer than the length indicated in the Content-Length
header field, ignores extra bytes and sends a Success (200 OK) response, p

Ensure that IUT on receipt of an INVITE request, sends a Success ( 200OK) SIP_CC_TE_CE_V_001
Ensure that IUT on receipt of an INVITE request with a Request -URI set with a scheme that it
does not support, sends a Unsupported URI scheme ( 416 Unsupported URI scheme)
response. (*) SIP_CC_TE_CE_V_002
Ensure that the IUT on receipt an INVITE request with Request-URI set with an address that it
does not accept sends a Not Found ( 404 Not Found) response. SIP_CC_TE_CE_V_003
Ensure that the IUT on receipt of an INVITE request with Timestamp header, when it answers
with a provision response Trying (100 Trying), set a Timestamp header with an increased
value of the received Timestamp in its response. SIP_CC_TE_CE_V_004
Ensure that the IUT on receipt of an INVITE request including an Expires header set to 0,
sends a Request Terminated ( 487 Request Terminated) response. (*) SIP_CC_TE_CE_V_005
Ensure that the IUT on receipt of an INVITE request including no message body, includes in
its first 2xx response an initial offer session description. SIP_CC_TE_CE_V_006
Ensure that the IUT on receipt of an INVITE request including an initial offer session
description in its message body, includes the answer in its first 2xx response a session
description. SIP_CC_TE_CE_V_007
Ensure that the IUT on receipt of an INVITE request, sends a Success(200OK) or a
provisional ( 101-199) response including the header From, Call-ID, Cseq and Via header
copy from the INVITE request. SIP_CC_TE_CE_V_014
Ensure that the IUT on receipt of an INVITE request with no TAG set on the TO header,
sends a Success ( 200OK) or a provisional ( 101-199) response including the same URI and
an additional TAG for the To header. SIP_CC_TE_CE_V_015
Ensure that the IUT on receipt of an INVITE request with a TAG set on the To header, sends
a Success(200OK) or a provisional ( 101-199) response including the same URI and the
same TAG for the To header. SIP_CC_TE_CE_V_016
Ensure that the IUT on receipt of an INVITE request, sends a Success(200OK) or a
provisional ( 101-199) response including a single Contact header. SIP_CC_TE_CE_V_017
Ensure that the IUT on receipt of an INVITE request including From header without tag, sends
a Success(200OK) or a provisional (101-199) response including a From header without tag.
SIP_CC_TE_CE_V_020
Ensure that the IUT having received an INVITE request, sends a Success( 200OK) including
an Allow and a Supported headers. SIP_CC_TE_CE_V_021
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
an INVITE request, including a Via header set with the same branch parameter and sent-by
value in the topmost list value, repeats its last response. SIP_CC_TE_CE_V_022
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
an INVITE request, including a Via header set with the same branch parameter but with the
Request-URI, To Tag, From Tag, Call-ID, CSeq and top Via identical as
SIP_CC_TE_CE_V_023
Ensure that the IUT when a server INVTIVE transaction is in the Proceeding state, on receipt
of an INVITE request, including a Via header set with a different branch parameter without the
magic cookie "z9hG4bK" but with the Request-URI, To tag, From tag,
SIP_CC_TE_CE_V_024
Ensure that the IUT when a server INVITE transactionis in the Completed state, on receipt of
an INVITE request, including a Via header set with the same branch parameter and sent by
value in the topmost list value, reapeat its last response. SIP_CC_TE_CE_V_025
Ensure that the IUT when a server INVITE transaction is in the Complete state, on receipt of
an INVITE request, including a Via header set with no branch parameter but with the Request-
URI, To tag, From tag, Call-ID, Cseq and top Via identical as in the f
SIP_CC_TE_CE_V_026
Ensure that the IUT when a server INVTIVE transaction is in the Completed state, on receipt
of an INVITE request, including a Via header set with a different branch parameter without the
magic cookie "z9hG4bK" but with the Request-URI, To tag, From tag, C
SIP_CC_TE_CE_V_027
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
an INVITE request, including a Via header set with a different branch parameter starting with
the magic cookie "z9hG4bK" but with the Request-URI, To tag, From
SIP_CC_TE_CE_V_028
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
an INVITE request, including a Via header set to an identical branch parameter starting with
the magic cookie "z9hG4bK" and a different sent by value, but with
SIP_CC_TE_CE_V_029
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
an INVITE request, including a top Via header set to a different value but with the Request-
URI, To tag, From tag, Call-ID and Cseq identical as in the first IN SIP_CC_TE_CE_V_030
Ensure that the IUT on receipt of an INVITE request with a Require header set to an option
value that the IUT does not support, sends a Bab Extension ( 420 Bad Extension) response
including those options in the Unsupported header. SIP_CC_TE_CE_V_031
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, after
sending a 4XX response, enters in the Completed state SIP_CC_TE_CE_V_032
Ensure that the IUT when a server INVITE transaction is in the Completed state, on receipt of
an ACK request, enters in the Confirmed transaction state. SIP_CC_TE_CE_V_033
Ensure that the IUT when a server INVITE transaction is in the Completed state, on receipt of
an ACK request including a Proxy-Require header set with an option-tag that it does not
support, enters in the confirmed transaction state. SIP_CC_TE_CE_I_001
Ensure that the IUT when a server INVITE transaction is in the Completed stae, on receipt of
an ACK request including a Require header set with an option-tag that it does not support,
enters in the Confirmed transaction state. SIP_CC_TE_CE_I_002
If an unreliable transport is used, ensure that the IUT, when an INVITE server transaction is in SIP_CC_TE_CE_TI_001
the Completed state repeats its response on the timeout condition of timer G set with a value
of T1.
If an unreliable transport is used, ensure that the IUT, when an INVITE server transaction is in SIP_CC_TE_CE_TI_003
the Completed state and having already sent twice times its response, repeats it after timer G
set MIN(2*T1,T2) value expires.
If an unreliable transport is used, ensure that the IUT, when an INVITE server transaction is in SIP_CC_TE_CE_TI_004
the Completed state and having already sent three times its response, repeats it after timer G
set the MIN(4*T1,T2) value expires.
Ensure that the IUT, when an INVITE server transaction is in the Completed state and, enters SIP_CC_TE_CE_TI_005
in the Terminated state after timer H set to 64*T1 value expires.
If an unreliable transport is used, ensure that the IUT, when an INVITE server transaction is in SIP_CC_TE_CE_TI_006
the Completed state and, does not repeats its response after timer H set to 64*T1 value
expires.
If an unreliable transport is used, ensure that the IUT, when an INVITE server transaction is in SIP_CC_TE_CE_TI_007
the Confirmed state, enters in the Terminated state after timer I set to T4 value expires.

Ensure that the IUT, when it has answered to an INVITE request with 2XX response, repeats SIP_CC_TE_CE_TI_009
it after T1 duration expires without receiving an ACK request.
Ensure that the IUT, when it has already answered twice times to an INVITE request with a SIP_CC_TE_CE_TI_010
2XX response, repeats it after 2*T1 duration expires without receiving an ACK request.

Ensure that the IUT, does not repeat its 2XX response to an INVITE request after T2 duration SIP_CC_TE_CE_TI_011
expires without receiving an ACK request.
Ensure that the IUT, when it has receive no ACK to its 2XX responses during a duration of SIP_CC_TE_CE_TI_012
64*T1 seconds, sends a BYE request.
Ensure that the IUT while a session has been establish, on receipt of an BYE request sends a
Success. SIP_CC_TE_CR_V_001
Ensure that the IUT while the dialog is in an early stage, on receipt of a BYE request sends a
response. SIP_CC_TE_CR_V_002
Ensure that the IUT while the dialog is in a confirm stage, on receipt of a BYE request sends a
Success ( 200 OK) response. SIP_CC_TE_CR_V_003
Ensure that the IUT once a dialog has been established, on receipt of a BYE request including
a header that it does not understand sends a Success ( 200 OK) response.
SIP_CC_TE_CR_V_004
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including a Require header set with an option-tag that it doesn not support, sends a Bad
Extension ( 420 Bab Extension) response including a Unsupported set with this opt
SIP_CC_TE_CR_V_005
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request, sends
a Success (200OK) response with From, Call-ID, Cseq and Via header set to the same value
as in the request. SIP_CC_TE_CR_V_006
Ensure that IUT, while no dialog has been established, on receipt of a BYE request, sends a
Call/Transaction does not exist(481 Call/Transacation does not exist). SIP_CC_TE_CR_V_007
Ensure that the IUT, while a dialog has been established, on receipt of a BYE request without
TAG in the TO header, sends a Call/Transaction does not exist ( 481 Call/Transaction does
not exist) SIP_CC_TE_CR_V_008
Ensure that the IUT, once a dialog has been established, on receipt of a BYE request
including a Cseq header set with a more than on higher value as in the previous
request,sends a Success (200OK) response with the same Cseq value. SIP_CC_TE_CR_V_009
Ensure that the IUT once a dialog has been established, to release it sends a BYE request
with a To header set to the same value as in the From header of the previous receive request.
SIP_CC_TE_CR_V_010
Ensure that the IUT once a dialog has been established, to release it sends a BYE request
with a From header set to the same value as in the To header of the last sent response.
SIP_CC_TE_CR_V_011
Ensure that the IUT once a dialog has been established with an INVITE request including no
Record-Route header set, to release it sends a BYE request with the Request-URI set to the
Contact URI included in the original INVITE request and with no Route hea
SIP_CC_TE_CR_V_012
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL, sends a Success (200 Success) response. SIP_CC_TE_CR_V_015
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL answers to the original INVITE, request with a Request Terminated (487 Request
Terminated) response SIP_CC_TE_CR_V_016
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL request including a Via header set with a different branch parameter starting with
the magic cookie “z9hG4bK” but with the Request-URI, To tag, From ta
SIP_CC_TE_CR_V_017
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL request including a Via header set to an identical branch parameter starting with
the magic cookie “z9hG4bK” and a different sent-by value, but with th
SIP_CC_TE_CR_V_018
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL request, including a top Via header set to a different value but with the Request-
URI, To tag, From tag, Call-ID and CSeq identical as in the original SIP_CC_TE_CR_V_019
Ensure that the IUT, having already answer to a BYE request, on receipt of a BYE request,
before timer J fires, including a Via header set with the same branch parameter in the topmost
list value, repeats its last response. SIP_CC_TE_CR_V_020
Ensure that the IUT, having already answer to a BYE request, on receipt of a BYE request,
before timer J fires, including a Via header set with no branch parameter but with the
Request-URI, To tag, From tag, Call-ID and CSeq identical as in the first BY
SIP_CC_TE_CR_V_021
Ensure that the IUT, having already answer to a BYE request, on receipt of a BYE request,
before timer J fires, including a Via header set with a different branch parameter but with the
Request-URI, To tag, From tag, Call-ID and CSeq identical as in the
SIP_CC_TE_CR_V_022
Ensure that the IUT on receipt of a BYE request with a CSeq number set to a lower value than
in the preceding INVITE request, sends a 500 (Server Internal Error) response.
SIP_CC_TE_CR_I_001
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL request including a Require header set with an option-tag that it does not support,
sends a Success (200 OK) response. SIP_CC_TE_CR_I_002
Ensure that the IUT when a server INVITE transaction is in the Proceeding state, on receipt of
a CANCEL request including a Proxy-Require header set with an option-tag that it does not
support, sends a Success (200 OK) response. SIP_CC_TE_CR_I_003
Ensure that the IUT while no session has been initiated, on receipt of a CANCEL request,
sends a Call/transaction Does Not Exist (481 Call/transaction Does Not Exist) response.
SIP_CC_TE_CR_I_004
Ensure that the IUT, while a session has been released, on receipt of a BYE request, sends a
Call/transaction Does Not Exist (481 Call/transaction Does Not Exist) response.
SIP_CC_TE_CR_I_005
If an unreliable transport is used, ensure that the IUT, when a BYE server transaction is in the
Completed state, on receipt of the repetitions of the BYE request, retransmits its response
until the timer J set to 64*T1 expires. SIP_CC_TE_CR_TI_001
Ensure that the IUT while a session has been established, on receipt of a re-INVITE request SIP_CC_TE_SM_V_001
with a higher CSeq and a new complete session description sends a Success (200 OK)
response including the last received CSeq.
Ensure that the IUT while a session has been established, on receipt of a re-INVITE request SIP_CC_TE_SM_V_002
with no session description sends a Success (200 OK) response.
Ensure that the IUT having sent a Success (200 OK) response to a re-INVITE request and SIP_CC_TE_SM_V_003
receiving no ACK message, sends a BYE request for the dialog.
Ensure that the IUT when an INVITE server transaction is in the Proceeding state, on receipt SIP_CC_TE_SM_I_001
of a re-INVITE with a lower CSeq values, sends a Server Internal Error (500 Server Internal
Error) response including a Retry-After header set to a randomly chos
Collection Name TestList Name TestList Description

DTAG_SIP_SPC NGN SIP specific

Testcase Name Area SubArea RCR TRS INC FDT Ext.Link QTPrefix QTVariant

DTAGSIP01 IP_PROT SIP 00 BL

DTAGSIP02 IP_PROT SIP 00 BL

DTAGSIP03 IP_PROT SIP 00 BL

DTAGSIP04 IP_PROT SIP 00 BL

DTAGSIP05 IP_PROT SIP 00 BL

DTAGSIP06 IP_PROT SIP 00 BL

DTAGSIP07 IP_PROT SIP 00 BL

DTAGSIP08 IP_PROT SIP 00 BL

DTAGSIP09 IP_PROT SIP 00 BL

DTAGSIP10 IP_PROT SIP 00 BL

DTAGSIP11 IP_PROT SIP 00 BL

DTAGSIP12 IP_PROT SIP 00 BL

DTAGSIP13 IP_PROT SIP 00 BL

Testcase Description
Ensure that the received INVITE from an UA with additional HEX-Digits in the Request-Line SIP_UNI_NNI_V_004
doesn't forward the INVITE and anwers with "404 not found";
Ensure that the received INVITE from an UA without CC (e.g. 09113333333) in the Request- SIP_UNI_NNI_V_005
Line forwards the INVITE with CC (e.g. +499113333333) to the LSS;
Ensure that the received INVITE from an UA without CC and without NDC (e.g. 5555) in the SIP_UNI_NNI_V_006
Request-Line forwards the INVITE with CC and with NDC (e.g. +4947115555) to the LSS
(Calling UA has Alias[0] +4947114711, i.e. same NDC should be used) ;
Ensure that the received INVITE from an UA with leading "00" and CC (e.g. 00499113333333) SIP_UNI_NNI_V_007
in the Request-Line forwards the INVITE without leading "00" but with "+" and CC (e.g.
+499113333333) to the LSS;
Ensure that the received INVITE from an UA with an ending "F" (e.g. +499113333333F) in SIP_UNI_NNI_V_008
the Request-Line forwards the INVITE without "F" (e.g. +499113333333) to the LSS;

Ensure that the received INVITE from an UA with "+ CC NDC SN" (e.g. +499113333333) in SIP_UNI_NNI_V_009
the Request-Line forwards the INVITE with the same format (e.g. +499113333333) to the
LSS;
Ensure that the received INVITE from an UA with a "ServiceRN" (e.g. 0800333333) in the SIP_UNI_NNI_V_010
Request-Line forwards the INVITE with the same format (e.g. +49800333333) to the LSS;

Ensure that the received INVITE from an UA with leading "00" and CC other than for Germany SIP_UNI_NNI_V_011
(e.g. Austria: 00435905917777) in the Request-Line forwards the INVITE without leading "00"
but with "+" and CC (e.g. +435905917777) to the LSS;
Ensure IUT establish a Call from Subscriber A to Subscriber B (PSTN) with an INVITE- SIP_UNI_NNI_V_PRACK_
Request containing "Supported: 100rel"; 001
Ensure IUT establish a Call from Subscriber A to Subscriber B (PSTN) with an INVITE- SIP_UNI_NNI_V_PRACK_
Request containing "Require: 100rel"; 002
Ensure IUT establish a Call from Subscriber A to Subscriber B (PSTN) with a required SIP_UNI_NNI_V_PRACK_
provisional response "PRACK" for a "180 Ringing"; 003
Ensure IUT establish a Call from Subscriber A to Subscriber B (PSTN) with a required SIP_UNI_NNI_V_PRACK_
provisional response "PRACK" for a "183 Session Progress"; 004
Ensure IUT establish a Call from Subscriber A to Subscriber B (PSTN) with a required SIP_UNI_NNI_V_PRACK_
provisional response "PRACK" for both "180 Ringing" and "183 Session Progress"; 005
NOTE:O-IWU refers to 5020 MGC
NOTE1:Mapping of IAM message to INVITE message-Called party Number maps to "TO" and "Request URI",Calli
Party Number maps to "P-Asserted-Identity","Privacy" and "From",Generic Number ("additional calling party num
maps to"From",Hop Counter maps to"Max-Forwards",TMR/USI maps to Message Body (application/SDP) and ISU
Message maps to Message Body (application/ISUP).

NOTE2: Both PCMA and PCMU required under some conditions.

Traceability used indicates the section numbers from Q.1912.5
TC # OBJECTIVE
Verify that, MGC should reject the INVITE from an untrusted adjacent SIP node
1 (ASN) with appropriate response (403 Forbidden) or use a default value ot it may
ignore the information.
Verify that, after receiving an IAM message the MGC (IWU) will send INVITE
2
to a trusted SIP node (ASN).
Verify that, after determining that the adjacent SIP node(ASN) is not trusted to
3 receive that information, the MGC shall take appropriate action (e.g ignore the
information, use a default value, or release the call).
4 Send an IAM message to MGC.
Send an SAM message to IWU.
Verify that, MGC should generate the INVITE message after getting IAM and
SAM only. IWU should support en-bloc signalling for SIP not over-lap
signalling.
Send an INVITE message from adjacent SIP Node (ASN) with encapsulated
5 IAM message to MGC. Verify that MGC should forward the IAM message to
SS7 entity.

Send an IAM message to MGC from SS7 entity, verify that INVITE should be
6
sent to ASN with IAM message encapsulated in the body of the message.

7 Make a call between SIP and SS7 using MGC.

Release the call from SIP entity by sending "BYE" , which doesn't contain
encapsulated "REL" message.
Verify that MGC should generate "REL" message towards SS7 after getting the
"BYE".
Send an IAM message to MGC, verify that MGC should generate an INVITE
8 message containing "Content-Type: application/ISUP;version=itu-t92+" and
"Content-Disposition: signal; handling = required".
Send an INVITE message to MGC with "Request-URI" different than "Called
Party Number" in the encapsulated IAM. Verify that MGC should send IAM to
9 SS7 entity with "Called Party Number" same as "Request-URI". The SIP header
should given precedence over the encapsulated ISUP value in the alignment
process unless otherwise stated.

Send an INVITE to MGC with encapsulated "Reset Circuit" message. Verify

10
that, MGC should ignore the "Reset Circuit" message.
Send an INVITE to MGC with encapsulated "Circuit Group Blocking" message.
11 Verify that, MGC should ignore the "Circuit Group Blocking" message.

Send an INVITE to MGC with encapsulated "Circuit Group Blocking

12 Acknowledgement" message. Verify that, MGC should ignore the "Circuit Group
Blocking Acknowledgement" message.
Send an INVITE to MGC with encapsulated "Group Reset" message. Verify that,
13
MGC should ignore the "Group Rest" message.
Send an INVITE to MGC with encapsulated "Circuit Group Reset
14 Acknowledgement" message. Verify that, MGC should ignore the "Circuit Group
Reset Acknowledgement" message.
Send an INVITE to MGC with encapsulated "Confusion" message. Verify that,
15
MGC should ignore the "Confusion" message.
Send an INVITE to MGC with encapsulated "Facility Reject" message. Verify
16
that, MGC should ignore the "Facility Reject" message.
Send an "183 Session Progress" for the INVITE message from the MGC with
17 encapsulated "User to User information" message. Verify that, MGC should
forward the " User to User information" message to SS7 entity.
Send an INVITE to MGC with encapsulated "Blocking" message. Verify that,
18
MGC should ignore the "Blocking" message.
Send an INVITE to MGC with encapsulated "Blocking Acknowledgement"
19 message. Verify that, MGC should ignore the "Blocking Acknowledgement"
message.
Send an INVITE to MGC with encapsulated "Continuity Check Request"
20 message. Verify that, MGC should ignore the "Continuity Check request"
message.
Send an INVITE to MGC with encapsulated "Continuity" message. Verify that,
21
MGC should ignore the "Continuity" message.
Send an INVITE to MGC with encapsulated "Unblocking" message. Verify that,
22
MGC should ignore the "Unblocking" message.
Send an INVITE to MGC with encapsulated "Unblocking Acknowledgement"
23 message. Verify that, MGC should ignore the "Unblocking Acknowledge"
message.
Send an INVITE to MGC with encapsulated "Circuit Group Unblocking"
24 message. Verify that, MGC should ignore the "Circuit Group Unblocking"
message.
Send an INVITE to MGC with encapsulated "Circuit Group Unblocking
25 Acknowledgement" message. Verify that, MGC should ignore the "Circuit Group
Unblocking Acknowledgement" message.
Send an INVITE to MGC with encapsulated "User part test" message. Verify
26
that, MGC should ignore the "User part test" message.
Send an INVITE to MGC with encapsulated "User part available" message.
27
Verify that, MGC should ignore the "User part available" message.
Send an "183 Session Progress" for the INVITE message from the MGC with
28 encapsulated "Forward Transfer" message. Verify that, MGC should forward the
"Forward Transfer " message to SS7 entity.
Send an "INFO" message with encapsulated "Suspend" message after the dialog
29 has been established to MGC. Verify that, MGC should forward the "Suspend"
message to SS7 entity.
Send an "INFO" message with encapsulated "Resume" message after the dialog
30 has been established to MGC. Verify that, MGC should forward the "Resume"
message to SS7 entity.
Send an "INFO" message with encapsulated "Facility Request" message after the
31 dialog has been established to MGC. Verify that, MGC should forward the
"Facility Request" message to SS7 entity.
Send an "INFO" message with encapsulated "Facility accepted" message after the
32 dialog has been established to MGC. Verify that, MGC should forward the
"Facility accepted" message to SS7 entity.
Send an "INFO" message with encapsulated "Facility" message after the dialog
33 has been established to MGC. Verify that, MGC should forward the "Facility"
message to SS7 entity.
Send an "INFO" message with encapsulated "Network Resource Managment"
34 message after the dialog has been established to MGC. Verify that, MGC should
forward the "Network Resource Managment" message to SS7 entity.
Send an "INFO" message with encapsulated "Identification Request" message
35 after the dialog has been established to MGC. Verify that, MGC should forward
the "Identification Request" message to SS7 entity.
Send an "INFO" message with encapsulated "Identification Response" message
36 after the dialog has been established to MGC. Verify that, MGC should forward
the "Identification Response" message to SS7 entity.
Send two consecutive "183 Session Progress" responses for the INVITE message
from the MGC with encapsulated "ACM" message and "Segmentataion" message
37 respectively . Verify that, MGC should forward the "ACM" and
"Segmentataion" messages to SS7 entity.
Send an "INFO" message with encapsulated "Loop prevention" message after the
38 dialog has been established to MGC. Verify that, MGC should forward the
"Loop prevention" message to SS7 entity.
Send an "INFO" message with encapsulated "Application Transport" message
39 after the dialog has been established to MGC. Verify that, MGC should forward
the "Application Transport" message to SS7 entity.
Send an "INFO" message with encapsulated "Pre-Release information" message
40 after the dialog has been established to MGC. Verify that, MGC should forward
the "Pre-Release information" message to SS7 entity.
Send an "INFO" message with encapsulated "Release Complete" message after
41 the dialog has been established to MGC. Verify that, MGC should forward the
"Release Complete" message to SS7 entity.
Send an IAM message to MGC with "Optional Forward call indicators"
42
containing "Simple segmentation indicator" set as 1.
Send a Segmentation (SGM) message containing segmented part after the IAM
message.
Verify that MGC should reassemble the original message in IAM with its
segmented message in SGM part and It should forward the INVITE message with
encapsulating resulting message to the terminating SIP entity.
Send an IAM message to MGC with "Optional Forward call indicators"
43
containing "Simple segmentation indicator" set as 1.
Send a Segmentation (SGM) message containing segmented part after the IAM
message.
Verify that MGC should reassemble the original message in IAM with its
segmented message in SGM part and It should forward the INVITE message with
encapsulating resulting message to the terminating SIP entity. It should set the
"Simple Segmentation Indicator" to 0 in "Optional Forward call indicators" of the
resulting message, if other indicators is set within the parameter.

Send an IAM message to MGC with "Optional Forward call indicators"

44
containing "Simple segmentation indicator" set as 1.
Send a Segmentation (SGM) message containing segmented part after the IAM
message.
Verify that MGC should reassemble the original message in IAM with its
segmented message in SGM part and It should forward the INVITE message with
encapsulating resulting message to the terminating SIP entity. It should discard
"Optional Forward call indicators" of the resulting message, if no other indicators
is set within the parameter.
45 Make a call between SIP-I and SS7.
Release the call by sending "BYE" with encapsulated "REL".
Verify that MGC should send "200 Ok" response with encapsulated "RLC".
46 Make call between SIP and SS7.
Verify that, MGC should include To tag in the first backward non-100
provisional response in order to establish an early dialog.
47 Generate a call between SIP to SS7.
Send a Re-INVITE .
Verify that, MGC do not require equivalent PSTN/ISDN service interworkig for
the Re-INVITE.
Send an INVITE message without SDP and without "Require: 100rel" to MGC.
48

Verify that MGC should generate the IAM message towards SS7 entity
immediately after getting INVITE message.
49 Send an INVITE message without SDP and with "Require: 100rel" to MGC.
Verify that MGC should send "183 Session Progress" with SDP, if MGC
operates as an international incomimg gateway and if G.711 encoding is used.
Precondition: MGC should operates as an international incoming gateway and
50
G.711 encoding is used.
Send an INVITE message without SDP and with "Require: 100rel" to MGC.
After getting "183 Session Progess" with SDP, send a PRACK with SDP to
MGC.
Verify that MGC should generate the IAM message towards SS7 entity
immediately after getting PRACK message.
Precondition: MGC should operates as an international incoming gateway and
51
G.711 encoding is used.
Send an INVITE message without SDP and with "Require: 100rel" to MGC.
Verify that, If the call is to be routed to an A-law PSTN network, then MGC
should send an SDP offer with A-law (PCMA), but not mu-law (PCMU)
included in the media description of "183 Session Progress".
Precondition: MGC should operates as an international incoming gateway and
52
G.711 encoding is used.
Send an INVITE message without SDP and with "Require: 100rel" to MGC.
Verify that, If the call is to be routed to an mu-law PSTN network, then MGC
should send an SDP offer with both A-law(PCMA) and mu-law (PCMU),
included in the media description of "183 Session Progress" and mu-law(PCMU)
should take precedence over A-law (PCMA).
Precondition: MGC should operates as an international incoming gateway and
53
G.711 encoding is used.
Send an INVITE message with SDP.
Verify that, if the call is to be routed to an A-law PSTN network then it shall
delete mu-law (PCMU) if present, from the media description that it will send
back in the SDP answer.
Precondition: MGC should operates as an international incoming gateway and
54
G.711 encoding is used.
Send an INVITE message with SDP.
Verify that, if the call is to be routed to an mu-law(PCMU) PSTN network, and if
both A-law (PCMA) and mu-law (PCMU) were present in the offer, then the I-
IWU shall delete A-law (PCMA) from the media description that it will send
back in the SDP answer.
Precondition: MGC should operates as an international incoming gateway and
55
G.711 encoding is used.
Send an appropriate INVITE message with SDP to MGC.
Verify that, MGC should send out the IAM immediately after getting the INVITE
message.
Send an INVITE with "Request-URI" containing "sip:" URI with "user=phone"
56 parameter, where the userinfo part of the URI is an E.164 number (RFC 2806) to
MGC.
Verify that, MGC should send out an IAM message with "Called Party Number"
Parameter same as the userinfo component.
57 Send an INVITE request to MGC from Adjacent SIP Node (ASN).
Verify that, MGC should send out an IAM message with "Calling Party's
Category" Parameter containing "Ordinary calling subscriber" (0000 1010).
Send an INVITE request with encapsulating IAM to MGC from Adjacent SIP
58
Node (ASN).
Verify that, MGC should send out an IAM message with "Calling Party's
Category" Parameter same as the "Calling Party's Category" parameter present in
the encapsulated ISUP.
59 Send an INVITE request to MGC from Adjacent SIP Node (ASN).
Verify that, MGC should send out an IAM message with "Nature of Connection
Indicators" Parameter containing .
bits BA Satellite indicator
01 One satellite circuit in the connection
bits DC Continuity check indicator
00 Continuty check not required
bit E Echo control device indicator
1 Outgoing echo control device included (Profile A)
0 Outgoing echo control device not included (Profile B)
Send an INVITE request with encapsulating IAM to MGC from Adjacent SIP
60
Node (ASN).
Verify that, MGC should generate the "Nature of Connection Indicators"
Parameter by using "Nature of Connection Indicators" received in the
encapsulated IAM message.
61 Send an INVITE request (Profile A) to MGC.
Verify that, MGC should send out an IAM message with "Forward Call
Indicators" Parameter containing
Bits Codes Meaning
A 0 Call to be treated as a national call
D 1 Interworking encountered
F 0 ISDN user part not used all the way
HG 01 ISDN user part not required all the way
I 0 Orginating access non-ISDN
Send an INVITE request with encapsulating IAM to MGC from Adjacent SIP
62
Node (ASN).
Verify that, MGC should generate the "Forward Call Indicators " Parameter by
using "Forward Call Indicators" received in the encapsulated IAM message.
63 Send an INVITE request (Profile A) to MGC.
Verify that, MGC should send out IAM with "TMR" parameter set to 3.1 kHz
audio. IAM should not contain "USI" parameter.
64 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP 0
b= N/A or up to 64 kbit/s
a= N/A" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "3.1
kHHz audio" and USI parameter containing "Information Transport Capability"
as "3.1 kHz audio" and "User Information Layer 1 Protocol Indicator" as "G.711
mu-law" .
65 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP Dynamic PT
b= N/A or up to 64 kbit/s
a= rtpmap: <payload type> PCMU/8000" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "3.1
kHHz audio" and USI parameter containing "Information Transport Capability"
as "3.1 kHz audio" and "User Information Layer 1 Protocol Indicator" as "G.711
mu-law" .
66 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP 8
b= N/A or up to 64 kbit/s
a= N/A" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "3.1
kHHz audio" and USI parameter containing "Information Transport Capability"
as "3.1 kHz audio" and "User Information Layer 1 Protocol Indicator" as "G.711
A-law" .
67 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP Dynamic PT
b= N/A or up to 64 kbit/s
a= rtpmap: <payload type> PCMA/8000" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "3.1
kHHz audio" and USI parameter containing "Information Transport Capability"
as "3.1 kHz audio" and "User Information Layer 1 Protocol Indicator" as "G.711
A-law" .
68 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP 9
b= AS:64 kbit/s
a= rtpmap: 9 G722/8000" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "64
kbit/s unrestricted" and USI parameter containing "Information Transport
Capability" as "Unrestricted digital inf. w/tones/ann".
69 Send an INVITE request with SDP (Profile B) to MGC.
Put "m= audio RTP/AVP Dynamic PT
b= AS:64 kbit/s
a= rtpmap: <payload type> CLEARMODE/8000" in the SDP
Verify that, MGC should send out IAM with "TMR" parameter containing "64
kbit/s unrestricted" and USI parameter containing "Information Transport
Capability" as "Unrestricted digital information".
Send an INVITE request with encapsulating IAM to MGC from Adjacent SIP
70
Node (ASN).
Verify that, MGC should generate the "TMR", "USI", "HLC" Parameter by using
"TMR", "USI", "HLC" received in the encapsulated IAM message respectively.

Send an INVITE request with encapsulating IAM to MGC from Adjacent SIP
71
Node (ASN).
Verify that, if the USI parameter is present in the encapsulated ISUP, G.711 is
used, and the MGC is an international gateway, then the User Information Layer1
Protocol indicator of the USI parameter shall be set in accordance with the
encoding law of subsequesnt ISUP network.
Note: MGC may generate IAM message with CgPN parameter as given in
Test case 72 or Test case 73.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header not
72 containing a URI with an identity in the format "+" CC+NDC+SN and without
Privacy header.
Verify that, MGC should send out an IAM message with CgPN paramter field
with a CLI (network option) as follows
ISUP CgPN parameter field Value
Screening Indicator "Network provided"

Number Incomplete Indicator "complete"

Numbering Plan Indicator "ISDN/Telephony
(E.164)"
Address Presentation Restricted Indicator "Presentation
allowed/restricted"
Nature of Address Indicator "If ISUP node is in same country
"national number" else "international number"
Address Signals "If NOA is "national number" no country code
should be included"
"If NOA is "international number", then the country code of the
network-provided number should be included."
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header not
73 containing a URI with an identity in the format "+" CC+NDC+SN and without
Privacy header.
Verify that, MGC should send out an IAM message with CgPN paramter field
with a CLI (network option) as follows
ISUP CgPN parameter field Value
Screening Indicator "Network provided"

Numbering Plan Indicator "ISDN/Telephony

(E.164)"
Address Presentation Restricted Indicator "Address not available"

Nature of Address Indicator "If ISUP node is in same country

"national number" else "international number"
Address Signals -------------------------

Note: MGC may generate IAM message with CgPN parameter as given in
Test case 74 or Test case 75.
Send an INVITE message to MGC with From header containing a URI with an
identity in the format "+" CC+NDC+SN and P-Asserted-Identity header not
74 containing a URI with an identity in the format "+" CC+NDC+SN and without
Privacy header.
Verify that, MGC should send out an IAM message with
(a) CgPN paramter field with a CLI (network option) as follows
ISUP CgPN parameter field Value
Screening Indicator "Network provided"

Numbering Plan Indicator "ISDN/Telephony

(E.164)"
Address Presentation Restricted Indicator "Presentation
allowed/restricted"
Nature of Address Indicator "If ISUP node is in same country
"national number" else "international number"
Address Signals "If NOA is "national number" no country code
should be included"
"If NOA is "international number", then the country code of the
network-provided number should be included."
(b) Generic Number derived from the SIP "From" header.
Send an INVITE message to MGC with From header containing a URI with an
identity in the format "+" CC+NDC+SN and P-Asserted-Identity header not
75 containing a URI with an identity in the format "+" CC+NDC+SN and without
Privacy header.
Verify that, MGC should send out an IAM message with
(a) CgPN paramter field with a CLI (network option) as follows
ISUP CgPN parameter field Value
Screening Indicator "Network provided"

Numbering Plan Indicator "ISDN/Telephony

(b) Generic Number derived from the SIP "From" header.

Send an INVITE message to MGC with From header not containing a URI with
76 an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
containing a URI with an identity in the format "+" CC+NDC+SN.
Verify that, MGC should send out IAM message with CgPN derived from the P-
Asserted-Identity header and the APRI = "presentation restricted" or
"presentation allowed" depending on Privacy header.
Send an INVITE message to MGC with From header containing a URI with an
77 identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
containing a URI with an identity in the format "+" CC+NDC+SN.
(a) CgPN derived from the P-Asserted-Identity header and APRI = "Presentation
Restricted" or "Presentation Allowed" depending on Privacy header.

(b) Generic Number derived from the SIP "From" header and APRI =
"Presentation Restricted" or "Presentation Allowed" depending on Privacy
header.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
78 containing a URI with an identity in the format "+" CC+NDC+SN and without
Privacy header field.
Verify that, the APRI of Calling Party Number indicator should be "Presentation
allowed" in the IAM message, send out by MGC.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
79 containing a URI with an identity in the format "+" CC+NDC+SN and with
Privacy: none.
Verify that, the APRI of Calling Party Number indicator should be "Presentation
allowed" in the IAM message, send out by MGC.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
80 containing a URI with an identity in the format "+" CC+NDC+SN and with
Privacy:header.
Verify that, the APRI of Calling Party Number indicator should be "Presentation
Restricted" in the IAM message, send out by MGC.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
81 containing a URI with an identity in the format "+" CC+NDC+SN and with
Privacy:user.
Verify that, the APRI of Calling Party Number indicator should be "Presentation
Restricted" in the IAM message, send out by MGC.
Send an INVITE message to MGC with From header not containing a URI with
an identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
82 containing a URI with an identity in the format "+" CC+NDC+SN and with
Privacy:id.
Verify that, the APRI of Calling Party Number indicator should be "Presentation
Restricted" in the IAM message, send out by MGC.
Send an INVITE message to MGC with P-Asserted-Identity header containing a
83
URI with an identity in the format "+" CC+NDC+SN.
Verify that, (a) The Address Signals of the Calling Party Number parameter field
is set to NDC+SN if NOA is "national (significant) number".
(b) The Address Signals of the Calling Party Number parameter field is set to
CC+NDC+SN if NOA is "international number"
Send an INVITE message to MGC with From header containing a URI with an
84 identity in the format "+" CC+NDC+SN and P-Asserted-Identity header
containing a URI with an identity in the format "+" CC+NDC+SN.
Verify that, MGC should send out an IAM message with Generic Number
parameter field containing
Generic Number parameter field Value
Number Qualifier Indicator "additional calling party
number"
Nature of Address Indicator "If ISUP node is in same country "national
number" else "international number"
Number Incomplete Indicator "Complete"
Numbering Plan Indicator "ISDN/Telephony
(E.164)"
Address Presentation Restricted Indicator "Presentation allowed/restricted"

Address Signals "If NOA is "national number" then set to

NDC+SN" "If NOA is "ineternational number" then set to
CC+NDC+SN"
Send an INVITE with Max-Forwards header field to MGC. Verify that MGC
85
should send out IAM message with Hop Counter parameter.
Send an INVITE with encapsulated IAM message to MGC. Verify that MGC
should send out IAM with "Hop Counter" parameter. MGC should generate the
86 "Hop Counter" parameter by using the "Hop Counter" parameter in the
encapsulated IAM.
Send an INVITE message without Max-Forwards header field to MGC, check for
87
the Hop Counter parameter in the IAM message sent by MGC.
Send an INVITE message without Max-Forwards header field and with
88 encapsulated IAM containing "Hop Counter" parameter to MGC, check for the
Hop Counter parameter in the IAM message sent by MGC.
Send an INVITE message to MGC. Verify that MGC should generate IAM
message with Continuity check indicator set to "continuity check required in this
89 circuit" and after Continuity check is done, MGC should generate COT message
with "Continuity check successful" .
Send an INVITE message to MGC. Verify that MGC should generate 200 Ok
90
INVITE for the "CON" message received from SS7 entity.
Make a SIP-I to SS7 call. Verify that, MGC should generate 200 Ok for INVITE
91
with encapsulated "CON" message received from SS7 entity.
Make a SIP to SS7 call. Send an ACM from SS7 entity with Called Party's Satus
92 Indicator(BCI) set to "No indication". Verify that MGC should send out "183
Session Progress" towards SIP entity.
Make a SIP to SS7 call. Send an ACM from SS7 entity with Called Party's Satus
93 Indicator(BCI) set to "Subscriber free". Verify that MGC should send out "180
Ringing" towards SIP entity.
Make a SIP-I to SS7 call. Send an ACM from SS7 entity with Called Party's
94 Satus Indicator(BCI) set to "Subscriber free". Verify that MGC should send out
"180 Ringing" towards SIP entity with encapsulated ACM message.
Make a SIP-I to SS7 call. Send an ACM from SS7 entity with Called Party's
95 Satus Indicator(BCI) set to "No Indication". Verify that MGC should send out
"183 Session Progress" towards SIP entity with encapsulated ACM message.
Make a SIP to SS7 call. Send an CPG from SS7 entity with Event Inficator set to
96 "alerting". Verify that MGC should send out "180 Ringing" towards SIP entity.

Make a SIP-I to SS7 call. Send an CPG from SS7 entity with Event indicator set
99 to "alerting". Verify that MGC should send out "180 Ringing" towards SIP entity
with encapsulated CPG message.
Make a SIP-I to SS7 call. Send an CPG from SS7 entity with Event indicator set
100 to "progress". Verify that MGC should send out "183 Session Progress" towards
SIP entity with encapsulated CPG message.
Make a SIP-I to SS7 call. Send an CPG from SS7 entity with Event indicator set
to "in-band information or an appropriate pattern is now available". Verify that
101 MGC should send out "183 Session Progress" towards SIP entity with
encapsulated CPG message.
Make a SIP-I to SS7 call. Send an ANM from SS7 entity after ACM. Verify that
102 MGC should send out "200 Ok" for INVITE towards SIP entity with
encapsulated ANM.
Make a SIP to SS7 call. Release the call from SIP entity by sending "BYE".
103 Verify that, MGC should generate "REL" message towards the SS7 entity with
Cause Value No. 16 (Normal call clearing)
Make a SIP-I to SS7 call. Release the call from SIP entity by sending "BYE"
104 with encapsulated "REL" message. Verify that, MGC should generate "REL"
message towards the SS7 entity.
Send an INVITE message to MGC. After receiving "183 Session Progress" from
105 MGC, send CANCEL request. Verify that, MGC should send "REL" towards
SS7 entity with Cause Value No. 31 (normal, unspecified).
Send an INVITE message with Request-URI containing unroutable number to
106 MGC. Verify that MGC should send "480 Temporarily Unavailable" to SIP
entity.
Send an INVITE with incomplete address in the Request-URI to MGC. Verify
107 that MGC should send "484 Address Incomplete" response to SIP entity. (Valid
for SIP-I)
For Autonomous Release by MGC, It should send BYE to SIP entity if the call is
108
answered.(Valid for SIP-I)
For Autonomous Release by MGC, It should send CANCEL to SIP entity if the
109
call is not answered.(Valid for SIP-I)
Send an appropriate INVITE message to MGC. Don't send any response from the
110 SS7 entity for the received IAM message. Verify that MGC should send "500
Server Internal Error" to SIP entity.
Send an appropriate INVITE message to MGC.Send a RSC message from SS7
111 entity to MGC after receiving IAM message. Verify that, MGC should send "500
Server Internal Error" to SIP entity.
Send an appropriate INVITE message to MGC.Send a GRS message from SS7
112 entity to MGC after receiving IAM message. Verify that, MGC should send "500
Server Internal Error" to SIP entity.
Send an appropriate INVITE message to MGC.Send a CGB message with the
Circuit Group Supervision Message Type indicator coded as "hardware failure
113 oriented" from SS7 entity to MGC after receiving IAM message. Verify that,
MGC should send "500 Server Internal Error" to SIP entity.
Make the call between SIP and SS7. After sending ACK from SIP entity, send a
114 RSC message from SS7 entity to MGC. Verify that MGC will send a BYE to SIP
entity after receiving the RSC message.
Make the call between SIP and SS7. After sending ACK from SIP entity, send a
115 GRS message from SS7 entity to MGC. Verify that MGC will send a BYE to SIP
entity after receiving the GRS message.
Make the call between SIP and SS7. After sending ACK from SIP entity, send a
CGB message with the Circuit Group Supervision Message Type indicator coded
116 as "hardware failure oriented" from SS7 entity to MGC. Verify that MGC will
send a BYE to SIP entity after receiving the CGB message.
Make the call between SIP and SS7. Don't send ACK from SIP entity, send a
117 RSC message from SS7 entity to MGC. Verify that MGC will send a BYE to SIP
entity only after receiving the ACK message.
Make the call between SIP and SS7. Don't send ACK from SIP entity, send a
118 GRS message from SS7 entity to MGC. Verify that MGC will send a BYE to SIP
entity only after receiving the ACK message.
Make the call between SIP and SS7. Don't send ACK from SIP entity, send a
CGB message with the Circuit Group Supervision Message Type indicator coded
119 as "hardware failure oriented" from SS7 entity to MGC. Verify that MGC will
send a BYE to SIP entity only after receiving the ACK message.
Send an appropriate INVITE message with encapsulated IAM message to
MGC.Send a RSC message from SS7 entity to MGC after receiving IAM
120 message. Verify that, MGC should send "500 Server Internal Error" with
encapsulated REL message to SIP entity.
Send an appropriate INVITE message with encapsulated IAM message to
MGC.Send a GRS message from SS7 entity to MGC after receiving IAM
121 message. Verify that, MGC should send "500 Server Internal Error" with
encapsulated REL message to SIP entity.
Send an appropriate INVITE message with encapsulated IAM message to
MGC.Send a CGB message with the Circuit Group Supervision Message Type
122 indicator coded as "hardware failure oriented" from SS7 entity to MGC after
receiving IAM message. Verify that, MGC should send "500 Server Internal
Error" with encapsulated REL message to SIP entity.

Make the call between SIP-I and SS7. After sending ACK from SIP entity, send a
RSC message from SS7 entity to MGC. Verify that MGC will send a BYE with
123 encapsulated REL message to SIP entity after receiving the RSC message.

Make the call between SIP-I and SS7. After sending ACK from SIP entity, send a
GRS message from SS7 entity to MGC. Verify that MGC will send a BYE with
124 encapsulated REL message to SIP entity after receiving the GRS message.

Make the call between SIP-I and SS7. After sending ACK from SIP entity, send a
CGB message with the Circuit Group Supervision Message Type indicator coded
125 as "hardware failure oriented" from SS7 entity to MGC. Verify that MGC will
send a BYE with encapsulated REL message to SIP entity after receiving the
CGB message.

Make the call between SIP-I and SS7. Don't send ACK from SIP entity, send a
126 RSC message from SS7 entity to MGC. Verify that MGC will send a BYE to
SIP-I entity only after receiving the ACK message.
Make the call between SIP-I and SS7. Don't send ACK from SIP entity, send a
127 GRS message from SS7 entity to MGC. Verify that MGC will send a BYE to
SIP-I entity only after receiving the ACK message.
Make the call between SIP-I and SS7. Don't send ACK from SIP entity, send a
CGB message with the Circuit Group Supervision Message Type indicator coded
128 as "hardware failure oriented" from SS7 entity to MGC. Verify that MGC will
send a BYE to SIP-I entity only after receiving the ACK message.
Send an IAM message with CDPN which is not in the form of an E.164
international public telecommunication number, the O-IWU shall add the country
129 code or the country code and national destination code of the preceding exchange
to form the international
public telecommunication number in the INVITE message.

130
Send an IAM and SAM
message is sent for complete called party addressing. verify that INVITE

131 Send an IAM message

with maximum number of digits used in the national numbering plan (complete
CDPN address); and verify that INVITE message is generated at the end of
receipt of the maximum number along with en bloc parameter.

132 Send an IAM message

with called party number (sufficient enough to route the call to the called party);
and verify that INVITE message is generated at the end of receipt of the routing

133
Send an IAM message
and verify that INVITE message is generated after TOIW1 timer is expired along
Send an IAM message with incomplete address digits followed by SAM ,O-IWU
134 invokes the appropriate outgoing INVITE message and restarts the timer TOIW2.

O-IWU triggers an INVITE (NOTE:1)without any delay,when the ISUP IAM

(possibly followed by SAMs) is received and the Continuity
135 Check indicator in Nature of Connection Indicator parameter is set to "continuity
check not required".
INVITE(NOTE1) shall be sent from O-IWU on receipt of the Continuity message
136 with the Continuity Indicators parameter set to "continuity check successful".

INVITE(NOTE1) shall not be sent if the Continuity message is received with the
137 Continuity Indicators parameter set to "continuity check failed" or the ISUP timer
T8 expires.
Send an IAM message with TMR/USI as AMR codec and verify that O-IWU
generates an INVITE message with "RTP payload format and file storage format
138 for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-
WB) audio codec".
Send an IAM with A-law companding, the O-IWU shall send an INVITE SDP
139 Offer with A-law (PCMA), but not µ-law (PCMU) included in the media
description.
Send an IAM message with µ-law companding, the O-IWU shall send an
140 INVITE SDP Offer with both µ-law (PCMU) and A-law (PCMA) included in the
media description and PCMU shall take precedence over PCMA.
send an IAM with TMR "speech" / USI "Speech-G.711 M-law" and verify that
141 MGC generates an INVITE message with m=audio RTP/AVP 0/8, b=AS:64,
a=rtpmap:0 PCMU/8000.
send an IAM with TMR "speech" / USI "Speech-G.711 M-law" and verify that
142 MGC generates an INVITE message with m=audio RTP/AVP Dynamic
PT(NOTE2), b=AS:64, a=rtpmap:<payload> PCMU/8000.
send an IAM with TMR "speech" / USI "Speech-G.711 A-law" and verify that
143 MGC generates an INVITE message with m=audio RTP/AVP 8, b=AS:64,
a=rtpmap:8 PCMA/8000.
send an IAM with TMR "speech" / USI "Speech-G.711 A-law" and verify that
144 MGC generates an INVITE message with m=audio RTP/AVPDYNAMIC PT,
b=AS:64, a=rtpmap:<payload> PCMA/8000.
send an IAM with TMR "3.1khz audio" ,verify that MGC generates an INVITE
145
message with m=audio RTP/AVP 0/8, b=AS:64, a=rtpmap:0/8 PCMU/8000.
send an IAM with TMR "3.1khz audio" / USI as "3.1khz audio G.711 m-law"
146 ,verify that MGC generates an INVITE message with m=audio RTP/AVP 0/8,
b=AS:64, a=rtpmap:0/8 PCMU/8000.
send an IAM with TMR "3.1khz audio" / USI as "3.1khz audio G.711 A-law"
147 ,verify that MGC generates an INVITE message with m=audio RTP/AVP 0/8,
b=AS:64, a=rtpmap:0/8 PCMA/8000.
Send an IAM with TMR="3.1 kHz audio"/ USI as "3.1 kHz audio" and HLC IE
148 as"Facsimile Group 2/ 3",verify that MGC generates an INVITE with m=image
udptl t38,b=AS: 64 a=Based on ITU- T Rec. T. 38.
Send an IAM with TMR="3.1 kHz audio"/ USI as "3.1 kHz audio" and HLC IE
149 as"Facsimile Group 2/ 3",verify that MGC generates an INVITE with m=image
tcptl t38,b=AS: 64 a=Based on ITU- T Rec. T. 38.
Send an IAM with TMR="64 kbit/s unrestricted"/USI="Unrestricted digital
150 inf.W/ tone/ ann.",verify that MGC generates an INVITE with m=audio RTP/
AVP 9 b=AS: 64 and a=rtpmap: 9 G722/ 8000.
Send an IAM with TMR="64 kbit/s unrestricted"/USI="Unrestricted digital
151 information",verify that MGC generates an INVITE with m=audio RTP/ AVP
Dynamic PT ,b=AS: 64 and a=rtpmap:< payload type>CLEARMODE/ 8000.
CDPN of the IAM and ASI of SAM sent to O-IWU derives an INVITE with the
152 userinfo component of the Request-URI, addr-spec component of the To header
field and both the field contains a sip:URI along with "user=phone".
Send IAM with Generic Number parameter with Number Qualifier Indicator is
set to "additional calling partynumber" and NoA is set to National(NDC+SN).
153 Verify that MGC generate an INVITE with From header field with (display-name
(optional) ) CC + Generic Number Address Signals mapped to userportion of
URI scheme used.

Send IAM with Generic Number parameter with Number Qualifier Indicator is
set to "additional calling partynumber" and NoA is set to
154 International(CC+NDC+SN). Verify that MGC generate an INVITE with From
header field with (display-name (optional) ) + Generic Number Address Signals
mapped to userportion of URI scheme used.

Send IAM with calling party Number- ,NOA-National(NDC+SN),verify that

MGC should generate INVITE with P-asserted identity header field with display-
155 name (optional) and addr-spec with added CC (of the country where theIWU is
located) to Generic Number Address Signals then map to userportion of URI
scheme used.

Send IAM with calling party Number- ,NOA-International(CC+NDC+SN),verify

that MGC should generate INVITE with P-asserted identity header field with
156 display-name (optional) and addr-spec "+" CC NDC SN mapped to the
appropriate global Number portion of URI scheme used.

Send IAM with calling party Number- ,NOA-National(NDC+SN),verify that

MGC should generate INVITE with From header field with display-name
157 (optional) and addr-spec with added CC (of the country where theIWU is located)
to Generic Number Address Signals then map to userportion of URI scheme
used.

Send IAM with calling party Number- ,NOA-International(CC+NDC+SN),verify

that MGC should generate INVITE with From header field with display-name
158 (optional) and addr-spec "+" CC NDC SN mapped to the appropriate global
Number portion of URI scheme used.
Send IAM with calling party Number ,APRI="presentation restricted",verify that
159 MGC should generate INVITE with privacy header field with priv-value=id.

Send IAM with calling party Number ,APRI="presentation allowed",verify that

160
MGC should generate INVITE without privacy header field.
Send an IAM with Hop counter value=x and verify that MGC generates INVITE
161
with Max-Forward value Y=Interger part of (X*factor).
Send an IAM with NOC indicator and verify that O-IWU shall increment the
162 satellite indicator in the Nature of Connection Indicators parameter of the
encapsulated IAM.
Send an IAM with NOC indicator and verify that O-IWU should increase the
Propagation Delay Counter parameter by an appropriate value based on available
163 network configuration data that represents the delay of the IP network of the
encapsulated IAM.
when en bloc addressing is used toward the SIP network, subsequent SAMs
164 received after the O-IWU has sent the INVITE are ignored if the TOIW2 timer
has expired.
Send a SAM message with further addressing after O-IWU sends an INVITE
165 message,verify that O-IWU sends INFO message carring the SAM information.

On receiptt of the SAM message, stop the TOIW3 timer(if it is running), timer
166
TOIW2 shall be restarted with an outgoing INVITE message.
Send a SAM message after the O-IWU has generated an INVITE message for
167 IAM and verify that the Request-URI and the To header field of the new INVITE
shall contain all digits received so far for this call.
Send a SAM message after the O-IWU has generated an INVITE message for
IAM and new INVITE with the same Call-ID and From header (including tag) as
168 the previous INVITE is sent. In the Profile C (SIP-I) case, the IAM which was
sent with the original INVITE is also encapsulated in the new INVITE.
Send a SAM message after the O-IWU has generated an INVITE message for
169
IAM and verify that new INVITE shall contain a new SDP offer.
170 On receiptt of ACM/CPG ISUP message,MGC generate 18x response
On receipt of a 180 Ringing message, timer TOIW2 (if running) is stopped. If a
180 Ringing is received without any encapsulated ISUP message, the O-IWU
171 shall send either the ACM or CPG message as determined by BICC/ISUP
procedures related to whether or not an ACM has previously been sent for this
call.

For Profile C (SIP-I), if 180 Ringing is received with encapsulated ACM or CPG
message, theO-IWU shall send ACM with backward call Indicator with Called
172 Party's Status Indicator (Bit DC) is set to "subscriber free" or CPG message with
Event information set to "alerting". Timer TOIW2 shall be stopped(if running).

For Profile C (SIP-I), if 183 session progress is received with encapsulated ACM
or CPG message, theO-IWU shall ACM with backward call Indicator with Called
173 Party's Status Indicator (Bit DC) is set to "subscriber free". Timer TOIW2 shall
be stopped(if running).
On receipt of 183 with SDP(183 not received before)and reason header with
174 cause valse, Verify that MGC sends ACM with the same cause value being
mapped.
On TOIW2 timer expiry the O-IWU shall send an ACM with Called Party's
175
Status Indicator (Bit DC) of BCI parameter is set to "no indication".
If the continuity check is performed (ISUP) or COT is expected, the O-IWU shall
176 withhold sending ACM until a successful continuity indication has been received.

200 OK INVITE is received with encapsulated CON or ANM message, Verify

177 that O-IWU sends an appropriate backward ISUP message and parameters based
on the encapsulated ISUP message.
On receipt of multiple 200 OK for the same INVITE message,O-IWU should
178
accept the first 200 OK and discard any further 200OK.
REL message received at O-IWU before a response has been received which
establishes a confirmed dialogue or early dialogue:
179 The O-IWU shall send a CANCEL request. If the O-IWU subsequently receives
a 200 OK INVITE, then it shall send an ACK for the 200 OK INVITE and
subsequently send a BYE request after the ACK has been sent.

REL message received at O-IWU after a response has been received which
180 establishes a confirmed dialogue:
The O-IWU shall send a BYE request.
On receipt of SIP BYE, the O-IWU shall send an ISUP REL message(with cause
181 value as "normal clearing) to the ISUP side(In the case of Profile C, the
encapsulated REL shall be passed to ISUP procedures without modification).
COT received with continuity Indicator parameter set set to "continuity check
182
failed" then the O-IWU will send CANCEL or BYE.
When resource reservation is unsuccessful then O-Iwu shall send a REL with
183
cause value 47(resource unavialable).
On receipt of RSC, GRS or CGB (ISUP) the O-IWU shall send CANCEL or
184
BYE.
On receipt of 400 Bad request response the O-IWU shall send a REL with cause
185
value 127 "interworking".
On receipt of 401 Unauthorized response the O-IWU shall send a REL with cause
186
value 127 "interworking".
On receipt of 402 Payment Required response the O-IWU shall send a REL with
187
cause value 127 "interworking".
On receipt of 403 Forbidden response the O-IWU shall send a REL with cause
188
value 127 "interworking".
On receipt of 404 Not Found response the O-IWU shall send a REL with cause
189
value 1 Unallocated number.
On receipt of 405 Method Not Allowed response the O-IWU shall send a REL
190
with cause value 127 "interworking".
On receipt of 406 Not Acceptable response the O-IWU shall send a REL with
191
cause value 127 "interworking".
On receipt of 407 Proxy authentication required response the O-IWU shall send a
192
REL with cause value 127 "interworking".
On receipt of 408 Request Timeout response the O-IWU shall send a REL with
193
cause value 127 "interworking".
On receipt of 410 Gone response the O-IWU shall send a REL with cause
194
value22 Number changed (without diagnostic).
On receipt of 413 Request Entity too long response the O-IWU shall send a REL
195
with cause value 127 "interworking".
On receipt of 414 Request-uri too long response the O-IWU shall send a REL
196
with cause value 127 "interworking".
On receipt of 415 Unsupported Media type response the O-IWU shall send a
197
REL with cause value 127 "interworking".
On receipt of 416 Unsupported URI scheme response the O-IWU shall send a
198
REL with cause value 127 "interworking".
On receipt of 420 Bad Extension response the O-IWU shall send a REL with
199
cause value 127 "interworking".
On receipt of 421 Extension required response the O-IWU shall send a REL with
200
cause value 127 "interworking".
On receipt of 423 Interval Too Brief response the O-IWU shall send a REL with
201
cause value 127 "interworking".
On receipt of 480 Temporarily Unavailable response the O-IWU shall send a
202
REL with cause value 20 Subscriber absent.
On receipt of 481 Call/Transaction does not exist response the O-IWU shall send
203
a REL with cause value 127 "interworking".
On receipt of 482 Loop Detected response the O-IWU shall send a REL with
204
cause value 127 "interworking".
On receipt of 483 Too many hops response the O-IWU shall send a REL with
205
cause value 127 "interworking".
On receipt of 484 Address Incomplete response the O-IWU shall send a REL
206
with cause value 28 Invalid Number format unless the timer expires.
On receipt of 485 Ambiguous response the O-IWU shall send a REL with cause
207
value 127 "interworking".
On receipt of 486 Busy Here response the O-IWU shall send a REL with cause
208
value 17 User busy.
On receipt of 487 Request terminated response the O-IWU shall send a REL with
209
cause value127 Interworking or no mapping.
On receipt of 488 Not acceptable here response the O-IWU shall send a REL
210
with cause value 127 "interworking".
On receipt of 493 Undecipherable response the O-IWU shall send a REL with
211
cause value 127 "interworking".
On receipt of 500 Server Internal error response the O-IWU shall send a REL
212
with cause value 127 "interworking".
On receipt of 501 Not implemented response the O-IWU shall send a REL with
213
cause value 127 "interworking".
On receipt of 502 Bad Gateway response the O-IWU shall send a REL with cause
214
value 127 "interworking".
On receipt of 503 Service Unavailable response the O-IWU shall send a REL
215
with cause value 127 "interworking".
On receipt of 504 Server timeout response the O-IWU shall send a REL with
216
cause value 127 "interworking".
On receipt of 505 Version not supported response the O-IWU shall send a REL
217
with cause value 127 "interworking".
On receipt of 513 Message too large response the O-IWU shall send a REL with
218
cause value 127 "interworking".
On receipt of 580 Precondition failure response the O-IWU shall send a REL
219
with cause value 127 "interworking".
On receipt of 600 Busy Everywhere response the O-IWU shall send a REL with
220
cause value 17 User busy.
On receipt of 603 Decline response the O-IWU shall send a REL with cause
221
value 21 Call rejected.
On receipt of 604 Does not exist anywhere response the O-IWU shall send a REL
222
with cause value1 Unallocated number".
On receipt of 606 Not acceptable response the O-IWU shall send a REL with
223
cause value 127 "interworking".
On receipt of REL message with Cause Value No. 1 ("unallocated (unassigned)
224
number"),the O-IWU shall send SIP response as 404 Not Found.
On receipt of REL message with Cause Value No. 2 ("no route to network"),the
225
O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 3 ("no route to
226
destination"),the O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 4 ("Send special information
227
tone"),the O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 5 ("Misdialled trunk
228
prefix"),the O-IWU shall send SIP response as 404 Not Found.
On receipt of REL message with Cause Value No. 8 ("Preemption"),the O-IWU
229
shall send SIP response as 500 Server Internal Error (SIP-I only).
On receipt of REL message with Cause Value No. 9 ("Preemption-circuit
230 reserved for reuse"),the O-IWU shall send SIP response as 500 Server Internal
Error (SIP-I only).
On receipt of REL message with Cause Value No. 17 ("user busy"),the O-IWU
231
shall send SIP response as 486 Busy Here.
On receipt of REL message with Cause Value No. 18 ("no user responding"),the
232 O-IWU shall send SIP response as 480 Temporarily unavailable

On receipt of REL message with Cause Value No. 19 ("no answer from the
233
user"),the O-IWU shall send SIP response as 480 Temporarily unavailable.
On receipt of REL message with Cause Value No. 20 ("subscriber absent"),the
234
O-IWU shall send SIP response as 480 Temporarily unavailable
On receipt of REL message with Cause Value No. 21 ("call rejected"),the O-IWU
235
shall send SIP response as 480 Temporarily unavailable.
On receipt of REL message with Cause Value No. 22 ("number changed"),the O-
236
IWU shall send SIP response as 410 Gone
On receipt of REL message with Cause Value No. 23 ("redirection to new
237
destination"),the O-IWU shall send SIP response as No mapping.
On receipt of REL message with Cause Value No. 25 ("Exchange routing
238
error"),the O-IWU shall send SIP response as 480 Temporarily unavailable
On receipt of REL message with Cause Value No. 27 ("destination out of
239
order"),the O-IWU shall send SIP response as 502 Bad Gateway
On receipt of REL message with Cause Value No. 28 ("invalid number format
240 (address incomplete")),the O-IWU shall send SIP response as 484 Address
Incomplete.
On receipt of REL message with Cause Value No. 29 ("facility rejected"),the O-
241
IWU shall send SIP response as 500 Server Internal Error
On receipt of REL message with Cause Value No. 31 ("normal, unspecified")
242 (Class default),the O-IWU shall send SIP response as 480 Temporarily
unavailable.
On receipt of REL message with includes the Cause Value in the Class 010
(resource unavailable,Cause Value No. 34),the O-IWU shall send SIP response as
243 486 Busy here if Diagnostics Indicatorincludes the (CCBS indicator =
"CCBSpossible") else 480 Temporarily unavailable

On receipt of REL message with Cause Value in the Class 010 (resource
244 unavailable,Cause Value No. 38-47)(47 is class default),the O-IWU shall send
SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 50 ("requested facility not
245
subscribed"),the O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 55 ("incoming calls barred
246 within CUG"),the O-IWU shall send SIP response as 500 Server Internal Error
(SIP-I only).
On receipt of REL message with Cause Value No. 57 ("bearer capability not
247
authorized"),the O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 58 ("bearer capability not
248 presently available"),the O-IWU shall send SIP response as 500 Server Internal
Error.
On receipt of REL message with Cause Value No. 63 ("service or option not
249 available,unspecified")(Class default),the O-IWU shall send SIP response as 500
Server Internal Error.
On receipt of REL message with Cause Value in the Class 100 (service or option
not implemented Cause Value No. 65-79)
250 (79 is class default),the O-IWU shall send SIP response as 500 Server Internal
Error.
On receipt of REL message with Cause Value No. 87 ("user not member of
251 CUG"),the O-IWU shall send SIP response as 500 Server Internal Error (SIP-I
only).
On receipt of REL message with Cause Value No. 88 ("incompatible
252
destination"),the O-IWU shall send SIP response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 90 ("Non-existent CUG"),the
253 O-IWU shall send SIP response as 500 Server Internal Error (SIP-I only)

On receipt of REL message with Cause Value No. 91 ("invalid transit network
254
selection"),the O-IWU shall send SIP response as 404 Not Found.
On receipt of REL message with Cause Value No. 95 ("invalid message,
255 unspecified")(Class default),the O-IWU shall send SIP response as 500 Server
Internal Error.
On receipt of REL message with Cause Value No. 97 ("Message type non-
256 existent or not implemented"),the O-IWU shall send SIP response as 500 Server
Internal Error.
On receipt of REL message with Cause Value No. 99 ("information
257 element/parameter non-existent or not implemented"),the O-IWU shall send SIP
response as 500 Server Internal Error.
On receipt of REL message with Cause Value No. 102 ("recovery on timer
258
expiry"),the O-IWU shall send SIP response as 480 Temporarily unavailable.
On receipt of REL message with Cause Value No. 103 ("Parameter non-existent
259 or not implemented, passed on"),the O-IWU shall send SIP response as 500
Server Internal Error.
On receipt of REL message with Cause Value No. 110 ("Message with
260 unrecognized parameter, discarded"),the O-IWU shall send SIP response as 500
Server Internal Error.
On receipt of REL message with Cause Value No. 111 ("protocol error,
261 unspecified")(Class default),the O-IWU shall send SIP response as 500 Server
Internal Error.
On receipt of REL message with Cause Value No. 127 ("interworking,
262 unspecified")(Class default),the O-IWU shall send SIP response as 480
Temporarily unavailable.
Send an IAM with Presentation allowed in CGPN. Verify that CGPN adress is
263
mapped to FROM in INVITE
Send an IAM with Presentation restricted in CGPN. Verify that CGPN adress is
264 mapped to P_ASSERTED ID with PRIVACY header as id or header in INVITE

send an ANM with connected number and verify that 200 ok with P-asserted
265
identity is generated for the connected line.
Send an IDS and IDR followed by an IAM. Verify that messages are
266
encapsulated in 183 Session progress.
267 FFS
Send an IAM with Redirect number address parameter and verify that INVITE
268
with DIVERSION header is generated.
If 181, 180 and 200 OK has diversion header, verify the same is mapped on to the
269
Redirect paramater.
B subsciber is enabled for CD. Attempt call with B subscriber. Verify that 180
270 RINGING has DIVERSION header. Verify that same is mapped to REDIRECT
NUMBER parameter in CPG/ACM.
Send CPG with event indicator as remote hold after call is answered. Verify that
271 same is mapped to Re-INVITE with attribute a=sendonly (if media is bothways)
or a=inactive (if media is recvonly)
Send CPG with event indicator as remote retrieval after call is answered. Verify
272 that same is mapped to Re-INVITE with attribute a=sendrecv (if media is
sendrecv) or a=recvonly (if media is inactive)
Send CPG with event indicator as remote hold after call is answered. Verify that
same is mapped to Re-INVITE with attribute a=sendonly (if media is bothways)
273 or a=inactive (if media is recvonly) and encapsulated CPG in message body

Send CPG with event indicator as remote retrieval after call is answered. Verify
that same is mapped to Re-INVITE with attribute a=sendrecv (if media is
274 sendrecv) or a=recvonly (if media is inactive) and encapsulated CPG in message
body
Send an IAM with overlock code and CUG indication. Verify that same is
275
encapsulated in the INVITE message.
Send a FACILITY message and verify that the same is mapped to INFo method.
276

Basic setup flow. Send ISUP messages (IAM, ACM and REL) in the call flow
277 with UUI. Verify that same is encapsulated in relevant INV, 18x and BYE
requests.
Esatblish calls A-B and A-C. Send CPG with conf establish. Verify that same is
278
encapsulated into INFO method.
nd "Request URI",Calling
tional calling party number")
pplication/SDP) and ISUP

TRACEABILITY

5.3

5.3.1
5.3.3

5.3.2

5.4
5.4.2.1
5.3.2
5.4
5.4.1.2

5.3.2

5.4.1.2
5.4.2.1.1

5.4.2.1.2
5.4.2.1.3
5.4.3.1

5.4.3.1

5.4.3.2

5.4.3.1

5.4.3.1
5.4.3.1

5.4.3.1

5.4.3.2

5.4.3.2
5.4.3.2

5.4.3.2

5.4.3.3

5.4.3.3
5.4.3.4

6.1.1

6.1.2
6.1.2

6.1.3.1

6.1.3.2

6.1.3.3

6.1.3.3
6.1.3.4

6.1.3.4

6.1.3.5

6.1.3.5.1

6.1.3.5.1
6.1.3.5.1

6.1.3.5.1

6.1.3.5

6.1.3.5
6.1.3.6.1

6.1.3.6.1
6.1.3.6.1

6.1.3.6.1

6.1.3.6.1
6.1.3.6.1

6.1.3.6.1

6.1.3.6.1
6.1.3.6.1

6.1.3.6.2

6.1.3.9

6.3
6.4

6.5

6.6

6.7

6.11.1

6.11.1
6.11.3

6.11.3

6.11.4

6.11.4
6.11.4

6.11.4

6.11.4
7

7.1

7.1.1

7.1.1
7.1.1

7.1.1.1

7.1.2
7.1.3

7.1.3

7.1.4

7.1.5.1
7.1.5.2

7.2

7.2.1

7.2.1
7.3

7.3.1

7.3.1.1,7.3.1.2

7.3.2

7.4
7.4

7.5,7.5.1

7.5

7.7.1

7.7.2

7.7.3

7.7.4

7.7.6

7.7.6
7.7.6

7.7.6

7.7.6.1

7.7.6

7.7.6
7.7.6

7.7.6

6.11

6.11.1

6.11.1
6.11.1

6.11.1

6.11.1
6.11.1

6.11.1

6.11.1
6.11.1

B.1

B.2

B.4
B.5
B.6

B.7

B.10

B.16

B.20

B.21
B.22

Building Low Latency Applications With C++ Develop A Complete Low Latency Trading Ecosystem From Scratch Using Modern C++ (-) (Z-Library) - Repaired
No ratings yet
Building Low Latency Applications With C++ Develop A Complete Low Latency Trading Ecosystem From Scratch Using Modern C++ (-) (Z-Library) - Repaired
454 pages
IT601-P Mcqs FinalTerm by Vu Topper RM
No ratings yet
IT601-P Mcqs FinalTerm by Vu Topper RM
27 pages
SOAMANAGER in SAP
No ratings yet
SOAMANAGER in SAP
3 pages
Connecting Audiocodes SBC To Microsoft Teams Direct Routing Hosting Model Configuration Note
No ratings yet
Connecting Audiocodes SBC To Microsoft Teams Direct Routing Hosting Model Configuration Note
56 pages
CCD II Basic Alcatel Contact Center - CCD Basic
0% (1)
CCD II Basic Alcatel Contact Center - CCD Basic
350 pages
EFOS3.10 - CLI Command Reference
No ratings yet
EFOS3.10 - CLI Command Reference
1,329 pages
Standard Huawei
No ratings yet
Standard Huawei
4 pages
Telnet - 2018 09 16 16 51 54 - Ugw03
No ratings yet
Telnet - 2018 09 16 16 51 54 - Ugw03
686 pages
Alcatel-Lucent OmniPCX Enterprise (OXE) R12 - SIP
No ratings yet
Alcatel-Lucent OmniPCX Enterprise (OXE) R12 - SIP
30 pages
Installation Admin Guide Ip Desktop SP
No ratings yet
Installation Admin Guide Ip Desktop SP
96 pages
Understanding Layer 2, 3, and 4 Protocols: The OSI Seven Layer Model-What A Layer?
No ratings yet
Understanding Layer 2, 3, and 4 Protocols: The OSI Seven Layer Model-What A Layer?
24 pages
DHCP Relay Agent Configuration On Huawei Cli
No ratings yet
DHCP Relay Agent Configuration On Huawei Cli
4 pages
How to Install Freeradius and Daloradius on Ubuntu 22 04
No ratings yet
How to Install Freeradius and Daloradius on Ubuntu 22 04
12 pages
DHCP, FTP, Telnet
No ratings yet
DHCP, FTP, Telnet
2 pages
Pnemococcal Vaccine in RI
No ratings yet
Pnemococcal Vaccine in RI
2 pages
29163-A21 Standard
No ratings yet
29163-A21 Standard
312 pages
A10 5.2.1-P3 Cli-Slb
No ratings yet
A10 5.2.1-P3 Cli-Slb
823 pages
Smartermail Features PROvsEnterprise
No ratings yet
Smartermail Features PROvsEnterprise
5 pages
ARP Lab-Skill3 Caso de Aplicacion 20171020
No ratings yet
ARP Lab-Skill3 Caso de Aplicacion 20171020
1 page
Install DNS Di LINUX FEDORA
No ratings yet
Install DNS Di LINUX FEDORA
15 pages
Cable Network Packet Notes
No ratings yet
Cable Network Packet Notes
160 pages
LAN Switching and Bridges: Relates To Lab 6
No ratings yet
LAN Switching and Bridges: Relates To Lab 6
39 pages
5.2 Linux Server
No ratings yet
5.2 Linux Server
10 pages
DNS Server Configuration For Oracle-RAC
No ratings yet
DNS Server Configuration For Oracle-RAC
32 pages
Form 1. LAC Profile
No ratings yet
Form 1. LAC Profile
2 pages
ASA
No ratings yet
ASA
115 pages
Aluminosilicate - Wikipedia, The Free Encyclopedia
No ratings yet
Aluminosilicate - Wikipedia, The Free Encyclopedia
80 pages
Alcatel-Lucent Omnipcx Enterprise: Attendant On Ip Touch
No ratings yet
Alcatel-Lucent Omnipcx Enterprise: Attendant On Ip Touch
4 pages
Difference Between FTP and SFTP
No ratings yet
Difference Between FTP and SFTP
4 pages
DigiCert SSLTools API Reference v1.0
No ratings yet
DigiCert SSLTools API Reference v1.0
22 pages
Creating A Self-Signed Certificate With OpenSSL
No ratings yet
Creating A Self-Signed Certificate With OpenSSL
5 pages
Lesson 7 Ports
No ratings yet
Lesson 7 Ports
12 pages
IWR 0174 Ed12 - Jabra Headsets Amplifiers - OmniPCXplatforms - Softphones
No ratings yet
IWR 0174 Ed12 - Jabra Headsets Amplifiers - OmniPCXplatforms - Softphones
83 pages
Lab 4 CCN
No ratings yet
Lab 4 CCN
7 pages
Torrent Trackers
No ratings yet
Torrent Trackers
13 pages
Cambridge International General Certificate of Secondary Education
No ratings yet
Cambridge International General Certificate of Secondary Education
12 pages
7.2.10 Packet Tracer - Configure DHCPv4
No ratings yet
7.2.10 Packet Tracer - Configure DHCPv4
3 pages
SIP For Multimedia PDF
No ratings yet
SIP For Multimedia PDF
80 pages
Mitel MiVoice 6900_6900w IP Phone Admin Guide_GA_R_2.0.0SP1
No ratings yet
Mitel MiVoice 6900_6900w IP Phone Admin Guide_GA_R_2.0.0SP1
96 pages
Crypto Trade Size Calculator v2
No ratings yet
Crypto Trade Size Calculator v2
115 pages
Administ
No ratings yet
Administ
13 pages
Alcatel IPTouchSIPphonesinstallation
No ratings yet
Alcatel IPTouchSIPphonesinstallation
17 pages
Troubleshooting Guide Alcatel Omnitouch Contact Center: No. Tg0016 Ed. 04
No ratings yet
Troubleshooting Guide Alcatel Omnitouch Contact Center: No. Tg0016 Ed. 04
78 pages
Planning Your First Exchange Server
No ratings yet
Planning Your First Exchange Server
8 pages
KD 02 IP Telephony Security Design Guide Ed03
No ratings yet
KD 02 IP Telephony Security Design Guide Ed03
108 pages
BTS API Docementation
No ratings yet
BTS API Docementation
14 pages
SIP Features in Alcatel Enterprise CS OXE
No ratings yet
SIP Features in Alcatel Enterprise CS OXE
21 pages
TC2954en-Ed02 Quick Steps Deployment Guide For ALE SoftPhone With OmniVista 8770 Ldap Server
No ratings yet
TC2954en-Ed02 Quick Steps Deployment Guide For ALE SoftPhone With OmniVista 8770 Ldap Server
16 pages
TG0069en-Ed13 SIP Maintenance R10.x and R11 2 de 2
No ratings yet
TG0069en-Ed13 SIP Maintenance R10.x and R11 2 de 2
78 pages
Alcatel-Lucent Omnipcx Enterprise: Ip Touch Security: NGP Configuration
No ratings yet
Alcatel-Lucent Omnipcx Enterprise: Ip Touch Security: NGP Configuration
5 pages
Ip Over Fax
No ratings yet
Ip Over Fax
85 pages
Mivoice Mx-One: Overview Guide
No ratings yet
Mivoice Mx-One: Overview Guide
58 pages
Alcatel Omnipcx Enterprise: 1 The Communication Architecture
No ratings yet
Alcatel Omnipcx Enterprise: 1 The Communication Architecture
6 pages
SIP Messages
No ratings yet
SIP Messages
7 pages
New OXE Features Introduced in OXE R12.4/M5.204.2.b/M5.204.7.c
100% (1)
New OXE Features Introduced in OXE R12.4/M5.204.2.b/M5.204.7.c
51 pages
Oxe Um 8068 38 39 28 29 8al90896enab 1 en
No ratings yet
Oxe Um 8068 38 39 28 29 8al90896enab 1 en
57 pages
Entity
100% (1)
Entity
3 pages
Voice Over IP Overview
No ratings yet
Voice Over IP Overview
24 pages
Omnipcx Enterprise Brochure en
No ratings yet
Omnipcx Enterprise Brochure en
12 pages
ECS42 Installation & Configuration Manual en
No ratings yet
ECS42 Installation & Configuration Manual en
160 pages
Upgrade R10.1 To R10.2 - Issue 03 OF00CTE106 - Nodrm
No ratings yet
Upgrade R10.1 To R10.2 - Issue 03 OF00CTE106 - Nodrm
90 pages
TC0942 Oxe r8
No ratings yet
TC0942 Oxe r8
16 pages
Inspecting Kerberos Ticket Requests v1
No ratings yet
Inspecting Kerberos Ticket Requests v1
26 pages
RAINBOW
No ratings yet
RAINBOW
20 pages
Sales & Technical: Certification
No ratings yet
Sales & Technical: Certification
18 pages
Design and Implementation Guide For Avaya Aura™ Communication Manager Branch
No ratings yet
Design and Implementation Guide For Avaya Aura™ Communication Manager Branch
74 pages
8088 With OXE Only For Video
No ratings yet
8088 With OXE Only For Video
8 pages
Omnipcx Enterprise Purple - Presales
No ratings yet
Omnipcx Enterprise Purple - Presales
149 pages
Alcatel-Lucent Omnipcx Enterprise: Attendant On Ip Touch
No ratings yet
Alcatel-Lucent Omnipcx Enterprise: Attendant On Ip Touch
10 pages
TC2262en Ed01 PDF
No ratings yet
TC2262en Ed01 PDF
18 pages
IPTouchSIPphonesinstallation Ed03
No ratings yet
IPTouchSIPphonesinstallation Ed03
31 pages
15 Phase in Opentouchsuite MLE EF C134 en
No ratings yet
15 Phase in Opentouchsuite MLE EF C134 en
10 pages
Alu mx52 PDF
No ratings yet
Alu mx52 PDF
24 pages
SIP: Protocol Overview
No ratings yet
SIP: Protocol Overview
16 pages
4 Mi Voice MXONEIntegration Guide
No ratings yet
4 Mi Voice MXONEIntegration Guide
157 pages
Ip Touch 4008
No ratings yet
Ip Touch 4008
29 pages
Univerge: Communication Solution
No ratings yet
Univerge: Communication Solution
16 pages
Follow-Up OXO 100 047.001 Maintenance Version
No ratings yet
Follow-Up OXO 100 047.001 Maintenance Version
5 pages
Mitel 5224 IP Phone PDF
No ratings yet
Mitel 5224 IP Phone PDF
4 pages
SIP Server 7.6 / HA Configuration White Paper: April 9, 2010
No ratings yet
SIP Server 7.6 / HA Configuration White Paper: April 9, 2010
49 pages
Mitel 3300cxi 3300cx en
No ratings yet
Mitel 3300cxi 3300cx en
4 pages
NEC SL1000 Programming Manual (Simplify)
No ratings yet
NEC SL1000 Programming Manual (Simplify)
4 pages
TG0069 Ed12
No ratings yet
TG0069 Ed12
155 pages
Avaya - ASBCE Presentation, FINAL
No ratings yet
Avaya - ASBCE Presentation, FINAL
23 pages
Alcatel-Lucent Omnipcx Enterprise: R9.1 Sip Newness
No ratings yet
Alcatel-Lucent Omnipcx Enterprise: R9.1 Sip Newness
42 pages
Configuring NOE VoIP
No ratings yet
Configuring NOE VoIP
32 pages
Abc F
No ratings yet
Abc F
15 pages
Avaya
No ratings yet
Avaya
67 pages
5 - VoIP Debug Commands
No ratings yet
5 - VoIP Debug Commands
14 pages
VOIP SIP Pardeep
No ratings yet
VOIP SIP Pardeep
85 pages
Avaya SRST SIP Gateway Solution
No ratings yet
Avaya SRST SIP Gateway Solution
72 pages
Alcatel-Lucent Omnipcx Enterprise: Lldp-Med
No ratings yet
Alcatel-Lucent Omnipcx Enterprise: Lldp-Med
7 pages
Oxe Um 8088 Smart DeskPhone
No ratings yet
Oxe Um 8088 Smart DeskPhone
55 pages
Building Telephony Systems with OpenSIPS - Second Edition
From Everand
Building Telephony Systems with OpenSIPS - Second Edition
Goncalves Flavio E.
No ratings yet
Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification and Beyond: Exam CV0-001
From Everand
Deploying and Managing a Cloud Infrastructure: Real-World Skills for the CompTIA Cloud+ Certification and Beyond: Exam CV0-001
Abdul Salam
No ratings yet
Building Telephony Systems with OpenSER
From Everand
Building Telephony Systems with OpenSER
Goncalves Flavio E.
No ratings yet