SIP Extensions Test Suite V.17.06
TEST SUITE OVERVIEW
ReferencesETSI TS 102 027-2 v3.1.1 (2004-11)) / IETF SIP RFC3261
Archive/Projectvoip/sip_ext_ts
Version19171216
Date18 Mar 2008
Number of Scenarios1301
Number of Groups68
Average per Group19
GROUP/SCENARIOTEST PURPOSE
SIP_Extensions
SIP_Extensions/
SIP_UA_PRACK
SIP_Extensions/
SIP_UA_PRACK/
SIP_UA_3262_HV
SIP_UA_3262_HV_001Ensure that the IUT, when it binds RSeq header in a reliable provisional response it SHOULD have value from 1 to 2**32-1
SIP_UA_3262_HV_002Ensure that the IUT, SHOULD only put Rack in PRACK method but NOT others
SIP_UA_3262_HV_003Ensure that the IUT, SHOULD only put RSeq into 1XX reliable provisional respond and optional in INVITE but NOT other methods
SIP_UA_3262_HV_004Ensure that the IUT, when it bind Rack header in PRACK, it MUST contain two numbers,
SIP_UA_3262_HV_005Ensure that the IUT, when it bind Rack header in PRACK, it MUST contain a method tag with value INVITE
SIP_UA_3262_HV_006Ensure that the IUT, when it respond 405 to PRACK method, it MUST have Allow header field in 405
SIP_UA_3262_HV_007Ensure that the IUT, when it responds PRACK, it MUST copy Call-ID header field into the PRACK method
SIP_UA_3262_HV_008Ensure that the IUT, when it responds PRACK, it MUST copy CSeq header field into the PRACK method
SIP_UA_3262_HV_009Ensure that the IUT, when it responds PRACK, it MUST copy From header field into the PRACK method
SIP_UA_3262_HV_010Ensure that the IUT, when it responds PRACK, it MUST have Max-Forwards header field in the PRACK method
SIP_UA_3262_HV_011Ensure that the IUT, when it responds 407 to PRACK, it MUST have Proxy-Authenticate header field in 407
SIP_UA_3262_HV_012Ensure that the IUT, when it responds PRACK, it MUST copy To header field into the PRACK method
SIP_UA_3262_HV_013Ensure that the IUT, when it responds PRACK, it MUST copy Via header field into the PRACK method
SIP_UA_3262_HV_014Ensure that the IUT, when it responds 420 to PRACK, it MUST have Unsupported header field in 420
SIP_UA_3262_HV_015Ensure that the IUT, when it responds 401 to PRACK, it MUST have WWW-Authenticate header field in 401
SIP_Extensions/
SIP_UA_PRACK/
SIP_UA_3262_V
SIP_UA_3262_V_001Ensure that the IUT responds to INVITE reliably using a non-100 provisional respond MUST contain with
SIP_UA_3262_V_002Ensure that the IUT SHOULD NOT respond reliably for any other methods but INVITE
SIP_UA_3262_V_003Ensure that the IUT, when it receives INVITE with Require header field with option tag 100rel, it MUST send
SIP_UA_3262_V_004Ensure that the IUT, when it receives INVITE with Require header field with option tag 100rel, it MUST reject
SIP_UA_3262_V_005Ensure that the IUT, when it receives INVITE without either Supported or Require header in INVITE,
SIP_UA_3262_V_006Ensure that the IUT, it MUST NOT send 100 Trying respond reliably
SIP_UA_3262_V_007Ensure that the IUT, when it sends non-100 provisional respond reliably, the respond MUST contain a Require header field with 100rel and MUST include an RSeq header field
SIP_UA_3262_V_008Ensure that the IUT, when it sends non-100 provisional respond reliably, the RSeq header field MUST have value between 1 to 2**31-1
SIP_UA_3262_V_009Ensure that the IUT, when it receives different non-100 provisional respond reliably for different Request with the RSeq header field with same value, it should proceed like different transaction
SIP_UA_3262_V_009_aEnsure that the IUT, when it receives different non-100 provisional respond reliably for different Request with the RSeq header field with same value, it should proceed like different transaction
SIP_UA_3262_V_010Ensure that the IUT, when it receives PRACK method, it will check the CSeq, From, To, Call-ID headers to match the provisional respond. If not matched, it should returns 481
SIP_UA_3262_V_011Ensure that the IUT, when it receives PRACK method, it will also check the RAck headers to match the provisional respond. If not matched, it should returns 481
SIP_UA_3262_V_011_aEnsure that the IUT, when it receives PRACK method, it will also check the RAck headers to match the provisional respond. If not matched, it should returns 481
SIP_UA_3262_V_012Ensure that the IUT, when it receives a non-100 provisional respond reliably, it SHOULD respond a PRACK
SIP_UA_3262_V_013Ensure that the IUT, when it sends a reliable non-100 provisional respond SHOULD start timer at T1 seconds and doubles for each retransmission until receive matched PRACK
SIP_UA_3262_V_014Ensure that the IUT, when it sends a reliable non-100 provisional respond SHOULD start timer at T1 seconds and doubles for each retransmission until 100rel retry counts is reached or hit 64*T1 seconds when no PRACK is returned, and it should reject the original request with a 5XX response
SIP_UA_3262_V_015Ensure that the IUT, after it receives PRACK, it SHOULD consider the PRACK matches if CSeq-num, and respond-num in the Rack header field of PRACK matches the CSeq, the sequence number from the CSeq and sequence number from the RSeq of the reliable provisional response
SIP_UA_3262_V_016Ensure that the IUT, when it receives a PRACK request that does not match any unacknowledged reliable provisional response (e.g. RAck is not matched), it MUST respond with a 481
SIP_UA_3262_V_017Ensure that the IUT, when it receives a PRACK request that does match an unacknowledged reliable provisional response, it MUST respond with a 2XX response
SIP_UA_3262_V_018Ensure that the IUT, may resend reliable provisional response, but MUST NOT resend it before the first one is acknowledged by PRACK
SIP_UA_3262_V_019Ensure that the IUT, when it sends subsequent reliable provisional response, the RSeq header field for the same request MUST be greater by exactly one
SIP_UA_3262_V_020Ensure that the IUT, when it receives subsequent reliable provisional response, the RSeq header field for the same request is not greater by exactly one, 4XX should be returned
SIP_UA_3262_V_021Ensure that the IUT, when it receives subsequent reliable provisional response, the RSeq header field for the same request is correct, it should PRACK it again
SIP_UA_3262_V_022Ensure that the IUT, when it sends final responds 2XX before it gets PRACK, it should stop retransmitting the unacknowledged reliable provisional respond
SIP_UA_3262_V_023Ensure that the IUT, when it wants to insist on reliable delivery of provisional response, it should inserts a Require header with option tag 100rel in the INVITE request
SIP_UA_3262_V_024Ensure that the IUT, MUST NOT bind Require header with value 100rel in any other request but INVITE
SIP_UA_3262_V_025Ensure that the IUT, when it tells UAS it does support reliable provisional response but not insist on using it, it MUST put Supported header field with value 100rel in all the INVITE requests
SIP_UA_3262_V_026Ensure that the IUT, when it receives a provisional response for initial request that contains a Require header with 100rel, it should consider the response is to be sent reliably
SIP_UA_3262_V_027Ensure that the IUT, when it receives 100 Trying with a Require header with 100rel, it SHOULD NOT consider this is reliably provisional respond
SIP_UA_3262_V_027_aEnsure that the IUT, when it receives 100 Trying with a Require header with 100rel, it SHOULD NOT consider this is reliably provisional respond
SIP_UA_3262_V_028Ensure that the IUT, when it receives retransmitted reliable provisional response after it sends PRACK, it SHOULD NOT retransmit PRACK and retransmissions of reliable provisional response MUST be discarded
SIP_UA_3262_V_029Ensure that the IUT, when it receives an INVITE contains no offer, it MUST has an offer in reliable message send back
SIP_UA_3262_V_030Ensure that the IUT, when it receives an INVITE contains an offer, it MAY generate an answer in a reliable provisional response, the early media should be established before the completion of the call (reception of 2xx)
SIP_UA_3262_V_031Ensure that the IUT, when it sends INVITE without an offer and receives a reliable provisional response with an offer, it MUST generate an answer in the PRACK
SIP_UA_3262_V_032Ensure that the IUT, when it sends INVITE contains an offer, it MAY generate additional offer in the PRACK if receives an answer in a reliable provisional response
SIP_UA_3262_V_033Ensure that the IUT, when it receives INVITE without an offer and receives PRACK with an offer, it MUST generate an answer in the 2XX to the PRACK
SIP_UA_3262_V_034Ensure that the IUT, when it sends a reliable provisional response with a session description and is unacknowledged when the INVITE is accepted, it MUST delay sending the 2XX until the PRACK acks the provisional response
SIP_Extensions/
SIP_UA_PRACK/
SIP_UA_3262_I
SIP_UA_3262_I_001Ensure that the IUT, when it receives a reliable provisional responds with RSeq with value 0, it should returns 4XX respond
SIP_UA_3262_I_001_aEnsure that the IUT, when it receives a reliable provisional responds with RSeq with value 0, it should returns 4XX respond
SIP_UA_3262_I_001_bEnsure that the IUT, when it receives a reliable provisional responds with RSeq with value 0, it should returns 4XX respond
SIP_UA_3262_I_001_NoRespEnsure that the IUT, when it receives a reliable provisional responds with RSeq with value 0, it should ignore it
SIP_UA_3262_I_002Ensure that the IUT, when it receives a method that is not reliable provisional respond (e.g. 2XX) with RSeq header field, it should be ignored
SIP_UA_3262_I_003Ensure that the IUT, when it receives PRACK with RAck header field with only one number and the method, it should returns 4XX respond
SIP_UA_3262_I_004Ensure that the IUT, when it bind Rack header in PRACK, it MUST contain two numbers, with first number mismatched, it should returns 481
SIP_UA_3262_I_005Ensure that the IUT, when it bind Rack header in PRACK, it MUST contain two numbers, with second number mismatched, it should returns 481
SIP_UA_3262_I_006Ensure that the IUT, when it bind Rack header in PRACK, it MUST contain two numbers, and method name “invite" (in lower case), it should returns 481
SIP_UA_3262_I_007Ensure that the IUT, when it receives non-100 provisional respond reliably, the RSeq header field value of 0, it should return 4XX
SIP_UA_3262_I_007_NoRespEnsure that the IUT, when it receives a reliable provisional responds with RSeq with value 0, it should ignore it and then recover with a good response
SIP_Extensions/
SIP_Session_Timer
SIP_Extensions/
SIP_Session_Timer/
SIP_UA_timer_HV
SIP_UA_timer_HV_001Ensure that the IUT, ONLY binds Session-Expires header into INVITE or UPDATE request,
SIP_UA_timer_HV_002Ensure that the IUT, the minimum value set into Min-SE header field is 90s
SIP_UA_timer_HV_003Ensure that the IUT, MAY send INVITE with Min-SE header in initial INVITE
SIP_UA_timer_HV_004Ensure that the IUT, the recommend value set into Session-Expires header is 1800 seconds
SIP_UA_timer_HV_005Ensure that the IUT, when it MUST NOT set Session-Expires header value less than value in Min-SE header
SIP_UA_timer_HV_006Ensure that the IUT, when it constructs Session-Expires header, it MUST have a value and optionally with refresher parameter of value uas or uac
SIP_UA_timer_HV_007Ensure that the IUT, when it constructs 422 respond to INVITE or UPDATE because Session-Expires too small, it MUST have Min-SE header field in 422 respond
SIP_UA_timer_HV_008Ensure that the IUT, when it constructs 422 respond to INVITE or UPDATE because Session-Expires too small, it MUST use context Session Interval Too Small
SIP_UA_timer_HV_009Ensure that the IUT, when it MUST NOT bind Min-SE in other respond rather than 422
SIP_UA_timer_HV_010Ensure that the IUT, when it SHOULD have Support header field with value timer in the INVITE when it
SIP_UA_timer_HV_011Ensure that the IUT, when it responds 407 to PRACK, it MUST have Proxy-Authenticate header field in 407
SIP_UA_timer_HV_012Ensure that the IUT, when it responds PRACK, it MUST copy To header field into the PRACK method
SIP_UA_timer_HV_013Ensure that the IUT, when it responds PRACK, it MUST copy Via header field into the PRACK method
SIP_UA_timer_HV_014Ensure that the IUT, when it responds 420 to PARCK, it MUST have Unsupported header field in 420
SIP_UA_timer_HV_015Ensure that the IUT, when it responds 401 to PARCK, it MUST have WWW-Authenticate header field in 401
SIP_Extensions/
SIP_Session_Timer/
SIP_UA_timer_V
SIP_UA_timer_V_001Ensure that the IUT, when it sends INVITE request, it SHOULD include a Supported header field with option tag timer to indicate it support the session timer
SIP_UA_timer_V_002Ensure that the IUT SHOULD use Min-SE header field to establish the lower bound for the session refresh interval
SIP_UA_timer_V_003Ensure that the IUT, when it receives 422 response for the request due to the Session-Expires interval is too low, the respond contains a Min-SE header field to identify the minimum session interval is too short, it SHOULD try again including Min-SE header with the largest Min-SE header field it observed in all 422 response it received previously
SIP_UA_timer_V_004Ensure that the IUT, before the session expiration (which states in Session-Expires header field), if it is active refresher, it MUST generate a session refresh request, which is a re-INVITE or UPDATE request for the current dialog
SIP_UA_timer_V_005Ensure that the IUT, before the session expiration (which states in Session-Expires header field), if it is active refresher, it SHOULD send a BYE to terminate the session after time out for the respond of a re-INIVTE or UPDATE request
SIP_UA_timer_V_006Ensure that the IUT, when it receives a refresh request, it SHOULD treat it same as the initial request but only will extend the session
SIP_UA_timer_V_007Ensure that the IUT, when it supports session timer, it MUST include a Supported header field in each request (except ACK) with option tag timer
SIP_UA_timer_V_008Ensure that the IUT, when it supports session timer, it MAY include a Min-SE header field in initial INVITE
SIP_UA_timer_V_009Ensure that the IUT, when it MAY include Session-Expires header field and a Min-SE header field in the initial INVITE, but the value of Session-Expires MUST be greater than or equal to the value of Min-SE
SIP_UA_timer_V_010Ensure that the IUT, when it supports session timer, it receives INVITE with Min-SE header ONLY (No Session-Expires header field) it should treat it valid, i.e the session has minimum value but never time out
SIP_UA_timer_V_011Ensure that the IUT, when it supports session timer, it receives INVITE with Session-Expires header ONLY (No Min-SE header field) it should treat it valid, i.e the session has minimum value of 90 seconds and maximum value states in Session-Expires header field
SIP_UA_timer_V_012Ensure that the IUT, when it receives 2XX Response with Require header field containing value timer, it MUST look for the session-Expires header and set the session timer correctly
SIP_UA_timer_V_013Ensure that the IUT, when it receives 2XX Response with NO Session-Expires header field, it does NOT need to send refresh request
SIP_UA_timer_V_014Ensure that the IUT, when it does need to do session refresh, it MUST compute the session expiration for that session, which is the time of reception of the last 2XX response to a session refresh plus the session interval for that session
SIP_UA_timer_V_015Ensure that the IUT, when it retrys the INVITE request after gets respond 422, it SHOULD create the new re-INVITE with same value of the Call-ID, To, and From of the previous request, but the CSeq SHOULD be one higher than the previous
SIP_UA_timer_V_016Ensure that the IUT, when it retrys the INVITE request after gets respond 422, it SHOULD create the new re-INVITE with same value of the Supported, Require and Proxy-Require (if any) of the previous request
SIP_UA_timer_V_017Ensure that the IUT, when it refreshs a session within a dialog, the Session-Expires header field SHOULD equal to the maximum of the Min-SE header field and the current session interval
SIP_UA_timer_V_018Ensure that the IUT, when it does refresh, it SHOULD construct the re-INVITE or UPDATE request with refresher parameter set to the correct value based on the initial refresher negotiation
SIP_UA_timer_V_019Ensure that the IUT, when it does refresh, it SHOULD use UPDATE request rather than re-INVITE if it is supported
SIP_UA_timer_V_020Ensure that the IUT, when it receives INVITE does NOT have Min-SE header but with Session-Expires header, it SHOULD assume the Min-SE header value is 90 second by default
SIP_UA_timer_V_021Ensure that the IUT, when it receives INVITE does NOT have Min-SE header but with Session-Expires header with value less than 90 seconds, it SHOULD assume the Min-SE header value is 90 second by default and return 422 responds with Min-SE header set to appropriate value
SIP_UA_timer_V_022Ensure that the IUT, when it receives INVITE does have Min-SE header but with Session-Expires header with value less than the value of Min-SE, it SHOULD assume the Min-SE header value is 90 second by default and return 422 responds with Min-SE header set to appropriate value
SIP_UA_timer_V_023Ensure that the IUT, when it responds 2XX respond to the INVITE, it MAY reduce Session-Expires value but NOT less than the Min-SE value, and it MUST NOT increase the value of the Session-Expires header field
SIP_UA_timer_V_024Ensure that the IUT, when it does support session timer and wants to insist it is refresher when it sends INVITE request, it SHOULD put refresher parameter with value uac
SIP_UA_timer_V_025Ensure that the IUT, when it does support session timer and wants to insist it UAS refresher when it sends INVITE request, it SHOULD put refresher parameter with value uas
SIP_UA_timer_V_026Ensure that the IUT, when it does support session timer, it sends INVITE without refresher parameter and receives 2XX responds with refresher parameter set to uac, it SHOULD perform the refresh request
SIP_UA_timer_V_027Ensure that the IUT, when it does support session timer, it sends INVITE without refresher parameter and receives 2XX responds with refresher parameter set to uas, it SHOULD wait for the refresh request
SIP_UA_timer_V_028Ensure that the IUT, when it does support session timer, it receives INVITE without refresher parameter, if it insists to be refresher, it SHOULD send 2XX responds with refresher parameter set to uas and with Require header field with value timer
SIP_UA_timer_V_029Ensure that the IUT, when it does support session timer, it receives INVITE without refresher parameter, if it insists that UAC to be refresher, it SHOULD send 2XX responds with refresher parameter set to uac and with Require header field with value timer
SIP_Extensions/
SIP_Session_Timer/
SIP_UA_timer_I
SIP_UA_timer_I_001Ensure that the IUT, when it receives INVITE with Session-Expires header field with value of 80 and no Min-SE header, it should return 422
SIP_UA_timer_I_002Ensure that the IUT, when it receives INVITE with Session-Expires header field with value of 100 and Min-SE header field value of 120, it should return 422
SIP_UA_timer_I_003Ensure that the IUT, when it receives INVITE with Session-Expires header field but no Supported header field with option tag timer, it should return 400
SIP_UA_timer_I_004Ensure that the IUT, when it receives INVITE with Min-SE header field but no Supported header field with option tag timer, it should return 400
SIP_UA_timer_I_005Ensure that the IUT, when it is active refresher for the session, and it receives refresh request, it MAY reject it using 400
SIP_UA_timer_I_006Ensure that the IUT, when it receives 2XX Response with Require header field containing value timer but no Session-Expires header field, it should return 400
SIP_UA_timer_I_007Ensure that the IUT, when it gets the re-INVITE request after gets respond 422, with same value of the Call-ID, To, and From of the previous request, as well as CSeq, it HOULD return 4XX (481 or 400)
SIP_Extensions/
Remote_Party_ID_Privacy_Test
SIP_Extensions/
Remote_Party_ID_Privacy_Test/
SIP_UA_RPID_HV
SIP_UA_RPID_HV_001Ensure that the IUT, when it constructs Remote-Party-ID header, it MUST add
SIP_UA_RPID_HV_002Ensure that the IUT, when it constructs Remote-Party-ID header, it MAY optionally add screen token with value either yes or no into the header
SIP_UA_RPID_HV_003Ensure that the IUT, when it constructs Remote-Party-ID header, it MAY optionally add party token with value either
SIP_UA_RPID_HV_004Ensure that the IUT, when it constructs Remote-Party-ID header, it MAY optionally add id-type token
SIP_UA_RPID_HV_005Ensure that the IUT, when it constructs Remote-Party-ID header, it MAY optionally add privacy token with value full, name, uri, or quoted string
SIP_Extensions/
Remote_Party_ID_Privacy_Test/
SIP_UA_RPID_V
SIP_UA_RPID_V_001Ensure that the IUT, when it constructs INVITE, and UPDATE, request, it CAN includes a Calling
SIP_UA_RPID_V_002Ensure that the IUT, when it constructs INVITE and UPDATE request with Remote-Party-ID header for the calling subscriber,
SIP_UA_RPID_V_003Ensure that the IUT, when it constructs INVITE and UPDATE request, with Remote-Party-ID header, it CAN put privacy
SIP_UA_RPID_V_004Ensure that the IUT, when it constructs INVITE and UPDATE request, with Remote-Party-ID header, it CAN put privacy token
SIP_UA_RPID_V_005Ensure that the IUT, when it constructs INVITE and UPDATE request, with Remote-Party-ID header, it CAN put privacy
SIP_UA_RPID_V_006Ensure that the IUT, when it constructs INVITE and UPDATE request, with Remote-Party-ID header, it CAN put privacy token
SIP_UA_RPID_V_007Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_008Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_009Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator, if it supports
SIP_UA_RPID_V_010Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator, if it supports
SIP_UA_RPID_V_011Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator, if it supports
SIP_UA_RPID_V_012Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the
SIP_UA_RPID_V_013Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_014Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_015Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_016Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_017Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_018Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_019Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header of the originator,
SIP_UA_RPID_V_020Ensure that the IUT, when it receives final responds (2XX) with Remote-Party-ID header of the connected-to
SIP_UA_RPID_V_021Ensure that the IUT, when it receives final response (2XX) with Remote-Party-ID header of the connected-to party
SIP_UA_RPID_V_022Ensure that the IUT, when it receives final responds (2XX) with Remote-Party-ID header of the connected-to party with
SIP_UA_RPID_V_023Ensure that the IUT, when it receives non-100 provisional respond with Remote-Party-ID header of the called party with the privacy token, if it supports this extension, it SHOULD send the connected-to party identity and “display-name" to the originator user privacy token is set to off
SIP_UA_RPID_V_024Ensure that the IUT, ONLY should bind Remote-Party-ID header in INVITE and UPDATE methods but NOT others
SIP_UA_RPID_V_025Ensure that the IUT, ONLY should bind Remote-Party-ID header in to the responds of INVITE and UPDATE methods but NOT others
SIP_Extensions/
Remote_Party_ID_Privacy_Test/
SIP_UA_RPID_I
SIP_UA_RPID_I_001Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header but without addr-spec, it should return 400
SIP_UA_RPID_I_002Ensure that the IUT, when it receives 200 final responds with Remote-Party-ID header with party token set to “connected", it should accept the respond and proceed correctly
SIP_UA_RPID_I_003Ensure that the IUT, when it receives INVITE and UPDATE Request with Remote-Party-ID header with party token set to connected (without double quote), it SHOULD return 400
SIP_UA_RPID_I_004Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header with id-type token set to “supervisor", it should accept the respond and proceed correctly
SIP_UA_RPID_I_005Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header with id-type token set to supervisor (without double quote), it should return 400
SIP_UA_RPID_I_006Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header with privacy token set to “whatever", it should accept the respond and proceed correctly
SIP_UA_RPID_I_007Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header with privacy token set to whatever, it should return 400
SIP_UA_RPID_I_008Ensure that the IUT, when it receives INVITE and UPDATE request with Remote-Party-ID header with two id-type tokens set to subscriber and user respectively , it should reject the request with 400
SIP_Extensions/
Diversion_Header_Test
SIP_Extensions/
Diversion_Header_Test/
SIP_UA_DIV_HV
SIP_UA_DIV_HV_001Ensure that the IUT, when it constructs Diversion header, it MUST add the
SIP_UA_DIV_HV_002Ensure that the IUT, when it constructs Diversion header, it MUST contain a diversion-reason with a reason value
SIP_UA_DIV_HV_003Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value unknown if the diversion reason is unknown (e.g. call is diverted from analog trunk)
SIP_UA_DIV_HV_004Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value user-busy if the diversion triggered because of user busy
SIP_UA_DIV_HV_005Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value unavailable if the diversion triggered because user is not presented
SIP_UA_DIV_HV_006Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value unconditional if the diversion is configured as call forward all
SIP_UA_DIV_HV_007Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value no-answer if the diversion is triggered by user not answer
SIP_UA_DIV_HV_008Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value time-of-day if the diversion is triggered because of time of the day
SIP_UA_DIV_HV_009Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value deflection if the diversion is triggered because of the deflection
SIP_UA_DIV_HV_010Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value do-not-disturb if the diversion configured as do not disturb
SIP_UA_DIV_HV_011Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value out-of-service if the is triggered because of out of service
SIP_UA_DIV_HV_012Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value away if the diversion is triggered by configured as away
SIP_UA_DIV_HV_013Ensure that the IUT, when it constructs Diversion header, it MUST add diversion-reason parameter with value follow-me if the diversion is triggered by configured as follow-me option
SIP_UA_DIV_HV_014Ensure that the IUT, when it constructs diversion-reason value that is NOT defined in the session 5, it MUST put the string into double quote
SIP_UA_DIV_HV_015Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-counter parameter “counter" with counter value within 2 digits
SIP_UA_DIV_HV_016Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-privacy parameter “privacy" with value full if not allowed to display both Name and Number
SIP_UA_DIV_HV_017Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-privacy parameter “privacy" with value name if not allowed to display Name only
SIP_UA_DIV_HV_018Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-privacy parameter “privacy" with value uri if not allowed to display Number
SIP_UA_DIV_HV_019Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-privacy parameter “privacy" with value off if both Name and Number are allowed to be displayed
SIP_UA_DIV_HV_020Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-privacy parameter “privacy" with value of quoted string if the value is not defined in this draft
SIP_UA_DIV_HV_021Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-screen parameter “screen" with value yes if the number is screened by the network (e.g. in the case of interworking with PSTN network.)
SIP_UA_DIV_HV_022Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-screen parameter “screen" with value no if the number is NOT screened by the network (e.g. in the case of interworking with Q.sig network.)
SIP_UA_DIV_HV_023Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-screen parameter “screen" with value of quoted string if the value is not defined in this draft
SIP_UA_DIV_HV_024Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-screen parameter “limit" with value two digits value to state the forwarding hop limitation
SIP_UA_DIV_HV_025Ensure that the IUT, when it constructs Diversion header, it MAY optionally add diversion-extension as quoted-string if not defined in session 5
SIP_UA_DIV_HV_026Ensure that the IUT, when it constructs Diversion header only in INVITE methods and 3XX respond but NOT other methods and responds
SIP_UA_DIV_HV_027Ensure that the IUT, when it receiving a 3XX message with 6 contact headers, it should use the most top list one and send new request downstream and put the rest in a correct order table and hunt down the list till it success
SIP_UA_DIV_HV_028Ensure that the IUT, when it receiving a 3XX message with 7 contact headers, it should use the most top list one and send new request downstream and put the rest in a correct order table and hunt down the list till it success
SIP_Extensions/
Diversion_Header_Test/
SIP_UA_DIV_V
SIP_UA_DIV_V_001Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “user-busy", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_002Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “unconditional", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_003Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “no-answer", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_004Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “unknown", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_005Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “unavaliable", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_006Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “time-of-day", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_007Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “do-not-disturb", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_008Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with diversion-reason “out-of-service", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_009Ensure that the IUT, when receives respond 302 that has Diversion header with one URIs with diversion-reason “away", the diversion information should correctly reflect to the new request, for example a Q.sig call or a new INVITE
SIP_UA_DIV_V_010Ensure that the IUT, when receives respond 302 that has Diversion header with one URIs with diversion-reason “follow-me", the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_011Ensure that the IUT, when receives respond 302 that has Diversion header with one URIs with diversion-reason “deflection", the diversion information should correctly reflect to the new INVITE request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_012Ensure that the IUT, when receives respond 302 that has Diversion header with one URIs with diversion-reason “whatever", the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_013Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reason “whatever", “away", “user-busy", the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_014Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-privacy with value full, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_015Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-privacy with value name, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_016Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-privacy with value uri, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_017Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-privacy with value off, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_018Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-counter set to 3, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_019Ensure that the IUT, when receives respond 302 that has three Diversion headers with URIs with diversion-reasons, diversion-limit and diversion-extension with values, the diversion information should correctly reflect to the new request, for example a Q.sig call or new INVITE
SIP_UA_DIV_V_020Ensure that the IUT, SHOULD NOT add Diversion header for normal call routing to the Request-URI
SIP_UA_DIV_V_021Ensure that the IUT, when it triggers the diversion, Diversion header field with the previous Request-URI SHOULD be added to the forwarded 3XX respond
SIP_UA_DIV_V_022Ensure that the IUT, when it triggers the diversion, Diversion header field with the previous Request-URI SHOULD be added to the forwarded request (e.g. nested Diversion)
SIP_UA_DIV_V_023Ensure that the IUT, when it triggers the diversion, diversion-reason with reason value SHOULD be added to the forwarded 3XX respond
SIP_UA_DIV_V_024Ensure that the IUT, after it receives a Request with Diversion headers, it MUST NOT be removed or changed in the forwarded response
SIP_UA_DIV_V_025Ensure that the IUT, when it receives a 3XX containing Diversion headers, it SHOULD copy the Diversion header into the downstream request
SIP_UA_DIV_V_027Ensure that the IUT, when it need to trigger the diversion beyond receiving a 3XX containing a Diversion header, and it SHOULD copy the Diversion header into the downstream request and add the most recent Diversion header on the top of the Diversion header list
SIP_UA_DIV_V_028Ensure that the IUT, when it receives INVITE with multiple Diversion headers, it SHOULD treat the most top Diversion header as the last diversion occurred and the most last Diversion header as the first diversion
SIP_RD_DIV_V_001Ensure that the IUT, when it receives a request as redirect server, it SHOULD return a 3XX containing a Contact with the diverts the request to, and Diversion header and diversion reason
SIP_Extensions/
Diversion_Header_Test/
SIP_PS_DIV_V
SIP_PS_DIV_V_001Ensure that the IUT, when it is a non-recursing SIP proxy, it SHOULD forward the 3XX containing the Diversion header upstream unchanged
SIP_PS_DIV_V_002Ensure that the IUT, when it is a recursing SIP proxy, if it receives a request it SHOULD return a 3XX contain a Contact which diverts the request to a different endpoint and add a Diversion header containing the Request-URI from the incoming request and the reason for the diversion
SIP_PS_DIV_V_003Ensure that the IUT, when it is a recursing SIP proxy, if it receives a request it SHOULD forwarded request in order to divert the request to a different endpoint and add a Diversion header containing the Request-URI from the incoming request and the reason for the diversion
SIP_Extensions/
Diversion_Header_Test/
SIP_UA_DIV_I
SIP_UA_DIV_I_001Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason set to whatever (without quote), it should return 400
SIP_UA_DIV_I_002Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-counter set to 100, it should return 400
SIP_UA_DIV_I_003Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-limit set to 100, it should return 400
SIP_UA_DIV_I_004Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-privacy set to whatever (without quote), it should return 400
SIP_UA_DIV_I_005Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-screen set to whatever (without quote), it should return 400
SIP_UA_DIV_I_006Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-extension set to whatever (without quote), it should return 400
SIP_UA_DIV_I_007Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason set to “diversion-reason: whatever" it should proceed correctly
SIP_UA_DIV_I_008Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason set to “NO-ANSWER", it should still proceed correctly
SIP_UA_DIV_I_009Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason without any value, it should return 4XX
SIP_UA_DIV_I_010Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason set to “no%answer", it should return 4XX
SIP_UA_DIV_I_011Ensure that the IUT, when it receives 3XX responds with Diversion header and with diversion-reason set to “no answer", it should still return 4XX
SIP_Extensions/
Redirection_Status_Code_Test
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_3XX_HV
SIP_UA_3XX_HV_001_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason user-busy, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_002_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason unconditional, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_003_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason no-answer, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_004_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason unknown, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_005_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason user-busy, the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_006_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason unconditional, the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_007_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason no-answer, the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_008_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with one URI with reason unknown, the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_009_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “unconditional" and "user-busy", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_009a_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “no-answer" and "unknown", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_010_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “unconditional" and "user-busy", the diversion information should correctly reflect to the new request, for example a Q.sig Call
SIP_UA_3XX_HV_010a_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “no-answer" and "unknown", the diversion information should correctly reflect to the new request, for example a Q.sig Call
SIP_UA_3XX_HV_011_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with three URIs with reason “unconditional", "user-busy", "no-answer", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_012_DF2aEnsure that the IUT, when receives respond 302 that has Diversion header with three URIs with reason “unconditional", "user-busy", "no-answer", the diversion information should correctly reflect to the new request, e.g. a Q.sig Call
SIP_UA_3XX_HV_001Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason user-busy, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_002Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason unconditional, the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_003Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “no-answer", the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_004Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “unknown", the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_005Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “user-busy", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_006Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “unconditional", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_007Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “no-answer", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_008Ensure that the IUT, when receives respond 302 that has Diversion header with one URI with reason “unknown", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_009Ensure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “unconditional", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_010Ensure that the IUT, when receives respond 302 that has Diversion header with two URIs with reason “unknown", the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_UA_3XX_HV_011Ensure that the IUT, when receives respond 302 that has Diversion header with three URIs with reason “unconditional", the diversion information should correctly reflect to the new INVITE request
SIP_UA_3XX_HV_012Ensure that the IUT, when receives respond 302 that has Diversion header with three URIs with reason “unknown", the diversion information should correctly reflect to the new request, for example a Q.sig call
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_RD_3XX_HV
SIP_RD_3XX_HV_001Ensure that the IUT, should treat “expires" parameter of a Contact header field value and Expires header field are same when receives either one in the respond of 302
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_300_V
SIP_UA_300_V_001_DF2aEnsure that the IUT, when receive a redirection respond 300, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_300_V_002_DF2aEnsure that the IUT, when processing 300 responses MUST NOT add any given URI to the target set more than once
SIP_UA_300_V_004_DF2aEnsure that the IUT, when receive a redirection respond 300 with multiple contacts with q value in the Contact header
SIP_UA_300_V_005_DF2aEnsure that the IUT, when receive a redirection respond 300, it should try the next perfer contact address UA prefers, if a failure for a paticular contact address. A new client transaction should be created
SIP_UA_300_V_006_DF2aEnsure that the IUT, when receive a redirection respond 300, it should try the next prefer contact address in the list in afailure, until the list is exhausted
SIP_UA_300_V_007_DF2aEnsure that the IUT, when receive a redirection respond 300, it should consider as a failure for a particular contact address if failure code returns (codes gretater than 399)
SIP_UA_300_V_008_DF2aEnsure that the IUT, when receive a redirection respond 300, in order to create a request based on 300 UAC MUST copy the entire URI from the target set into the Request-URI, except
SIP_UA_300_V_009_DF2aEnsure that the IUT, when receive a redirection respond 300, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_300_V_010_DF2aEnsure that the IUT, when receive a redirection respond 300, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to updated the Call-ID header field value of new requests
SIP_UA_300_V_011_DF2aEnsure that the IUT, when receive a redirection respond 300, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_300_V_012_DF2aEnsure that the IUT, when receive a redirection respond 300, it should re-use the header fields (except method) and bodies of the original request to construct
SIP_UA_300_V_013_DF2aEnsure that the IUT, when receive a redirection respond 300, UAs respond may contain several Contact fields or a list of addresses in a Contact field in the new request
SIP_UA_300_V_001Ensure that the IUT, when receive a redirection respond 300, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_300_V_002Ensure that the IUT, when processing 300 responses MUST NOT add any given URI to the target set more than once
SIP_UA_300_V_003Ensure that the IUT, when processing 300 responses MUST NOT add any given URI to the target set more than once
SIP_UA_300_V_004Ensure that the IUT, when receive 300 with multiple contacts with q value in Contact header, UA can use the prefer contact and redirect its request to that location
SIP_UA_300_V_005Ensure that the IUT, when receive a redirection respond 300, it should try the next prefer contact address UA prefers if a failure for a particular contact address. A new client transaction should be created to deliver a new request
SIP_UA_300_V_006Ensure that the IUT, when receive a redirection respond 300, it should try the next prefer contact address in the list in a failure, until the list is exhausted. If the list is exhausted, then the request has failed
SIP_UA_300_V_007Ensure that the IUT, when receive a redirection respond 300, it should consider as a failure for a particular contact address if failure code returns (codes greater than 399)
SIP_UA_300_V_008Ensure that the IUT, when receive a redirection respond 300, in order to create a request based on 300, UAC MUST copy the entire URI from the target set into the Request-URI, except for the “method-param" and “header" URI parameters
SIP_UA_300_V_009Ensure that the IUT, when receive a redirection respond 300, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_300_V_010Ensure that the IUT, when receive a redirection respond 300, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to updated the Call-ID header field value of new requests
SIP_UA_300_V_011Ensure that the IUT, when receive a redirection respond 300, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_300_V_012Ensure that the IUT, when receive a redirection respond 300, it should re-use the header fields (except method) and bodies of the original request to construct the new request
SIP_UA_300_V_013Ensure that the IUT, when receive a redirection respond 300, UAs respond may contain several Contact fields or a list of addresses in a Contact field in the new request
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_301_V
SIP_UA_301_V_001_DF2aEnsure that the IUT, when receive a redirection respond 300, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_301_V_002_DF2aEnsure that the IUT, when processing 301 responses MUST NOT add any given URI to the target set more than once
SIP_UA_301_V_004_DF2aEnsure that the IUT, when receive a redirection respond 301 with multiple contacts with q value in the Contact header
SIP_UA_301_V_005_DF2aEnsure that the IUT, when receive a redirection respond 301, it should try the next perfer contact address UA prefers, if a failure for a paticular contact address. A new client transaction should be created
SIP_UA_301_V_006_DF2aEnsure that the IUT, when receive a redirection respond 301, it should try the next prefer contact address in the list in afailure, until the list is exhausted
SIP_UA_301_V_007_DF2aEnsure that the IUT, when receive a redirection respond 301, it should consider as a failure for a particular contact address if failure code returns (codes gretater than 399)
SIP_UA_301_V_008_DF2aEnsure that the IUT, when receive a redirection respond 300, in order to create a request based on 300 UAC MUST copy the entire URI from the target set into the Request-URI, except
SIP_UA_301_V_009_DF2aEnsure that the IUT, when receive a redirection respond 301, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_301_V_010_DF2aEnsure that the IUT, when receive a redirection respond 301, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to updated the Call-ID header field value of new requests
SIP_UA_301_V_011_DF2aEnsure that the IUT, when receive a redirection respond 301, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_301_V_012_DF2aEnsure that the IUT, when receive a redirection respond 301, it should re-use the header fields (except method) and bodies of the original request to construct
SIP_UA_301_V_013_DF2aEnsure that the IUT, when receive a redirection respond 301, the Contact header field values May be cached at UAC temporaril
SIP_UA_301_V_001Ensure that the IUT, when receive a redirection respond 301, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_301_V_002Ensure that the IUT, when processing 301 responses MUST NOT add any given URI to the target set more than once
SIP_UA_301_V_003Ensure that the IUT, when receive a redirection respond 301 and original request has a SIPS URI in the Request-URI, Clint May choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI
SIP_UA_301_V_004Ensure that the IUT, when receive 301 with q value in Contact header, using a mechanism to order the set by the “q" parameter value from the Contact header field value either serially or in parallel. One approach is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value
SIP_UA_301_V_005Ensure that the IUT, when receive a redirection respond 301, it should try the next contact address if a failure for a particular contact address. A new client transaction should be created to deliver a new request
SIP_UA_301_V_006Ensure that the IUT, when receive a redirection respond 301, it should try the next contact address in the list in a failure, until the list is exhausted. If the list is exhausted, then the request has failed
SIP_UA_301_V_007Ensure that the IUT, when receive a redirection respond 301, it should consider as a failure for a particular contact address if failure code returns (codes greater than 399)
SIP_UA_301_V_008Ensure that the IUT, when receive a redirection respond 301, in order to create a request based on 301, UAC MUST copy the entire URI from the target set into the Request-URI, except for the “method-param" and “header" URI parameters
SIP_UA_301_V_009Ensure that the IUT, when receive a redirection respond 301, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_301_V_010Ensure that the IUT, when receive a redirection respond 301, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to updated the Call-ID header field value of new requests
SIP_UA_301_V_011Ensure that the IUT, when receive a redirection respond 301, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_301_V_012Ensure that the IUT, when receive a redirection respond 301, it should re-use the header fields (except method) and bodies of the original request to construct the new request
SIP_UA_301_V_013Ensure that the IUT, when receive a redirection respond 301, the Contact header field values May be cached at UAC temporarily. The requestor SHOULD update any local directories and address book
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_302_V
SIP_UA_302_V_001_DF2aEnsure that the IUT, when receive a redirection respond 302, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_302_V_002_DF2aEnsure that the IUT, when processing 302 responses MUST NOT add any given URI to the target set more than once
SIP_UA_302_V_004_DF2aEnsure that the IUT, when receive a redirection respond 302 with multiple contacts with q value in the Contact header
SIP_UA_302_V_005_DF2aEnsure that the IUT, when receive a redirection respond 302, it should try the next perfer contact address UA prefers, if a failure for a paticular contact address. A new client transaction should be created
SIP_UA_302_V_006_DF2aEnsure that the IUT, when receive a redirection respond 302, it should try the next prefer contact address in the list in afailure, until the list is exhausted
SIP_UA_302_V_007_DF2aEnsure that the IUT, when receive a redirection respond 302, it should consider as a failure for a particular contact address if failure code returns (codes gretater than 399)
SIP_UA_302_V_008_DF2aEnsure that the IUT, when receive a redirection respond 302, in order to create a request based on 302 UAC MUST copy the entire URI from the target set into the Request-URI, except
SIP_UA_302_V_009_DF2aEnsure that the IUT, when receive a redirection respond 302, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_302_V_010_DF2aEnsure that the IUT, when receive a redirection respond 302, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to updated the Call-ID header field value of new requests
SIP_UA_302_V_011_DF2aEnsure that the IUT, when receive a redirection respond 302, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_302_V_012_DF2aEnsure that the IUT, when receive a redirection respond 302, it should re-use the header fields (except method) and bodies of the original request to construct
SIP_UA_302_V_013_DF2aEnsure that the IUT, when receive a redirection respond 302 with Expires header or an expires parameter in the Contact header field,
SIP_UA_302_V_014_DF2aEnsure that the IUT, when receive a redirection respond 302 with no explicit expiration time, the address is only valid once for recursing,
SIP_UA_302_V_001Ensure that the IUT, when receive a redirection respond 302, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_302_V_002Ensure that the IUT, when processing 302 responses MUST NOT add any given URI to the target set more than once
SIP_UA_302_V_003Ensure that the IUT, when receive a redirection respond 302 and original request has a SIPS URI in the Request-URI, Clint May choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI
SIP_UA_302_V_004Ensure that the IUT, using a mechanism to order the set by the “q" parameter value from the Contact header field value either serially or in parallel. One approach is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value
SIP_UA_302_V_005Ensure that the IUT, when receive a redirection respond 302, it should try the next contact address if a failure for a particular contact address. A new client transaction should be created to deliver a new request
SIP_UA_302_V_006Ensure that the IUT, when receive a redirection respond 302, it should try the next contact address in the list in a failure, until the list is exhausted. If the list is exhausted, then the request has failed
SIP_UA_302_V_007Ensure that the IUT, when receive a redirection respond 302, it should consider as a failure for a particular contact address if failure code returns (codes greater than 399)
SIP_UA_302_V_008Ensure that the IUT, when receive a redirection respond 302, in order to create a request based on 302, UAC MUST copy the entire URI from the target set into the Request-URI, except for the “method-param" and “header" URI parameters
SIP_UA_302_V_009Ensure that the IUT, when receive a redirection respond 302, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple value, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address
SIP_UA_302_V_010Ensure that the IUT, when receive a redirection respond 302, it is RECOMMENNDED that the UAC reused the same To, From, and Call-ID used in the original redirected request, but the UAC MAY als choose to updated the Call-ID header field value of new requests
SIP_UA_302_V_011Ensure that the IUT, when receive a redirection respond 302, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_302_V_012Ensure that the IUT, when receive a redirection respond 302, it should re-use the header fields (except method) and bodies of the original request to construct the new request
SIP_UA_302_V_013Ensure that the IUT, when receive a redirection respond 302 with Expires header or an expires parameter in the Contact header field, UAs may cache this URI for the duration of the expiration time
SIP_UA_302_V_014Ensure that the IUT, when receive a redirection respond 302 with no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_305_V
SIP_UA_305_V_001_DF2aEnsure that the IUT, when receive a redirection respond 305, it should use the URI(s) in the Contact header field to formulate one or more new requests. The Request-URI of the new request uses the value of the Contact header field in the respond
SIP_UA_305_V_002_DF2aEnsure that the IUT, when processing 305 responses MUST NOT add any given URI to the target set more than once
SIP_UA_305_V_004_DF2aEnsure that the IUT, when receive a redirection respond 305, it should consider as a failure for a particular contact address if failure code returns (codes gretater than 399)
SIP_UA_305_V_005_DF2aEnsure that the IUT, when receive a redirection respond 305, in order to create a request based on 302 UAC MUST copy the entire URI from the target set into the Request-URI, except
SIP_UA_305_V_006_DF2aEnsure that the IUT, when receive a redirection respond 305, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_UA_305_V_001Ensure that the IUT, when receive a redirection respond 305, it should use the URI(s) in the Contact header field as Proxy URI to formulate one new requests. The Request-URI of the new request should be same
SIP_UA_305_V_002Ensure that the IUT, when processing 305 responses it should reused all original headers, and Request-URI to repeat this single (same header and bodies) request to the Proxy
SIP_UA_305_V_003Ensure that the IUT, when receive a redirection respond 305 and original request has a SIPS URI in the Request-URI, Clint May choose to use a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI
SIP_UA_305_V_004Ensure that the IUT, when receive a redirection respond 305, it should consider as a failure for using Proxy to access if failure code returns (codes greater than 399)
SIP_UA_305_V_005Ensure that the IUT, when receive a redirection respond 305, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_380_V
SIP_UA_380_V_001_DF2aEnsure that the IUT, when receive a redirection respond 380 with the alternative services are described in the message body, UAs can either retry the call for new service or terminate the call
SIP_UA_380_V_001a_DF2aEnsure that the IUT, when receive a redirection respond 380 with the alternative services are described in the message body, UAs can either retry the call for new service or terminate the call
SIP_UA_380_V_002_DF2aEnsure that the IUT, when receives respond 302 following by 380 with the alternative services are described in the message body, UAs can either retry the call for new service or terminate the call
SIP_UA_380_V_002A_DF2aEnsure that the IUT, when receives respond 302 following by 380 with the alternative services are described in the message body, UAs can either retry the call for new service or terminate the call
SIP_UA_380_V_001Ensure that the IUT, when receive a redirection respond 380 with the alternative services are described in the message body, UAs can either retry the call for new service or terminate the call
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_485_V
SIP_UA_485_V_001Ensure that the IUT, when receives respond 485 with a listing of possible unambiguous addresses in Contact header fields, UAs should either respond 404(Not Found) or to suppress the listing of possible choice for ambiguous Request-URIs
SIP_UA_485_V_002_DF2aEnsure that the IUT, when receives respond 302 following by 485 with a listing of possible unambiguous addresses in Contact header fields , UAs should either respond 404(Not Found) or to suppress the listing of possible choice for ambiguous Request-URIs
SIP_UA_485_V_002A_DF2aEnsure that the IUT, when receives respond 302 following by 485 with a listing of possible unambiguous addresses in Contact header fields , UAs should either respond 404(Not Found) or to suppress the listing of possible choice for ambiguous Request-URIs
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_3XX_V
SIP_UA_3XX_V_001_DF2aEnsure that the IUT, when receives respond new 3XX respond as a result of sequential redirecting, if 302 Respond has a contact which already exists in the Target list and has been hunted, this duplicated target SHOULD not be added into target list and no more new request should send to this contact URI
SIP_UA_3XX_V_002_DF2aEnsure that the IUT, when receives respond new 3XX respond as a result of sequential redirecting, if 302 Respond has a contact which already exists in the Target list and has NOT been hunted, this duplicated target SHOULD not be added into target list and no more new request should send to this contact URI
SIP_UA_3XX_V_001Ensure that the IUT, when receives respond new 302 respond as a result of sequential redirecting, if 302 Respond has a contact which already exists in the Target list and has been hunted, this duplicated target SHOULD not be added into target list and no more new request should send to this contact URI
SIP_UA_3XX_V_002Ensure that the IUT, when receives respond new 302 respond as a result of sequential redirecting, if 302 Respond has a contact which already exists in the Target list and has NOT been hunted, this duplicated target SHOULD be removed first and then added into target list with the q value rule and new request should send to this contact URI when the turn comes
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_3xx_RD_V
SIP_3xx_RD_V_001Ensure that the IUT, when receives respond 302, should be able to send a well-formed CANCEL before the new request if user decide to terminate the call, RD should send back 2XX
SIP_3xx_RD_V_002Ensure that the IUT, when receives respond 302, should be able to send a well-formed CANCEL after the new request if user decide to terminate the call, RD should send back 2XX
SIP_3xx_RD_V_003Ensure that the IUT, when receives respond 301 that give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, UA should treat this is a valid 301 respond and general new request accordingly
SIP_3xx_RD_V_004Ensure that the IUT, when receives respond 301 that give the same location and username that was targeted by the initial request but specify additional transport parameters such as a change of SIP transport from UDP to TCP, UA should treat this is a valid 301 respond and general new request accordingly
SIP_3xx_RD_V_005Ensure that the IUT, when receives respond 302 that give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, UA should treat this is a valid 301 respond and general new request accordingly
SIP_3xx_RD_V_006Ensure that the IUT, when receives respond 302 that give the same location and username that was targeted by the initial request but specify additional transport parameters such as a change of SIP transport from UDP to TCP, UA should treat this is a valid 301 respond and general new request accordingly
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_UA_3XX_I
SIP_UA_3XX_I_001_DF2aEnsure that the IUT, when receives respond 302 that has duplicate contact in the Contact List, UA should only store one of them and send only one request to that location
SIP_UA_3XX_I_002_DF2aEnsure that the IUT, when receives respond 302 that has original contact URI in the Contact List, UA should ignore it and NOT send request to that location
SIP_UA_3XX_I_003_DF2aEnsure that the IUT, when receive a redirection respond 302 that has 7 different contact in the Contact List, UA should only store 6 of them per q value and list order and only send request to those 6 locations
SIP_UA_3XX_I_005_DF2aEnsure that the IUT, when receive a redirection respond 302 that has in valid q value in Contact header of the Contact List, UA should treat them as unknown only store one of them and send only one request to that location
SIP_UA_3XX_I_001Ensure that the IUT, when receives respond 302 that has duplicate contact in the Contact List, UA should only store one of them and send only one request to that location
SIP_UA_3XX_I_002Ensure that the IUT, when receives respond 302 that has original contact URI in the Contact List, UA should ignore it and NOT send request to that location
SIP_UA_3XX_I_003Ensure that the IUT, when receives respond 302 that has 7 different contact in the Contact List, UA should only store 6 of them per q value and list order and only send requests to those 6 location
SIP_UA_3XX_I_004Ensure that the IUT, when receives respond 302 that has multiple contact headers for the Contact List, UA should treat it as same as one contact header with comma separate list. UA should correct store than and send request to the correct location
SIP_UA_3XX_I_005Ensure that the IUT, when receives respond 302 that has invalid q value in Contact header of the Contact List, UA should treat them as unknown only store one of them and send only one request to that location
SIP_Extensions/
Redirection_Status_Code_Test/
SIP_3XX_RD_I
SIP_3XX_RD_I_001Ensure that the IUT, when receives respond 302 with expires parameter of a Contact header field value indicates an absolute time (>3600), UA should treat it as equivalent to 3600
SIP_3XX_RD_I_002Ensure that the IUT, when receives respond 302 with Expires header of a value indicates an absolute time (>3600), UA should treat it as equivalent to 3600
SIP_3XX_RD_I_003Ensure that the IUT, when receives respond 302 with unrecognized header fields, UA MUST ignore features and proceed with the redirection of the request in question
SIP_Extensions/
Subscribe_Notify_Test
SIP_Extensions/
Subscribe_Notify_Test/
SIP_UA_3265_HV
SIP_UA_3265_HV_001Ensure that the IUT, when it CAN bind header field Allow-Events into all the methods it supported (except CANCEL)
SIP_UA_3265_HV_001_SIPL_aEnsure that the SUT on receipt of an OPTIONS request, sends a Success (200 OK)
SIP_UA_3265_HV_001_SIPL_bEnsure that the SUT on receipt of an OPTIONS request, sends a Success (200 OK)
SIP_UA_3265_HV_002Ensure that the IUT, it MUST have Subscription-State header field in the NOTIFY it respond to SUBSCRIBE
SIP_UA_3265_HV_003Ensure that the IUT, when it constructs SUBSCRIBE request, it MUST have Event header field in the SUBSCRIBE
SIP_UA_3265_HV_004Ensure that the IUT, when constructs NOTIFY request, it MUST have Event header field in the NOTIFY
SIP_UA_3265_HV_005Ensure that the IUT, when it constructs 405 respond to SUBSCRIBE or NOTIFY, it MUST have Allow header field in 405
SIP_UA_3265_HV_006Ensure that the IUT, when it constructs SUBSCRIBE for existing dialog, it MUST copy the existing Call-ID into SUBSCRIBE
SIP_UA_3265_HV_007Ensure that the IUT, when it constructs NOTIFY for existing dialog, it MUST copy the existing Call-ID from SUBSCRIBE into NOTIFY
SIP_UA_3265_HV_008Ensure that the IUT, when it constructs SUBSCRIBE Request it MUST have correct Contact header field in SUBSCRIBE
SIP_UA_3265_HV_009Ensure that the IUT, when it sends NOTIFY Request, it MUST have correct Contact header field in NOTIFY
SIP_UA_3265_HV_010Ensure that the IUT, when it constructs 2XX respond for SUBSCRIBE request, it MUST have correct Contact header field in 2XX respond
SIP_UA_3265_HV_011that the IUT, when it constructs 3XX respond for SUBSCRIBE request, it MUST have correct Contact header field in 3XX respond
SIP_UA_3265_HV_012Ensure that the IUT, when it constructs 3XX respond for NOTIFY request, it MUST have correct Contact header field in 3XX respond
SIP_UA_3265_HV_013Ensure that the IUT, when it constructs SUBSCRIBE Request it MUST have correct Max-Forwards header field in SUBSCRIBE
SIP_UA_3265_HV_014Ensure that the IUT, when it sends NOTIFY Request, it MUST have correct Max-Forwards header field in NOTIFY
SIP_UA_3265_HV_015Ensure that the IUT, when it constructs 423 respond to SUBSCRIBE request, it MUST have Min-SE header field in 423
SIP_UA_3265_HV_016Ensure that the IUT, when it constructs 401 respond to SUBSCRIBE or NOTIFY, it MUST have WWW-Authenticate header field in 401
SIP_UA_3265_HV_017Ensure that the IUT, when it constructs 407 respond to SUBSCRIBE or NOTIFY, it MUST have Proxy-Authentication header field in 407
SIP_UA_3265_HV_018Ensure that the IUT, when it constructs SUBSCRIBE Request in existing dialog, it MUST copy CSeq header field into the SUBSCRIBE
SIP_UA_3265_HV_019Ensure that the IUT, when it constructs NOTIFY Request in existing dialog, it MUST copy CSeq header field into the NOTIFY from SUBSCRIBE
SIP_UA_3265_HV_020Ensure that the IUT, when it constructs SUBSCRIBE Request in existing dialog, it MUST copy From header field into the SUBSCRIBE
SIP_UA_3265_HV_021Ensure that the IUT, when it constructs NOTIFY Request in existing dialog, it MUST copy From header field into the NOTIFY from SUBSCRIBE
SIP_UA_3265_HV_022Ensure that the IUT, when it constructs SUBSCRIBE Request in existing dialog, it MUST copy To header field into the SUBSCRIBE
SIP_UA_3265_HV_023Ensure that the IUT, when it constructs NOTIFY Request in existing dialog, it MUST copy To header field into the NOTIFY from SUBSCRIBE
SIP_UA_3265_HV_024Ensure that the IUT, when it constructs SUBSCRIBE Request in existing dialog, it MUST copy Via header field into the SUBSCRIBE
SIP_UA_3265_HV_025Ensure that the IUT, when it constructs NOTIFY Request in existing dialog, it MUST copy Via header field into the NOTIFY from SUBSCRIBE
SIP_UA_3265_HV_026Ensure that the IUT, when it constructs 489 respond to SUBSCRIBE or NOTIFY, it MUST have Allow-Events header field in 489
SIP_UA_3265_HV_027Ensure that the IUT, when it constructs 489 to respond SUBSCRIBE request, it MUST have Allow-Events header field in the 489 respond
SIP_UA_3265_HV_028Ensure that the IUT, when it constructs 489 to respond NOTIFY request, it MUST have Allow-Events header field in the 489 respond
SIP_UA_3265_HV_029Ensure that the IUT, when it receives Responds or NOTIFY for the subscription, Event header, it SHOULD match the Event header in SUBSCRIBE on byte-by-byte base
SIP_UA_3265_HV_030Ensure that the IUT, when it constructs 489 to respond SUBSCRIBE or NOTIFY, it should have context "Bad Event"
SIP_Extensions/
Subscribe_Notify_Test/
SIP_UA_3265_V
SIP_UA_3265_V_001Ensure that the IUT, when it constructs a SUBSCRIBE request, it SHOULD contain Expires header field with a value indicates the duration of the subscription
SIP_UA_3265_V_002Ensure that the IUT, when it receives SUBSCRIBE request, it responds 200-class respond, it MUST have an Expires header in the respond with a value which MUST not longer than the one in SUBSCRIBE
SIP_UA_3265_V_003Ensure that the IUT, when it wants to unsubscribe after he subscription done, it CAN send a SUBSCRIBE request with Expires header with value 0
SIP_UA_3265_V_004Ensure that the IUT, when it sends SUBSCRIBE for an event, it MUST have Request URI, Event Type and optionally message body
SIP_UA_3265_V_005Ensure that the IUT, when it sends SUBSCRIBE for an event, it MUST have exactly one "Event" header in the request indicating which event it is subscribing and optionally can have id (e.g. multiple REFER requests)
SIP_UA_3265_V_006Ensure that the IUT, when sends SUBSCRIBE, it MAY also have header field Accept in the request with value NOTIFY
SIP_UA_3265_V_007Ensure that the IUT, when it receives SUBSCRIBE for an event and it is acceptable, it SHOULD return a 200 response with Expires header and immediately send a NOTIFY
SIP_UA_3265_V_008Ensure that the IUT, when it receives SUBSCRIBE for an event and it is understood but not authorized yet, it SHOULD return a 202 response with Expires header and immediately send a NOTIFY
SIP_UA_3265_V_009Ensure that the IUT, when it receives SUBSCRIBE for an event and it is not valid, it SHOULD return a non-200 class response and no NOTIFY message will be sent. There will be no subscription or dialog created
SIP_UA_3265_V_010Ensure that the IUT, when it does refresh for the subscription, it MUST send a SUBSCRIBE message with same Event header and id parameter if there is one in the initial SUBSCRIBE message
SIP_UA_3265_V_011Ensure that the IUT, when it does a new subscription for the same event, it MUST send a SUBSCRIBE message with same Event header and different id parameter to the one in the initial SUBSCRIBE message
SIP_UA_3265_V_012Ensure that the IUT, when it receives a SUBSCRIBE message with same Event header but different id parameter, it MUST consider this is a new subscription
SIP_UA_3265_V_013Ensure that the IUT, when it receives a 481 response to a refresh SUBSCRIBE request it sent, it should NOT consider the subscription is success. It MUST send new SUBSCRIBE request if it like to re-subscribe the events
SIP_UA_3265_V_014Ensure that the IUT, when it receives subscribing request with no Expires header, it SHOULD treat it as has Expires header with default value 3600
SIP_UA_3265_V_015Ensure that the IUT, when it sends SUBSCRIBE for subscription, it MUST be prepared to receive NOTIFY messages before the SUBSCRIBE transaction has completed
SIP_UA_3265_V_016Ensure that the IUT, when it receives SUBSCRIBER for subscription, it SHOULD check the event package in Event header, if it is NOT understood or NOT supported it MUST return 489 Bad Event
SIP_UA_3265_V_017Ensure that the IUT, when it receives a subscription, if Expires header is grater than zero and smaller than one hour and less than notifier configured minimum, it MAY return 423 Interval too small with Min-SE header with a right value
SIP_UA_3265_V_018Ensure that the IUT, when it receives NOTIFY for subscription, it MUST check to see it is for an outstanding subscription, if not it MUST return a 481 with context "Subscription does not exist"
SIP_UA_3265_V_018_aEnsure that the IUT, when it receives NOTIFY for subscription, it MUST check to see it is for an outstanding subscription, if not it MUST return a 481 with context "Subscription does not exist"
SIP_UA_3265_V_018_bEnsure that the IUT, when it receives NOTIFY for subscription, it MUST check to see it is for an outstanding subscription, if not it MUST return a 481 with context "Subscription does not exist"
SIP_UA_3265_V_019Ensure that the IUT, when it receives SUBSCRIBER for subscription, if it MAY send 401 respond to request Authentication
SIP_UA_3265_V_020_NoKeepAliveEnsure that the IUT, when it sends SUBSCRIBER for subscription, and it receives 401, it should follow the Authentication procedure as state in RFC3261 if it supports authentication
SIP_UA_3265_V_021Ensure that the IUT, when it sends SUBSCRIBER for subscription, and it receives 407, it should follow the Proxy Authentication procedure as state in RFC3261 if it supports authentication
SIP_UA_3265_V_022Ensure that the IUT, when it receives a subscription refresh with Expires header too short, it SHOULD respond 423 with context Subscription Too Brief
SIP_UA_3265_V_023Ensure that the IUT, when it is in a subscription and not receives a refresh subscription before its expiration, it SHOULD remove subscription, and send a NOTIFY with Subscription-State with terminated with parameter reason=timeout
SIP_UA_3265_V_024Ensure that the IUT, when it receives SUBSCRIBE, it MAY trigger several NOTIFY requests, it CAN just send one Final NOTIFY or more NOTIFY before the final one
SIP_UA_3265_V_025Ensure that the IUT, when it receives SUBSCRIBE, it MUST respond NOTIFY with Event header with same package name as in SUBSCRIBE, if the id parameter is presented in SUBSCRIBE, it also MUST presented in NOTIFY
SIP_UA_3265_V_026Ensure that the IUT, when it responds a NOTIFY for SUBSCRIBE, if it contains a body message, it MUST use the body formats specified in the Accept header of the corresponding SUBSCRIBE request
SIP_UA_3265_V_027Ensure that the IUT, when it does not receive respond for a NOTIFY after time out, it SHOULD remove the subscription
SIP_UA_3265_V_028Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_403Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_404Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_408Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_480Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_481Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_486Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_488Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_489Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_028_500Ensure that the IUT, when it receives non-200 class respond with no "Retry-After" header, it SHOULD remove the subscription
SIP_UA_3265_V_029Ensure that the IUT, when it receives 481 respond, it SHOULD remove the subscription
SIP_UA_3265_V_029_401Ensure that the IUT, when it receives 401 respond to immediately NOTIFY, it SHOULD resend NOTIFY with authentication
SIP_UA_3265_V_029_403Ensure that the IUT, when it receives 403 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_404Ensure that the IUT, when it receives 404 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_408Ensure that the IUT, when it receives 408 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_480Ensure that the IUT, when it receives 408 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_481Ensure that the IUT, when it receives 481 respond, it SHOULD remove the subscription
SIP_UA_3265_V_029_486Ensure that the IUT, when it receives 486 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_488Ensure that the IUT, when it receives 488 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_489Ensure that the IUT, when it receives 489 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_029_500Ensure that the IUT, when it receives 500 respond to immediately NOTIFY, it SHOULD remove the subscription
SIP_UA_3265_V_030Ensure that the IUT, when it responds a NOTIFY for SUBSCRIBE, it SHOULD contain expires parameter indicates the time remaining on the subscription if Subscription-State is active
SIP_UA_3265_V_031Ensure that the IUT, when it responds a NOTIFY for SUBSCRIBE, it SHOULD contain expires parameter indicates the time remaining on the subscription if Subscription-State is pending
SIP_UA_3265_V_032Ensure that the IUT, when it responds a NOTIFY for SUBSCRIBE, it SHOULD contain reason parameter indicates the correct reason of the termination on the subscription if Subscription-State is terminated
SIP_UA_3265_V_033Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is deactivated, it SHOULD retry immediately a new subscription if need to
SIP_UA_3265_V_033_WSEnsure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is deactivated, it SHOULD retry immediately a new subscription if need to
SIP_UA_3265_V_034Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is probation and retry-after parameter also presented, it SHOULD NOT retry a new subscription before retry-after timer expires
SIP_UA_3265_V_035Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is giveup and retry-after parameter also presented, it SHOULD NOT retry a new subscription before retry-after timer expires
SIP_UA_3265_V_036Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is rejected, it SHOULD NOT retry a new subscription
SIP_UA_3265_V_037Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is timeout, it MAY retry a new subscription immediately if needed
SIP_UA_3265_V_038Ensure that the IUT, when it receives a NOTIFY for SUBSCRIBE with Subscription-State is terminated, if the reason parameter is noresource, it SHOULD NOT retry a new subscription
SIP_UA_3265_V_039Ensure that the IUT, when it receives de-subscription request SUBSCRIBE with an Expires equal to 0, it should send NOTIFY with Subscription-State of value terminated and reason of timeout.
SIP_UA_3265_V_040Ensure that the IUT, CAN request multiple subscriptions for a single dialog
SIP_UA_3265_V_041Ensure that the IUT, it SHOULD be able handle multiple subscriptions for a single dialog
SIP_UA_3265_V_042Ensure that the IUT, it SHOULD put Allow-Events header in the all methods which initiate dialogs and their responds to advertise that it can process SUBSCRIBE and generate NOTIFY request for all of the event package listed in that header
SIP_UA_3265_V_043Ensure that the IUT, it SHOULD be able handle 3XX for subscription
SIP_UA_3265_V_044Ensure that the IUT, it SHOULD be able handle 3XX for NOTIFY
SIP_UA_3265_V_045Ensure that the IUT, when it sends SUBSCRIBER for subscription, and it receives 423, it should reSUBSCIRBE using Min-Expires header
SIP_Extensions/
Subscribe_Notify_Test/
SIP_UA_3265_I
SIP_UA_3265_I_001Ensure that the IUT, when it receives a SUBSCRIBE without Event header field it SHOULD return 489.
SIP_UA_3265_I_002Ensure that the IUT, when it receives a NOTIFY without Event header field it SHOULD return 489.
SIP_UA_3265_I_003Ensure that the IUT, when it receives a NOTIFY without Subscription-State header field it SHOULD return 400
SIP_UA_3265_I_004Ensure that the IUT, when it receives a NOTIFY with Event field header set to whatever, it SHOULD return 489 Bad Event
SIP_UA_3265_I_005Ensure that the IUT, when it receives a NOTIFY with Subscription-State with value whatever, it SHOULD return 400 or ignore it
SIP_UA_3265_I_006Ensure that the IUT, when it receives a NOTIFY with no matching From, To, Call-ID, it SHOULD return 481
SIP_UA_3265_I_006_aEnsure that the IUT, when it receives a NOTIFY with no matching From, To, Call-ID, it SHOULD return 481.
SIP_UA_3265_I_006_bEnsure that the IUT, when it receives a NOTIFY with no matching From, To, Call-ID, it SHOULD return 481.
SIP_UA_3265_I_006_cEnsure that the IUT, when it receives a NOTIFY with no matching From, To, Call-ID, it SHOULD return 481.
SIP_UA_3265_I_007Ensure that the IUT, when it receives a NOTIFY with same Call-ID, From and To, but different CSeq value, it SHOULD return 500
SIP_UA_3265_I_008Ensure that the IUT, it sends SUBSCRIBE with Event header refer, then it receives a NOTIFY with Event header with value Presence, it SHOULD return 489
SIP_UA_3265_I_009Ensure that the IUT, it sends SUBSCRIBE with Event header refer and id parameter, then it receives a NOTIFY with Event header with same value but different id parameter, it SHOULD return 489
SIP_UA_3265_I_010Ensure that the IUT, when it receives a NOTIFY with Subscription-State with value of active but no expires parameter, it SHOULD proceed correctly.
SIP_UA_3265_I_011Ensure that the IUT, when it receives a NOTIFY with Subscription-State with value of terminated but no reason parameter, it SHOULD proceed correctly.
SIP_UA_3265_I_012Ensure that the IUT, when it receives a NOTIFY with Subscription-State with value of terminated but reason parameter set to value whatever, it SHOULD proceed correctly.
SIP_UA_3265_I_013Ensure that the IUT, when it receives a 202 to respond SUBSCRIBE without Expires header, it MAY terminated the subscription
SIP_UA_3265_I_014Ensure that the IUT, when it receives a SUBSCRIBE with two Event headers field, it SHOULD return 400
SIP_UA_3265_I_015Ensure that the IUT, when it receives a SUBSCRIBE with Expires with value 1, it SHOULD return 423 Interval too small with Min-Expires header
SIP_UA_3265_I_016Ensure that the IUT, when it receives a NOTIFY before 2xx final respond for the SUBSCRIBE it sent, it SHOULD respond correctly
SIP_UA_3265_I_017Ensure that the IUT, when it does NOT receive final respond for the SUBSCRIBE it sent after time out, it SHOULD remove the subscription
SIP_UA_3265_I_018Ensure that the IUT, when it does NOT receive final respond for the NOTIFY it sent after timeout, it SHOULD remove the subscription
SIP_UA_3265_I_019Ensure that the IUT, when it receives SUBSCRIBE with an Event that is not allowed, it should return 403
SIP_Extensions/
Info_Compliance_Test_Plan
SIP_Extensions/
Info_Compliance_Test_Plan/
SIP_UA_2976_HV
SIP_UA_2976_HV_001Ensure that the IUT, when it constructs respond of INFO, it MUST copy the Call-ID header field from INFO
SIP_UA_2976_HV_002Ensure that the IUT, when it constructs respond of INFO, it MUST copy the CSeq header field from INFO
SIP_UA_2976_HV_003Ensure that the IUT, when it constructs respond of INFO, it MUST copy the From header field from INFO
SIP_UA_2976_HV_004Ensure that the IUT, when it constructs respond of INFO, it MUST copy the To header field from INFO
SIP_UA_2976_HV_005Ensure that the IUT, when it constructs respond of INFO, it MUST copy the Via header field from INFO
SIP_UA_2976_HV_006Ensure that the IUT, when it constructs INFOR, it MUST have headers To, From, Via, Call-ID, CSeq, but NOT limited to these
SIP_Extensions/
Info_Compliance_Test_Plan/
SIP_UA_2976_V
SIP_UA_2976_V_001Ensure that the IUT, when it receives an INFO request, it MUST send a final response
SIP_UA_2976_V_002Ensure that the IUT, when it receives an INFO request, it MUST send a 200 OK with no message body if the INFOR was successfully received for an existing call and no further action required
SIP_UA_2976_V_003Ensure that the IUT, when it receives an INFO request with body message that does not understand, it MUST respond with 415 Unsupported Media Type message
SIP_UA_2976_V_004Ensure that the IUT, after it receives an INFO then it receives a CANCEL that matches the INFO, it SHOULD send 487 Request Cancelled if the final respond not being sent back for the INFO
SIP_UA_2976_V_004_INEnsure that the IUT, after it receives an INFO then it receives a CANCEL that matches the INFO, it SHOULD send 487 Request Cancelled if the final respond not being sent back for the INFO
SIP_UA_2976_V_005Ensure that the IUT, when it receives an INFO it will respond a final respond, but it MUST NOT change the state of the SIP call
SIP_UA_2976_V_006Ensure that the IUT, when it sends consecutive INFO, it SHOULD increment CSeq header in the INFO
SIP_Extensions/
Info_Compliance_Test_Plan/
SIP_UA_2976_I
SIP_UA_2976_I_001Ensure that the IUT, when it receives INFO Request that could not match to a existing call due header To is not right, 481 Call Leg/Transaction Does Not Exist
SIP_UA_2976_I_002Ensure that the IUT, when it receives INFO Request that could not match to a existing call due header From is not right, 481 Call Leg/Transaction Does Not Exist
SIP_UA_2976_I_003Ensure that the IUT, when it receives INFO Request that could not match to a existing call due header Via is not right, 481 Call Leg/Transaction Does Not Exist
SIP_UA_2976_I_004Ensure that the IUT, when it receives INFO Request that could not match to a existing call due header Call-ID is not right, 481 Call Leg/Transaction Does Not Exist
SIP_UA_2976_I_005Ensure that the IUT, when it receives INFO Request that could not match to a existing call due header CSeq is not right, 481 Call Leg/Transaction Does Not Exist
SIP_UA_2976_I_006Ensure that the IUT, when it receives an INFO request with body message that does not understand, it MUST respond with 415 Unsupported Media Type message
SIP_Extensions/
Update_Compliance_Test_Plan
SIP_Extensions/
Update_Compliance_Test_Plan/
SIP_UA_3311_HV
SIP_UA_3311_HV_001Ensure that the IUT, when it constructs 405 to respond UPDATE, it MUST have Allow header in 405 respond
SIP_UA_3311_HV_002Ensure that the IUT, when it constructs UPDATE it MUST have header field Call-ID and copy it from the existing dialog
SIP_UA_3311_HV_003Ensure that the IUT, when it constructs UPDATE request, it MUST have Contact field in the request
SIP_UA_3311_HV_004Ensure that the IUT, when it constructs the 2XX final respond to the UPDATE request, it MUST have Contact field in the 2XX final respond
SIP_UA_3311_HV_005Ensure that the IUT, when it constructs the responds of UPDATE it MUST have header field CSeq and copy from UPDATE request
SIP_UA_3311_HV_006Ensure that the IUT, when it constructs UPDATE request, it MUST have header field CSeq in the UPDATE request
SIP_UA_3311_HV_007Ensure that the IUT, when it constructs UPDATE request, it MUST have header field Max-Forwards in the UPDATE request
SIP_UA_3311_HV_008Ensure that the IUT, when it constructs UPDATE request, it MUST have header field To in the UPDATE request
SIP_UA_3311_HV_009Ensure that the IUT, when it constructs a respond to UPDATE request, it MUST have header field To in the respond and copy it from UPDATE request
SIP_UA_3311_HV_010Ensure that the IUT, when it constructs UPDATE request, it MUST have header field Via in the UPDATE request
SIP_UA_3311_HV_011Ensure that the IUT, when it constructs respond to UPDATE request, it MUST have header field Via in the respond and copy it from the UPDATE request
SIP_UA_3311_HV_012Ensure that the IUT, when it constructs 407 final respond to UPDATE request, it MUST have header field Proxy-Authenticate in the 407
SIP_UA_3311_HV_013Ensure that the IUT, when it constructs 401 final respond to UPDATE request, it MUST have header field WWW-Authenticate in the 401
SIP_Extensions/
Update_Compliance_Test_Plan/
SIP_UA_3311_V
SIP_UA_3311_V_001Ensure that the IUT, when it sends INVITE it should include Allow header with method UPDATE to indicate it does support UPDATE methods
SIP_UA_3311_V_002Ensure that the IUT, when it receives INVITE with Allow header which states support UPDATE, if it generates reliable provisional respond containing SDP, the respond SHOULD contain an Allow header field with UPDATE method
SIP_UA_3311_V_003Ensure that the IUT, when it receives INVITE with Allow header which states support UPDATE, if it generates an unreliable provisional respond, the respond MAY contain an Allow header field with UPDATE method
SIP_UA_3311_V_004Ensure that the IUT, when it receives INVITE with Allow header which states support UPDATE, if it a final respond, the respond SHOULD contain an Allow header field with UPDATE method
SIP_UA_3311_V_005Ensure that the IUT, when it MAY send UPDATE in a early or confirmed dialogs, but confirmed dialog is NOT recommended (rather should use re-INVITE)
SIP_UA_3311_V_006Ensure that the IUT, when it receives INVITE and have not sent 2XX final respond yet, it MUST place the same Contact header into the UPDATE as the 2XX final respond for that INVITE request
SIP_UA_3311_V_007Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the initial INVITE it sent contains an offer, it MAY send UPDATE with an offer if callee responds an answer in a reliable provisional respond
SIP_UA_3311_V_008Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the initial INVITE it sent contains an offer, it MUST NOT send UPDATE with an offer if callee does not responds an answer in a reliable provisional respond
SIP_UA_3311_V_008_180Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the initial INVITE it sent contains an offer, it MUST NOT send UPDATE with an offer if callee does not responds an answer in a reliable provisional respond.
SIP_UA_3311_V_008_183Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the initial INVITE it sent contains an offer, it MUST NOT send UPDATE with an offer if callee does not responds an answer in a reliable provisional respond.
SIP_UA_3311_V_009Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the PRACK it sent contains an offer, it MUST NOT send UPDATE with an offer if callee does not responds an answer for the PRACK
SIP_UA_3311_V_010Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, if the previous UPDATE it sent contains an offer, it MUST NOT send another UPDATE with an offer if callee does not responds an answer for the previous UPDATE
SIP_UA_3311_V_011Ensure that the IUT, when it sends UPDATE after the INVITE transaction complete, it MUST NOT send another UPDATE with an offer if callee does not responds an answer for the previous UPDATE
SIP_UA_3311_V_012Ensure that the IUT, when it sends UPDATE after the INVITE transaction complete, it MUST NOT send another UPDATE with an offer if callee does not responds an answer for the re-INVITE
SIP_UA_3311_V_013Ensure that the IUT, when it sends UPDATE after the INVITE transaction complete, if the INVITE it sent does NOT have offer, it MAY send UPDATE with an offer if there is offer and answer being exchanged either in PRACK or previous UPDATE
SIP_UA_3311_V_014Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, the initial INVITE it receives containing an offer, it MUST NOT send an UPDATE with an offer if it does not responds an answer in a reliable provisional response for the initial INVITE
SIP_UA_3311_V_015Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, the initial INVITE it receives containing an offer, it MUST NOT send an UPDATE with an offer if it does not receive any request with offers that it has not answered
SIP_UA_3311_V_016Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, the initial INVITE it receives containing an offer, it MUST NOT send an another UPDATE with an offer if it does not receive an answer for previous UPDATE it sent
SIP_UA_3311_V_017Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, the initial INVITE it receives does not contain an offer, it MUST NOT send an UPDATE with an offer if it does not responds an offer in a reliable provisional response for the initial INVITE and receives an answer in PRACK
SIP_UA_3311_V_018Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, it MUST NOT send an UPDATE with an offer if it does not responds an answer in to an UPDATE with an offer it received
SIP_UA_3311_V_019Ensure that the IUT, when it sends UPDATE before the INVITE transaction complete, it MUST NOT send an UPDATE with an offer if it does not receive an answer in the previous UPDATE it sent to
SIP_UA_3311_V_020Ensure that the IUT, when it sends UPDATE after the INVITE transaction complete, it MUST NOT send an UPDATE with an offer if it does not receive an answer in the previous UPDATE it sent to or it does not respond to the UPDATE with offer
SIP_UA_3311_V_021Ensure that the IUT, when it sends UPDATE after the INVITE transaction complete, it MUST NOT send an UPDATE with an offer if it does not receive an answer in the re-INVITE it sent to or does not respond to the re-INVITE with an offer
SIP_UA_3311_V_022Ensure that the IUT, when it receives a UPDATE before it generates a final respond of the previous UPDATE, it MUST return 500 respond to the new UPDATE
SIP_UA_3311_V_022_180Ensure that the IUT, when it receives a UPDATE before it generates a final respond of the previous UPDATE, it MUST return 500 respond to the new UPDATE
SIP_UA_3311_V_023Ensure that the IUT, when it generates 500 respond to the UPDATE, it MUST include a Retry-After header field with a value between 0 to 10 seconds
SIP_UA_3311_V_024Ensure that the IUT, when it receives an UPDATE with an offer after it generated an offer in INVITE, which is NOT yet being answered, it MUST reject the UPDATE with 491
SIP_UA_3311_V_025Ensure that the IUT, when it receives an UPDATE with an offer after it generated an offer in PRACK, which is NOT yet being answered, it MUST reject the UPDATE with 491
SIP_UA_3311_V_026Ensure that the IUT, when it receives an UPDATE with an offer after it generated an offer in UPDATE, which is NOT yet being answered, it MUST reject the UPDATE with 491
SIP_UA_3311_V_026_180Ensure that the IUT, when it receives an UPDATE with an offer after it generated an offer in UPDATE, which is NOT yet being answered, it MUST reject the UPDATE with 491
SIP_UA_3311_V_027Ensure that the IUT, when it receives an UPDATE with an offer after it received an offer in another UPDATE, which it has NOT yet answered it, it MUST reject the UPDATE with 500 containing Retry-After header with value between 0 to 10 seconds
SIP_UA_3311_V_028Ensure that the IUT, when it receives an UPDATE with an offer after it received an offer in PRACK, which it has NOT yet answered it, it MUST reject the UPDATE with 500 containing Retry-After header with value between 0 to 10 seconds
SIP_UA_3311_V_029Ensure that the IUT, when it receives an UPDATE with an offer after it received an offer in INVITE, which it has NOT yet answered it, it MUST reject the UPDATE with 500 containing Retry-After header with value between 0 to 10 seconds
SIP_UA_3311_V_030Ensure that the IUT, when it receives an UPDATE in the existing dialog, and if the session parameters cannot be changed, it SHOULD reject with 504
SIP_UA_3311_V_030_aEnsure that the IUT, when it receives an UPDATE in the existing dialog, and if the session parameters cannot be changed, it SHOULD reject with 504
SIP_UA_3311_V_031Ensure that the IUT, when it receives an UPDATE in the existing dialog, and if the session parameters is NOT acceptable, it SHOULD reject the UPDATE with 488 Not Acceptable here with Warning header
SIP_UA_3311_V_032Ensure that the IUT, when it receives 491 respond to its UPDATE, it SHOULD start a timer with value between 2.1 to 4 seconds if it owns the Call-ID and SHOULD resend UPDATE once more when the timer expires, and state SHOULD NOT be changed
SIP_UA_3311_V_033Ensure that the IUT, when it receives 491 respond to its UPDATE, it SHOULD start a timer with value between 0 to 2 seconds if it does NOT own the Call-ID and SHOULD resend UPDATE once more when the timer expires, and state SHOULD NOT be changed
SIP_Extensions/
Update_Compliance_Test_Plan/
SIP_UA_3311_I
SIP_UA_3311_I_001Ensure that the IUT, when it receives 481 Call/Transaction Does Not Exist respond to its UPDATE, it CAN terminate the dialog
SIP_UA_3311_I_002Ensure that the IUT, when it receives 408 Request Timeout respond to its UPDATE, it CAN terminate the dialog
SIP_UA_3311_I_003Ensure that the IUT, when it receives no respond to its UPDATE, it CAN terminate the dialog
SIP_UA_3311_I_004Ensure that the IUT, when it receives UPDATE after INVITE trasaction complete, it should respond accordingly
SIP_UA_3311_I_004_g729Ensure that the IUT, when it receives UPDATE after INVITE trasaction complete, it should