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 2009
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 respond accordingly
SIP_UA_3311_I_004_g730Ensure that the IUT, when it receives UPDATE after INVITE trasaction complete, it should respond accordingly
SIP_UA_3311_I_004_reINVITEEnsure that the IUT, when it receives UPDATE after INVITE trasaction complete, it should respond accordingly
SIP_Extensions/
Replace_Compliance_Test_Plan
SIP_Extensions/
Replace_Compliance_Test_Plan/
SIP_UA_3891_HV
SIP_UA_3891_HV_001Ensure that the IUT, when it bind Replaces header in a Method, it is only in INVITE not other methods
SIP_UA_3891_HV_002Ensure that the IUT, when it receives Replace header in a Non-INVITE method, it should returns 400 Bad Request
SIP_UA_3891_HV_003Ensure that the IUT, when it bind INVITE with Replace header, it MUST contain exactly one to-tag, exactly one from-tag with one callID need to be replaced
SIP_UA_3891_HV_004Ensure that the IUT, when it bind INVITE with Replace header, it must in the syntax of "Replace: called;from-tag=token;to-tag=token"
SIP_UA_3891_HV_005Ensure that the IUT, when it binds INVITE with Replace header, it MAY contain with early-flag with exactly one to-tag, exactly one from-tag with one callID need to be replaced
SIP_UA_3891_HV_006Ensure that the IUT, when it act as UAS, it MUST include Supported header with "replaces"
SIP_UA_3891_HV_007Ensure that the IUT, when it act as UAS, if it wants explicit failure notification if Replaces header is not supported, it MAY include Require header with "replaces"
SIP_Extensions/
Replace_Compliance_Test_Plan/
SIP_UA_3891_V
SIP_UA_3891_V_001Ensure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match this information with a confirmed or early dialog
SIP_UA_3891_V_001_aEnsure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match this information with an early dialog
SIP_UA_3891_V_001_bEnsure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match this information with a confirmed dialog
SIP_UA_3891_V_002Ensure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match the to-tag to local tag and the from-tag to the remote tag in a confirmed or early dialog
SIP_UA_3891_V_002_aEnsure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match the to-tag to local tag and the from-tag to the remote tag in an early dialog
SIP_UA_3891_V_002_bEnsure that the IUT, when it receives an INVITE with a Replaces header, it should attempt to match the to-tag to local tag and the from-tag to the remote tag in a confirmed dialog
SIP_UA_3891_V_003Ensure that the IUT, when it sends INVITE with Replace header, it MUST send one and only one Replace header
SIP_UA_3891_V_004Ensure that the IUT, when it receives INVITE with Replace header, if the Call-ID is Not matched any confirmed or early dialog, it SHOULD return 481 Call/Transaction Does Not Exist"
SIP_UA_3891_V_004_aEnsure that the IUT, when it receives INVITE with Replace header, if the Call-ID is Not matched any early dialog, it SHOULD return 481 Call/Transaction Does Not Exist".
SIP_UA_3891_V_004_bEnsure that the IUT, when it receives INVITE with Replace header, if the Call-ID is Not matched any confirmed dialog, it SHOULD return 481 Call/Transaction Does Not Exist".
SIP_UA_3891_V_005Ensure that the IUT, when it receives INVITE with Replace header and matches more than one dialog, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_V_006Ensure that the IUT, when it receives INVITE with Replace header which matches a dialog is not created with an INVITE, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_V_007Ensure that the IUT, when it receives INVITE with Replace header which matches a dialog has already terminated, it SHOULD return 603 Declined
SIP_UA_3891_V_008Ensure that the IUT, when it receives INVITE with Replace header field matches a confirmed dialog, it should reassign the user interface and resources of the matched dialog to the new INVITE and shut down the replaced dialog by sending BYE
SIP_UA_3891_V_009Ensure that the IUT, when it receives INVITE with Replace header field matches a early dialog that was initiated by itself, it should accepts the new INVITE by sending 2XX and shut down the replaced dialog by sending CANCEL
SIP_UA_3891_V_010_aEnsure that the IUT, when it receives INVITE with Replace header field matches a early dialog that was NOT initiated by itself, it should returns a 481 Call/Transaction Does Not Exist and leave the matched dialog unchanged.
SIP_UA_3891_V_010_bEnsure that the IUT, when it receives INVITE with Replace header field matches a early dialog that was NOT initiated by itself, it should returns a 481 Call/Transaction Does Not Exist and leave the matched dialog unchanged.
SIP_UA_3891_V_010_cEnsure that the IUT, when it receives INVITE with Replace header field matches a early dialog that was NOT initiated by itself, it should returns a 481 Call/Transaction Does Not Exist and leave the matched dialog unchanged.
SIP_UA_3891_V_010Ensure that the IUT, when it receives INVITE with Replace header field matches a early dialog that was NOT initiated by itself, it should returns a 481 Call/Transaction Does Not Exist and leave the matched dialog unchanged
SIP_UA_3891_V_011Ensure that the IUT, when it receives INVITE with Replace header field matches a confirm dialog with "early-only" flag in the Replaces header field, it should rejects the request with 486 Busy
SIP_UA_3891_V_012Ensure that the IUT, when it wants to replace an existing confirmed dialog it MAY send an new INVITE with Replaces header with correct Call-ID, to-tag and from-tag
SIP_UA_3891_V_013Ensure that the IUT, when it wants to replace an existing early dialog it MAY send an new INVITE with Replaces header with correct Call-ID, to-tag, from-tag and may also include "early-only" parameter
SIP_UA_3891_V_014Ensure that the IUT, when it does NOT send out new INVITE with Replaces header to attempt to replace an early dialog not originated by itself
SIP_UA_3891_V_015Ensure that the IUT, when it does Replacing an Early Dialog at the originator as message flow in session 7.1
SIP_UA_3891_V_016Ensure that the IUT, when it does do INVITE with Replace to replace with confirm dialog, make sure the message flow complied with session 7
SIP_Extensions/
Replace_Compliance_Test_Plan/
SIP_UA_3891_I
SIP_UA_3891_I_001Ensure that the IUT, when it receives an INVITE with more than one Replaces header, it SHOULD reject the request with 400 Bad Request
SIP_UA_3891_I_002Ensure that the IUT, when it receives an INVITE with more than one Replaces header, it SHOULD reject the request with 400 Bad Request
SIP_UA_3891_I_003Ensure that the IUT, when it receives a non-INVITE Request with Replace header, it SHOULD reject the request with 400 Bad Request
SIP_UA_3891_I_004Ensure that the IUT, when it receives an INVITE with Replace header as well as another header with contradictory semantics, it SHOULD reject the request with 400 Bad Request
SIP_UA_3891_I_005Ensure that the IUT, when it receives INVITE with Replace header, if to-tag does not match, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_I_006Ensure that the IUT, when it receives INVITE with Replace header, if from-tag does not match, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_I_007Ensure that the IUT, when it receives INVITE with Replace header without to-tag, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_I_008Ensure that the IUT, when it receives INVITE with Replace header without From-tag, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_UA_3891_I_009Ensure that the IUT, when it receives INVITE with Replace header without Call-ID, it SHOULD return 481 Call/Transaction Does Not Exist
SIP_Extensions/
Refer_By_Compliance_Test_Plan
SIP_Extensions/
Refer_By_Compliance_Test_Plan/
SIP_UA_3892_V
SIP_UA_3892_V_001Ensure that the IUT, when it is Referrer, it provides a Referred-By header with its SIP address-of-record, optionally associating an S/MIME protected token reflecting the identity of the referrer and the details of the REFER request
SIP_UA_3892_V_002Ensure that the IUT, when it is Referee, if it receives REFER request with Referred-By header, it SHOULD compare this header and the token, if provided into the INVITE
SIP_UA_3892_V_003Ensure that the IUT, when it is Referrer, it MUST NOT contain more than one Referred-by header field value
SIP_UA_3892_V_004Ensure that the IUT, when it is Referrer, it May include a Referred-By token in a REFER request, the token MUST contain a Referred-By header field value with a cid parameter value equal to the Content-ID of the body part containing the token
SIP_UA_3892_V_005Ensure that the IUT, when it is Referrer, it CAN re-send REFER with Referred-By token when it receives 429 "Provide Referrer Identity" if the first REFER sent without token or token is invalid. Check CSeq in REFER and token in the new REFER
SIP_UA_3892_V_006Ensure that the IUT, when it is Referee, it must copy any Referred-By header field value and token into INVITE without modification
SIP_UA_3892_V_007Ensure that the IUT, when it is Referee, it MAY reject a REFER request that does not contain a Referred-By Token with a 429 "Provide Referred Identity" responds
SIP_UA_3892_V_008Ensure that the IUT, when it is Referee, it SHOULD NOT reject a REFER request that contains a Referred-By token encrypted a key it cannot decrypt it
SIP_UA_3892_V_009Ensure that the IUT, when it is Referee, it should present the same identity to the referrer and the refer target
SIP_UA_3892_V_010Ensure that the IUT, when it is Refer Target, if it receives INVITE without Referred-By header, it should proceed like normal call as RFC3261
SIP_UA_3892_V_011Ensure that the IUT, when it is Refer Target, if it receives INVITE with Referred-By header, it May reject a request if no Referred-By token is present using 429 "Provide Referrer Identity"
SIP_UA_3892_V_012Ensure that the IUT, when it is Refer Target, if it receives INVITE with Referred-By header but no Referred-By token, it May proceed with processing the request
SIP_UA_3892_V_013Ensure that the IUT, when it is Refer Target, if it receives INVITE with Referred-By header with an invalid Referred-By token, it MUST reject a request using 429 "Provide Referrer Identity
SIP_UA_3892_V_014Ensure that the IUT, when it form Referred-By Header and the token, the double quotes surrounding the sip-clean-msg-id MUST be replaced with left and right angle brackets in Content-ID
SIP_UA_3892_V_015Ensure that the IUT, when it form Referred-By header, if the referrer-uri contains a comma, question mark, or semicolon, the URI MUST be enclosed in angle brackets (<>) formulate one or more new requests
SIP_UA_3892_V_016Ensure that the IUT, can optionally put Referred-By Header in following methods: BYE, INVITE, OPTION, REGRISTAR and should NOT bind it in ACK and CANCEL
SIP_UA_3892_V_017Ensure that the IUT, when it contains Referred-By Token, the body part MUST be identified with a MIME Content-ID: field
SIP_UA_3892_V_018Ensure that the IUT, when it send Referred-By Token to refer target, the sipfrag MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request
SIP_UA_3892_V_019Ensure that the IUT, when it constructs the Referred-By token, it SHOULD NOT contain the Call-ID header and From header field from the REFER and other useful information that send to refer target
SIP_UA_3892_V_020Ensure that the IUT, when it constructs the Referred-By token, it SHOULD NOT contain the To header field from the REFER that send to refer target unless the referrer has cryptographically identified the referee
SIP_UA_3892_V_021Ensure that the IUT, when it receives invalid signature for Referred-By token, it must treat it as invalid token
SIP_UA_3892_V_022Ensure that the IUT, when it receives an aged Date header field value, it should treat a Referred-By token as invalid
SIP_UA_3892_V_023Ensure that the IUT, when the token contains a To header, it SHOULD verify that the identity it expresses matches the referrer
SIP_UA_3892_V_024Ensure that the IUT, when it is refer target and indicate that the referee must provide a valid Referred-By token, it SHOULD send 429 with text phrase "Provide Referrer Identity"
SIP_Extensions/
Refer_By_Compliance_Test_Plan/
SIP_UA_3892_I
SIP_UA_3892_I_001Ensure that the IUT, when it receives more than one Referred-by header field value it should sends back 48????
SIP_UA_3892_I_002Ensure that the IUT, when it receives Referred-By Header and the token, the double quotes surrounding the sip-clean-msg-id is same as in Content-ID but in double quotes as well, it should treat it as Invalid Token and sends 429 back
SIP_UA_3892_I_003Ensure that the IUT, when it receives ACK or CANCEL method with Referred-By Header it should just simply ignores the header
SIP_UA_3892_I_004Ensure that the IUT, when it receives the Referred-By token, which contains the Call-ID header and From header field from the REFER or/and other useful information, it should simply ignore it
SIP_Extensions/
SIP_MWI_Compliance_Test_Plan
SIP_Extensions/
SIP_MWI_Compliance_Test_Plan/
SIP_UA_3842_HV
SIP_UA_3842_HV_001Ensure that the IUT, when it binds SUBSCRIBE for the MWI, it should have header Event with package message-summary
SIP_UA_3842_HV_002Ensure that the IUT, when it constructs NOTIFY for the MWI, it should have header Event with package message-summary
SIP_UA_3842_HV_003Ensure that the IUT, it MAY construct REGISTER with Contact header with actor="msg-taker" and events="message-summary"
SIP_UA_3842_HV_004Ensure that the IUT, when it constructs SUBSCRIBE for the MWI, it should have header Accept header with application/Simple-message-summary
SIP_UA_3842_HV_005Ensure that the IUT, when it constructs NOTIFY for the MWI, it should have header field Content-Type with application/Simple-message-summary
SIP_UA_3842_HV_006Ensure that the IUT, when it constructs NOTIFY for alias or group, it MAY add bodies message with typical headers: To, From, Subject, Date, Message-ID and Priority, but NOT limited to these
SIP_UA_3842_HV_007Ensure that the IUT, when constructs body message for the application/simple-message-summary, it should start with msg-status-line with "Messages-Waiting" and msg-status = "yes" or "no"
SIP_UA_3842_HV_008Ensure that the IUT, when constructs body message for the application/simple-message-summary, it should have "Message-Account" with Account-URI set to SIP-URI/SIPS-UR/obsoluteURI
SIP_UA_3842_HV_009Ensure that the IUT, when constructs body message for the application/simple-message-summary, it should have msg-summary-line with newmsgs/oldmsgs and optionally follow by (new-urgentmsgs/old-urgentmsgs)
SIP_Extensions/
SIP_MWI_Compliance_Test_Plan/
SIP_UA_3842_V
SIP_UA_3842_V_001Ensure that the IUT set the subscription Duration for MWI from minutes to weeks, Days are recommended
SIP_UA_3842_V_002Ensure that the IUT when constructs NOTIFY Bodies for MWI, it uses message-context-class to separate messages, e.g voice-message, fax-message, pager-message, text-message, multimedia-message and none
SIP_UA_3842_V_003Ensure that the IUT when constructs NOTIFY Bodies for MWI, under the message-context-class header, it should have the new and old fields and optionally has urgent and non-urgent type
SIP_UA_3842_V_004Ensure that the IUT, can also send message waiting use the "message-summary" package in the NOTIFY with Messages-Waiting: header field
SIP_UA_3842_V_005Ensure that the IUT, when it has Request-URI in a message-summary subscription, it MUST specify the account using Message-Account: with correct URI. The URI MUST NOT be delimited with angle brackets
SIP_UA_3842_V_006Ensure that the IUT, when it sends MWI notification out, Message headers MUST NOT be included in the initial NOTIFY, it MUST in the subsequent NOTIFYs after the initial Subscription
SIP_UA_3842_V_007Ensure that the IUT, if it sends message headers in a NOTIFY, it MUST provide an administrator configurable mechanism to select which headers to send
SIP_UA_3842_V_008Ensure that the IUT, when it wants to MWI notification, it MUST send SUBSCRIBE to subscribe the message summary information for a period of hours or days
SIP_UA_3842_V_009Ensure that the IUT, when it wants to MWI notification, it SHOULD automatically attempt to re-SUBSCRIBE to subscribe the message summary information before the subscription is completely expired
SIP_UA_3842_V_010Ensure that the IUT, when its subscription is expired, a NEW re-subscription MUST use a new Call-ID
SIP_UA_3842_V_011Ensure that the IUT, it SHOULD SUBSCRIBE to that users message summaries whenever a new user becomes associated with the device
SIP_UA_3842_V_012Ensure that the IUT, SHOULD renew its subscription immediately after a reboot or network connectivity being re-established
SIP_UA_3842_V_013Ensure that the IUT, after it sends SUBSCRIBE due to new SUBSCRIBE, renewal or unsubscribe etc., it MUST be prepared to receive and process a NOTIFY immediately
SIP_UA_3842_V_014Ensure that the IUT, when it de-registers, it SHOULD send SUBSCRIBE with Expires header set to 0 to unsubscribe for the message summaries
SIP_UA_3842_V_015Ensure that the IUT, as a notifier, it MUST send a NOTIFY with the current message summary information right after a subscription is accepted
SIP_UA_3842_V_016Ensure that the IUT, as a notifier, it MUST send a NOTIFY with the current message summary information when the status of the messages changed
SIP_UA_3842_V_017Ensure that the IUT, as a notifier, it SHOULD send a NOTIFY with Expires header set to 0 and Subscription-State with terminated before a graceful shutdown
SIP_UA_3842_V_018Ensure that the IUT, when it receives NOTIFY for the subscriptions it has correctly, it should tell the end user MWI status correctly, e.g. LED light, icons, text, number of new messages etc as well as the message flow
SIP_UA_3842_V_019Ensure that the IUT, when it receives NOTIFY for the subscriptions it has correctly, it should tell the end user MWI status correctly, e.g. LED light, icons, text, number of new messages etc
SIP_UA_3842_V_020Ensure that the IUT, when it act as notifier, it SHOULD NOT generate NOTIFY request more frequently than once per second regardless the change rate of status of the message
SIP_UA_3842_V_021Ensure that the IUT, when it REGISTER and SUBSCRIB to notifier, and receive NOTIFY for new messages, check the call flow
SIP_UA_3842_V_022Ensure that the IUT, when it REGISTER and SUBSCRIB to notifier, and receive NOTIFY for no more new messages, check the call flow
SIP_UA_3842_V_023Ensure that the IUT, when it REGISTER and SUBSCRIB to notifier, and receive NOTIFY for retrieves some new messages but not all, check the call flow
SIP_UA_3842_V_024Ensure that the IUT, when it as notifier, and subscriber has new voice message, it MUST send out NOTIFY, check the call flow
SIP_UA_3842_V_025Ensure that the IUT, when it as notifier, and subscriber has retrieved all the new voice messages, it MUST send out NOTIFY, check the call flow
SIP_UA_3842_V_026Ensure that the IUT, when it as notifier, and subscriber has retrieves some but not all new voice messages, it MUST send out NOTIFY, check the call flow
SIP_UA_3842_V_027Ensure that the IUT, when it as notifier, and subscriber dial into voice mail system but not retrieves any new voice mail messages, it MUST NOT send out NOTIFY, check the call flow
SIP_Extensions/
SIP_MWI_Compliance_Test_Plan/
SIP_UA_3842_I
SIP_UA_3842_I_001Ensure that the IUT, when it receives SUBSCRIBE with header Event with value "Message-Summary", it SHOULD still proceed correctly
SIP_UA_3842_I_002_UN_aEnsure that the IUT, when it receives NOTIFY with header Event with value "Message-Summary",content-type: application/simple-message-summary
SIP_UA_3842_I_002_UN_bEnsure that the IUT, when it receives NOTIFY with header Event with value "Message-Summary", content-type with text/plain
SIP_UA_3842_I_002_UNEnsure that the IUT, when it receives NOTIFY with header Event with value "Message-Summary", it SHOULD still proceed correctly.
SIP_UA_3842_I_003_UNEnsure that the IUT, when it receives a NOTIFY "MESSAGES-Waiting" with msg-status = "yes" or "no", it SHOULD still proceed correctly
SIP_UA_3842_I_004_UNEnsure that the IUT, when it receives a NOTIFY with "MESSAGES-Waiting" with msg-status = "YES" or "NO", it SHOULD still Proceed
SIP_UA_3842_I_005_UNEnsure that the IUT, when it receives a NOTIFY with "MESSAGES-Waiting" with msg-status = " YES" or " NO", it SHOULD still Proceed
SIP_UA_3842_I_006_UNEnsure that the IUT, when it receives NOTIFY "Message-Account" with unsupported URL (e.g. http), it SHOULD return 400
SIP_UA_3842_I_007_UNEnsure that the IUT, when it receives NOTIFY with "MESSAGES-Account" with Account-URI set to SIP-URI/SIPS-UR/obsoluteURI, it SHOULD still proceed correctly
SIP_UA_3842_I_008_UNEnsure that the IUT, when it receives NOTIFY with body message with msg-summary-line only has one number, it SHOULD return 400.
SIP_UA_3842_I_009_UNEnsure that the IUT, when it receives NOTIFY with body message with msg-summary-line only has one priority number, it SHOULD return 400.
SIP_UA_3842_I_010_UNEnsure that the IUT, when it receives NOTIFY with body message with but header field Content-Type is not application/simple-message-summary, it SHOULD return 400.
SIP_UA_3842_I_010_UN_aEnsure that the IUT, when it receives NOTIFY with body message with but header field Content-Type is not application/simple-message-summary, it SHOULD return 400.
SIP_UA_3842_I_011_UNEnsure that the IUT, when it receives NOTIFY with body message with message-summary but header field Event is not message-summary, it SHOULD return 400.
SIP_UA_3842_I_012_UNEnsure that the IUT, when it receives NOTIFY with body message with Message-Account is NOT for the user, it SHOULD return 4XX
SIP_UA_3842_I_012_UN_aEnsure that the IUT, when it receives NOTIFY with body message with Message-Account is NOT for the user, it SHOULD return 4XX
SIP_UA_3842_I_013_UNEnsure that the IUT, when it receives NOTIFY but NOTIFY/mwi is not allowed, it SHOULD return 403
SIP_UA_3842_I_014_UNEnsure that the IUT, when it receives NOTIFY with body message with extra lines after msg-summary-line, it should treat it as extension-header if it does NOT understand, and it SHOULD proceed correctly
SIP_UA_3842_I_015_UNEnsure that the IUT, when it receives NOTIFY with body message with Message-Account is NOT for it self, should proceed correctly
SIP_UA_3842_I_016_UNEnsure that the IUT, when it receives NOTIFY with body message with extra lines after msg-summary-line for two accounts, it should treat it as extension-header if it does NOT understand, and it SHOULD proceed correctly
SIP_UA_3842_I_002Ensure that the IUT, when it receives NOTIFY with header Event with value "Message-Summary", it SHOULD still proceed correctly
SIP_UA_3842_I_003Ensure that the IUT, when it receives a NOTIFY "MESSAGES-Waiting" with msg-status = "YES" or "NO", it SHOULD still proceed correctly
SIP_UA_3842_I_004Ensure that the IUT, when it receives a NOTIFY with "MESSAGES-Waiting" with msg-status = " YES" or " NO", it SHOULD return 400
SIP_UA_3842_I_005Ensure that the IUT, when it receives NOTIFY "Message-Account" with unsupported URL (e.g. http), it SHOULD return 400
SIP_UA_3842_I_006Ensure that the IUT, when it receives NOTIFY with "MESSAGES-Account" with Account-URI set to SIP-URI/SIPS-UR/obsoluteURI, it SHOULD still proceed correctly
SIP_UA_3842_I_007Ensure that the IUT, when it receives NOTIFY with body message with msg-summary-line only has one number, it SHOULD return 400
SIP_UA_3842_I_008Ensure that the IUT, when it receives NOTIFY with body message with msg-summary-line only has one priority number, it SHOULD return 400
SIP_UA_3842_I_009Ensure that the IUT, when it receives NOTIFY with body message with but header field Content-Type is not application/simple-message-summary, it SHOULD return 400
SIP_UA_3842_I_010Ensure that the IUT, when it receives NOTIFY with body message with message-summary but header field Event is not message-summary, it SHOULD return 400
SIP_UA_3842_I_011Ensure that the IUT, when it receives NOTIFY with body message with Message-Account is NOT for the user, it SHOULD return 4XX
SIP_UA_3842_I_012Ensure that the IUT, when it receives NOTIFY with body message with extra lines after msg-summary-line, it should treat it as extension-header if it does NOT understand, and it SHOULD proceed correctly
SIP_Extensions/
Refer_Compliance_Test_Plan
SIP_Extensions/
Refer_Compliance_Test_Plan/
SIP_UA_3515_HV
SIP_UA_3515_HV_001Ensure that the IUT, when it sends REFER method, it MUST contain a single Contact header field value
SIP_UA_3515_HV_002Ensure that the IUT, when it does REFER inside an existing dialog, it MUST follow the Route/Record-Route logic of that dialog
SIP_UA_3515_HV_003Ensure that the IUT, when it does REFER inside an existing dialog, it MUST have a correct To tag in REFER
SIP_UA_3515_HV_004Ensure that the IUT, when it does REFER outside an existing dialog, it MUST have No To tag in REFER
SIP_UA_3515_HV_005Ensure that the IUT, when it generates REFER request, it binds Refer-To header in, Refer-To provides a URL to reference. Make sure the URL in Refer-To is correct
SIP_UA_3515_HV_006Ensure that the IUT, only sends Refer-To header in REFER methods and Not any other methods
SIP_UA_3515_HV_007Ensure that the IUT, when it responds 2XX to REFER it should NOT have Accept header in 2XX
SIP_UA_3515_HV_008Ensure that the IUT, when it responds 2XX to REFER it should NOT have Accept-Encoding header in 2XX
SIP_UA_3515_HV_009Ensure that the IUT, when it responds 2XX to REFER it should NOT have Accept-Language header in 2XX
SIP_UA_3515_HV_010Ensure that the IUT, when it responds 405 to REFER it MUST have Allow header in 405
SIP_UA_3515_HV_011Ensure that the IUT, when it responds to REFER it MUST copy the Call-ID into the Respond
SIP_UA_3515_HV_012Ensure that the IUT, when it sends REFER Request, it MUST have Contact header in REFER Request
SIP_UA_3515_HV_013Ensure that the IUT, when it responds 1XX to REFER it should NOT have Contact header in 1XX
SIP_UA_3515_HV_014Ensure that the IUT, when it sends 2XX to respond REFER Request, it MUST have Contact header in 2XX
SIP_UA_3515_HV_015Ensure that the IUT, when it responds to REFER it MUST copy the CSeq header field into the Respond with value REFER
SIP_UA_3515_HV_016Ensure that the IUT, when it responds to REFER it MUST copy the From header field into the Respond
SIP_UA_3515_HV_017Ensure that the IUT, when it responds to REFER it MUST copy the To header field into the Respond
SIP_UA_3515_HV_018Ensure that the IUT, when it responds to REFER it MUST copy the Via header field into the Respond
SIP_UA_3515_HV_019Ensure that the IUT, when it sends REFER Request it MUST have Max-Forwards header field in REFER
SIP_UA_3515_HV_020Ensure that the IUT, when it sends REFER Request it MUST NOT have Priority header field in REFER
SIP_UA_3515_HV_021Ensure that the IUT, when it responds 407 to REFER it MUST have header Proxy-Authenticate header field in the Respond
SIP_UA_3515_HV_022Ensure that the IUT, when it sends REFER Request it MUST NOT have Subject header field in the REFER
SIP_UA_3515_HV_023Ensure that the IUT, when it responds 401 to REFER it MUST have a WWW-Authenticate header field in the Respond
SIP_UA_3515_HV_024Ensure that the IUT, when it receives REFER Request and responds NOTIFY it SHOULD have the duration states in the Subscription-State parameter expires set correctly
SIP_Extensions/
Refer_Compliance_Test_Plan/
SIP_UA_3515_V
SIP_UA_3515_V_001Ensure that the IUT, when it is constructed a REFER request, it must contain exactly one Refer-To header
SIP_UA_3515_V_002Ensure that the IUT, when it receives well-formed REFER, it MUST contact the resource identified by the URI in the Refer-To header
SIP_UA_3515_V_003Ensure that the IUT, when it receives REFER, it may return 100 or any appropriate 4XX-6XX class response per RFC3261
SIP_UA_3515_V_004Ensure that the IUT, when it receives well-formed REFER, it MUST return a 2XX Accepted response before the REFER transaction expires. It Must create a subscription and send notifications of the status of the refer to the Referee
SIP_UA_3515_V_005Ensure that the IUT, when it accepts REFER, it must use NOTIFY mechanism to inform the agent sending the REFER of the status. The dialog identifiers (To, From, and Call-ID) of each NOTIFY MUST match those of the REFER as they would if the REFER had been a SUBSCRIBE request
SIP_UA_3515_V_006Ensure that the IUT, when it sends REFER, it must be prepared to use NOTIFY mechanism to inform the agent sending the REFER of the status. The creation of a subscription always results in an immediate NOTIFY, it must be prepared to receive a NOTIFY before the REFER transaction completes
SIP_UA_3515_V_007Ensure that the IUT, when it receives REFER and sends NOTIFY for the REFER status, each NOTIFY MUST contain an Event header field with a value of refer and possibly an id parameter
SIP_UA_3515_V_008Ensure that the IUT, when it receives REFER and sends NOTIFY for the REFER status, each NOTIFY MUST contain an Event header field with a value of refer and an id parameter for Multiple REFER Request in a Dialog. The id parameter is same as the sequence number of CSeq
SIP_UA_3515_V_009Ensure that the IUT, when it sends REFER and sends SUBSCRIBE to refresh or terminate the subscription for the REFER status, it MUST contain an Event header field with a value of refer and an id parameter for Multiple REFER Request in a Dialog. The id parameter is same as the sequence number of CSeq
SIP_UA_3515_V_010Ensure that the IUT, when it receives REFER Request and receives SUBSCRIBE to refresh or terminate the subscription for the REFER status, with Event header field with a value of refer and an id parameter it should treat the subscription correctly. If id parameter not matched CSeq value, 481 SHOULD return
SIP_UA_3515_V_011Ensure that the IUT, when it receives REFER and sends NOTIFY for the REFER status, each NOTIFY MUST contain a body of type "message/sipfrag"
SIP_UA_3515_V_012Ensure that the IUT, when it send Referred-By Token, the sipfrag MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request
SIP_UA_3515_V_013Ensure that the IUT, when it acting on a REFER request, it should NOT issue a CANCEL to any referenced SIP requests if it receiving REFER terminated its subscription to the refer event before the referenced request completes
SIP_UA_3515_V_014Ensure that the IUT, when it needs to extend its subscription, it may use refresh subscription mechanisms
SIP_UA_3515_V_015Ensure that the IUT, when it receives SUBSCRIBE request for event refer that does not already exist, it MUST reject it with a 403
SIP_UA_3515_V_016Ensure that the IUT, when it accepts REFER and not wishing to hold subscription state, it can terminate the subscription with the initial NOTITY
SIP_UA_3515_V_017Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY MUST begin with a SIP response Status-Line
SIP_UA_3515_V_018Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY MUST contain SIP/2.0 100 Trying if the subscription is pending
SIP_UA_3515_V_019Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY MUST contain SIP/2.0 200 OK if the reference was successful
SIP_UA_3515_V_020Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY MUST contain SIP/2.0 503 Service Unavailable if the reference failed
SIP_UA_3515_V_021Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY MUST contain SIP/2.0 603 Declined if the REFER request was accepted before approval to follow the reference could be obtained and that approval was subsequently denied
SIP_UA_3515_V_022Ensure that the IUT, when it receives REFER and sends NOTIFY, the body of a NOTIFY COULD contain warning header field values received in responds to the referred action
SIP_UA_3515_V_023Ensure that the IUT, when it receives REFER with Refer-To is a non-SIP URI, it sends NOTIFY MUST begin with a SIP response Status-Line
SIP_UA_3515_V_024Ensure that the IUT, when it receives REFER and sends NOTIFY, the NOTIFY MUST contain a Subscription-State header field with the correct state value
SIP_UA_3515_V_025Ensure that the IUT, when it receives REFER and sends NOTIFY, the final NOTIFY MUST contain a Subscription-State header field equals "terminated" with a reason of "noresource"
SIP_UA_3515_V_026Ensure that the IUT, when it receives REFER and sends NOTIFY, the final NOTIFY with subscription Duration in expires, the subscription SHOULD NOT expires before the timer expires unless it willing to terminate
SIP_Extensions/
Refer_Compliance_Test_Plan/
SIP_UA_3515_I
SIP_UA_3515_I_001Ensure that the IUT, when it receives REFER with zero Refer-To header, it should return a 400 (Bad Request)
SIP_UA_3515_I_002Ensure that the IUT, when it receives REFER with two Refer-To headers, it should return a 400 (Bad Request)
SIP_UA_3515_I_003Ensure that the IUT, when it receives REFER with non-SIP URIs, e.g. Refer-To: http://www.valid8.com, it should return 4XX to deny the request
SIP_UA_3515_I_004Ensure that the IUT, when it sends REFER Request and receives NOTIFY for the REFER status which contains an Event header field with a value not equal to refer and an id parameter, it should respond 4XX
SIP_UA_3515_I_005Ensure that the IUT, when it sends REFER Request and receives NOTIFY for the REFER status, without Event header field, it should respond 4XX message
SIP_UA_3515_I_006Ensure that the IUT, when it sends REFER and receives NOTIFY for the REFER status without "message/sipfrag" in body message, it should respond 403
SIP_UA_3515_I_007Ensure that the IUT, when it receives Referred-By Token in INVITE, the sipfrag does NOT contain copies of the Refer-To, Referred-By, and Date header fields, it should responds 403
SIP_UA_3515_I_008Ensure that the IUT, when it sends REFER, and if it receives NOTIFY that terminate the subscription, it should be notified the REFER subscription is expires
SIP_UA_3515_I_009Ensure that the IUT, when it sends REFER Request and receives NOTIFY which the body of a NOTIFY not begin with a SIP response Status-Line, it should respond 4XX
SIP_Extensions/
Message_SipFrag_Compliance_Test_Plan
SIP_Extensions/
Message_SipFrag_Compliance_Test_Plan/
SIP_UA_3420_HV
SIP_UA_3420_HV_001Ensure that the IUT, when it constructs message/sipfrag, it MAY only contain valid start-line per RFC3261
SIP_UA_3420_HV_002Ensure that the IUT, when it constructs message/sipfrag, it MAY only contain one or more entire header fields per RFC3261
SIP_UA_3420_HV_003Ensure that the IUT, when it constructs message/sipfrag, if it contain the message-body, it MUST also contain the appropriate header fields for the body and the null-line separating the header from the body
SIP_UA_3420_HV_004Ensure that the IUT, when it constructs message/sipfrag, it MAY contain the start-line, message-header and the message-body
SIP_UA_3420_HV_005Ensure that the IUT, when it constructs message/sipfrag, it MAY optional construct version parameter in with the version of the SIP protocol
SIP_UA_3420_HV_006Ensure that the IUT, when it receives message/sipfrag body without optional version parameter, it SHOULD assume it is version 2.0
SIP_Extensions/
Message_SipFrag_Compliance_Test_Plan/
SIP_UA_3420_I
SIP_UA_3420_I_001Ensure that the IUT, when it receives message/sipfrag, and with body message start with start-line of SIP/2.0, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_002Ensure that the IUT, when it receives message/sipfrag, and with body message start with start-line of INVITE, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_003Ensure that the IUT, when it receives message/sipfrag, and with body message start with invalid header Call-ID, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_004Ensure that the IUT, when it receives message/sipfrag, and with body message start with invalid header From, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_005Ensure that the IUT, when it receives message/sipfrag, and with body message start with body but no headers, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_006Ensure that the IUT, when it receives message/sipfrag, and with body message start with valid header fields and body but no null line in between, it SHOULD consider this is invalid message/sipfrag parts
SIP_UA_3420_I_007Ensure that the IUT, when it receives message/sipfrag body with optional version parameter which is not valid, it SHOULD assume it is version 2.0
SIP_Extensions/
Presence_Compliance_Tests
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Information_Data_Compliance_Test
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Information_Data_Compliance_Test/
SIP_UA_3863_HV
SIP_UA_3863_HV_001Ensure that the IUT, when it constructs XML-encoded Presence Data Format, it MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration,
SIP_UA_3863_HV_002Ensure that the IUT, it can use other parameter other than charset (encoding=`UTF-8`) if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_HV_003Ensure that the IUT, when it constructs PIDF, it SHOULD associate with XML namespace name `urn:ietf:params:xml:ns:pidf` by default
SIP_UA_3863_HV_004Ensure that the IUT, when constructs PIDF, the root of an "application/pidf+xml" object is a element associated with the presence information name space
SIP_UA_3863_HV_005Ensure that the IUT, when it constructs element of the PIDF, it MUST have `entity` attribute in element with value set to pres URL
SIP_UA_3863_HV_006Ensure that the IUT, when it constructs element of the PIDF, it MUST contain a namespace declaration `xmlns` which is set to `urn:ietf:params:xml:ns:pidf:`
SIP_UA_3863_HV_007Ensure that the IUT, when it constructs element, it MAY contain any number of elements, followed by any number of elements, followed by any number of OPTIONAL extension from other namespace
SIP_UA_3863_HV_008Ensure that the IUT, when constructs element, it MUST contain element
SIP_UA_3863_HV_009Ensure that the IUT, when constructs element, it MUST contain element followed by any number of OPTIONAL extension elements
SIP_UA_3863_HV_010Ensure that the IUT, when constructs element, it MUST contain element followed by any number of OPTIONAL extention elements, followed by OPTIONAL element
SIP_UA_3863_HV_011Ensure that the IUT, when constructs element, it MUST contain element followed by any number of OPTIONAL extention elements, followed by OPTIONAL element, followed by any number of OPTIONAL elements
SIP_UA_3863_HV_012Ensure that the IUT, when constructs element, it MUST contain element followed by any number of OPTIONAL extention elements, followed by OPTIONAL element, followed by any number of OPTIONAL elements, followed by an OPTIONAL element
SIP_UA_3863_HV_013Ensure that the IUT, when constructs element, it MUST contain id attribute which is used to distinguish this tuple from other tuples in the same PRESENTITY, and the value MUST be unique (arbitrary string) within `id` attribute values of other tuples for the same PRESENTITY
SIP_UA_3863_HV_014Ensure that the IUT, when constructs element, it MAY contain one OPTIONAL element, followed by any number of OPTIONAL extension elements, but at least one child element appears in either element or extension element
SIP_UA_3863_HV_015Ensure that the IUT, when it constructs truple that contain a element, it SHOULD also contain a address
SIP_UA_3863_HV_016Ensure that the IUT, when constructs element has element which has element, the element COULD have either value “open" or “closed"
SIP_UA_3863_HV_017Ensure that the IUT, when it is Watcher, it should extract the information from PIDF and by comparing the tuple with same id with the and element if any
SIP_UA_3863_HV_018Ensure that the IUT, when constructs element has element which has element, it should set the element to “open" when the INSTANT INBOX which associated is ready to accept an INSTANT MESSAGE
SIP_UA_3863_HV_019Ensure that the IUT, when constructs element has element which has element, it should set the element to “closed" when the INSTANT INBOX which associated is unable to accept an INSTANT MESSAGE
SIP_UA_3863_HV_020Ensure that the IUT, when constructs element, it SHOULD contain a URL of the contact address and optionally can has a `priority` attribute
SIP_UA_3863_HV_021Ensure that the IUT, when constructs element has element which has element, it should set the element to “open" when the INSTANT INBOX which associated is ready to accept an INSTANT MESSAGE
SIP_UA_3863_HV_022Ensure that the IUT, when constructs element has element which has element, it should set the element to “closed" when the INSTANT INBOX which associated is unable to accept an INSTANT MESSAGE
SIP_UA_3863_HV_023Ensure that the IUT, when constructs element, it SHOULD contain a URL of the contact address and optionally can has a ‘priority’ attribute
SIP_UA_3863_HV_024Ensure that the IUT, when constructs element which has attribute ‘priority’, it MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point
SIP_UA_3863_HV_025Ensure that the IUT, when constructs element which has attribute `priority`, it MUST put the higher value to indicate higher priority, if it is not presented, it should be treated as lowest priority
SIP_UA_3863_HV_026Ensure that the IUT, when constructs element, it SHOULD contain a special attribute `xml:lang` to specify the language used in the contents of this element as defined
SIP_UA_3863_HV_027Ensure that the IUT, when constructs element, it SHOULD contain a string value which is human readable comment
SIP_UA_3863_HV_028Ensure that the IUT, when constructs element in the element, it represent the comment is about the PRESENTITY. When constructs element in element, it represents the comment is about the particular tuple
SIP_UA_3863_HV_029Ensure that the IUT, when constructs element, it MUST comply with the IMPP datetime format in RFC3339
SIP_UA_3863_HV_030Ensure that the IUT, when constructs element, if it contains ‘T’ or ‘Z’, it MUST use the capitalized forms
SIP_UA_3863_HV_031Ensure that the IUT, when constructs elements, it SHOULD include element with string value to indicate the date and time of the status change of this tuple unless the exact time of the status change cannot be determined
SIP_UA_3863_HV_032Ensure that the IUT, when constructs successive elements, it MUST NOT contain the same timestamp
SIP_UA_3863_HV_033Ensure that the IUT, when constructs extension namespace it SHOULD use element or attribute names are associated with a particular namespace by a namespace prefix as format …
SIP_UA_3863_HV_034Ensure that the IUT, when constructs a namespace with a namespace prefix, it MUST use xmlns attribute with value urn:ietf:params:xml:ns:pidf. It also can use for default XML namespace
SIP_UA_3863_HV_035Ensure that the IUT, when it receives PIDF which contains unrecognized name for any XML elements, it SHOULD ignore it
SIP_UA_3863_HV_036Ensure that the IUT, when it receives PIDF which contains recognized name but unrecognized content for any XML elements, it SHOULD ignore it
SIP_UA_3863_HV_037Ensure that the IUT, when constructs complex extension namespace it SHOULD add attribute mustUnderstand=`true` or mustUnderstand=`1` to indicate it is Mandatory to understand the information
SIP_UA_3863_HV_038Ensure that the IUT, when it receives complex extension namespace with attribute mustUnderstand=`true` or mustUnderstand=`1` to indicate it is Mandatory to understand the information, but has unrecognized element in block, it SHOULD ignore the entire element
SIP_UA_3863_HV_039Ensure that the IUT, when constructs attribute mustUnderstand for complex extension, it MUST put it in optional element element
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Information_Data_Compliance_Test/
SIP_UA_3863_V
SIP_UA_3863_V_001Ensure that the IUT, when it constructs presence information, it SHOULD use `charset` parameter, but others also can be used, e.g. iso characters
SIP_UA_3863_V_002Ensure that the IUT, when it constructs PIDF, it should have Content-Type header field set to `application/pidf+xml` presence information
SIP_UA_3863_V_003Ensure that the IUT, when it SHOULD have the PRESENTITY URL which specify the “pres" URL of the PRESENTITY in the content of the PIDF
SIP_UA_3863_V_004Ensure that the IUT, when it SHOULD have identifier to identify the tuple within the presence information for the PRESENCE TUPLES in the content of the PIDF
SIP_UA_3863_V_005Ensure that the IUT, when it SHOULD have status and/or extension status value in the content of the PIDF
SIP_UA_3863_V_006Ensure that the IUT, when it CAN optionally have communication address which is the contact address of the tuple in the content of the PIDF
SIP_UA_3863_V_007Ensure that the IUT, when it CAN optionally have relative priority to specify the priority of the communication address in the content of the PIDF
SIP_UA_3863_V_008Ensure that the IUT, when it CAN optionally have timestamp to specify the time of the change of the tuple in the content of the PIDF
SIP_UA_3863_V_009Ensure that the IUT, when it CAN optionally have human readable comment about the tuple in the content of the PIDF
SIP_UA_3863_V_010Ensure that the IUT, when it CAN optionally have human readable comment about the PRESENTITY in the content of the PIDF
SIP_UA_3863_V_011Ensure that the IUT, when it constructs PIDF, it SHOULD use XML-encoded with CPP compliant systems
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Information_Data_Compliance_Test/
SIP_UA_3863_I
SIP_UA_3863_I_001Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_002Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_003Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_004Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_005Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_006Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_007Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_008Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_009Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_010Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_011Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_012Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_013Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_014Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_015Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_016Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_017Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_UA_3863_I_018Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Event_Package
SIP_Extensions/
Presence_Compliance_Tests/
Presence_Event_Package/
SIP_UA_3856_I
SIP_UA_3856_I_000Ensure that the IUT, it can use other parameter other than charset (encoding="UTF-8") if it does support, but it MUST accept the UTF-8 character encoding as minimum requirement
SIP_Extensions/
Publish_Compliance_Tests
SIP_Extensions/
Publish_Compliance_Tests/
Publish_Compliance_Tests_HV
SIP_UA_3903_HV_001Ensure that the IUT, when it constructs outbound method, e.g. INVITE, it should put PUBLISH in Allow header if it does support receiving PUBLISH
SIP_UA_3903_HV_002Ensure that the IUT, when it constructs PUBLISH it MUST have Request-URI, and a single Event header
SIP_UA_3903_HV_003Ensure that the IUT, when it constructs 2xx final response for PUBLISH, it MUST have the SIP-Etag header
SIP_UA_3903_HV_003_aEnsure that the IUT, when it constructs 2xx final response for PUBLISH, it MUST have the SIP-Etag header
SIP_UA_3903_HV_003_bEnsure that the IUT, when it constructs 2xx final response for PUBLISH, it MUST have the SIP-Etag header
SIP_UA_3903_HV_004Ensure that the IUT, when it constructs initial PUBLISH, it MUST have NO SIP-If-Match header and has SDP body. It also MUST have Expires header with value greater than 0
SIP_UA_3903_HV_005Ensure that the IUT, when it constructs PUBLISH to modify or update event state, it MUST bind SIP-If-Match header in the PUBLISH and have an SDP body. It also MUST have Expires header with value greater than 0
SIP_UA_3903_HV_006Ensure that the IUT, when it constructs PUBLISH, it MUST have SIP-If-Match header and have NO SDP body. It also MUST have Expires header with value greater than 0
SIP_UA_3903_HV_007Ensure that the IUT, when it constructs PUBLISH to remove the publishing event state, it MUST have no SDP body and have SIP-If-Match header. It also MUST have expires header with value greater than 0
SIP_UA_3903_HV_008Ensure that the IUT, when it constructs PUBLISH Request it MAY contain Header: Accept, Accept-Encoding, Accept-Language, Allow, Allow-Events, Authorization, Call-Info, Content-Encoding, Content-Language, Expires, MIME-Version, Organization, Priority, Proxy-Authorization, Proxy-Require, Require, Subject, Supported, Timestamp, User-Agent.
SIP_UA_3903_HV_009Ensure that the IUT, when it constructs PUBLISH Request it MUST contain Headers: CSeq, Event, From, Max-Forwards, To, Via, Call-ID
SIP_UA_3903_HV_010Ensure that the IUT, when it constructs 2XX response to inbound PUBLISH, it MUST contain headers: Expires, From, To, Call-ID and MUST NOT contain headers: Accept, Accept-Encoding, Contact, Reply-To, Record-Route, and Optionally it MAY contain headers: Authentication-Info, Supported
SIP_UA_3903_HV_011Ensure that the IUT, when it constructs 2XX response to inbound PUBLISH, it MUST contain headers: Expires, From, To, Call-ID and MUST NOT contain headers: Accept, Accept-Encoding, Contact, Reply-To, Record-Route, and Optionally it MAY contain headers: Authentication-Info, Supported
SIP_UA_3903_HV_012Ensure that the IUT, when it constructs 415 to response PUBLISH, it MUST contain headers: Accept, Accept-Encoding and Optional header Error-Info
SIP_UA_3903_HV_013Ensure that the IUT, when it constructs 405 to response PUBLISH, it MUST contain header: Accept
SIP_UA_3903_HV_014Ensure that the IUT, when it constructs 489 to response PUBLISH, it MUST contain header: Allow-Events
SIP_UA_3903_HV_015Ensure that the IUT, when it constructs 485 to response PUBLISH, it MAY contain header: Contact
SIP_UA_3903_HV_016Ensure that the IUT, when it constructs 407 to response PUBLISH, it MUST contain header: Proxy-Authenticate and optional header WWW-Authenticate
SIP_UA_3903_HV_017Ensure that the IUT, when it constructs 401 to response PUBLISH, it MUST contain header: WWW-Authenticate and optional header Proxy-Authenticate
SIP_UA_3903_HV_018Ensure that the IUT, when it constructs 404 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_019Ensure that the IUT, when it constructs 413 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_020Ensure that the IUT, when it constructs 480 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_021Ensure that the IUT, when it constructs 486 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_022Ensure that the IUT, when it constructs 500 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_023Ensure that the IUT, when it constructs 503 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_024Ensure that the IUT, when it constructs 600 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_025Ensure that the IUT, when it constructs 603 to response PUBLISH, it MAY contain header: Retry-After
SIP_UA_3903_HV_026Ensure that the IUT, Binds SIP-ETag in 2XX response ONLY to response PUBLISH, but not any other methods
SIP_UA_3903_HV_027Ensure that the IUT, MAY bind SIP-If-Match header ONLY in PUBLISH Method but NOT any other methods
SIP_Extensions/
Publish_Compliance_Tests/
Publish_Compliance_Tests_V
SIP_UA_3903_V_001Ensure that the IUT, when it receives OPTIONS, it SHOULD put PUBLISH in Allow header to respond with Allow-Events header to indicate the supported even packages which using in PUBLISH method
SIP_UA_3903_V_002Ensure that the IUT, when it constructs PUBLISH method, it MAY include Route header field in outbound PUBLISH
SIP_UA_3903_V_003Ensure that the IUT, when it MUST NOT create a new route set based on the precense or abssences of a Record-Route header in any response to a PUBLISH request. (i.e. when ITU receives PUBLISH method with Record-Route header, it MUST ignore it)
SIP_UA_3903_V_004Ensure that the IUT, when it MAY contain a Contact header in outbound PUBLISH request
SIP_UA_3903_V_005Ensure that the IUT, when it receives PUBLISH with Contact header, it SHOULD ignore it and respond based on the Via header
SIP_UA_3903_V_006Ensure that the IUT, when it receives PUBLISH within an existing dialog, it should respond correctly or it could reject it
SIP_UA_3903_V_007Ensure that the IUT, when it MUST NOT send a new PUBLISH request for the same Request-URI, until they have received a final respond from ESC for the previous one
SIP_UA_3903_V_008Ensure that the IUT, when it MUST NOT send a new PUBLISH request for the same Request-URI, until the previous PUBLISH request has timed out
SIP_UA_3903_V_009Ensure that the IUT, ?????? this test is not documented
SIP_UA_3903_V_010Ensure that the IUT, when it creates an initial publication, it MUST create PUBLISH with SDP body, Expires header set to none zero, have single event header with event package, MUST have no SIP-If-Match value
SIP_UA_3903_V_011Ensure that the IUT, when it responds to the initial PUBLISH, it may lower the value in Expires header and set the value in the 2xx response. But it MUST NOT extend the value
SIP_UA_3903_V_012Ensure that the IUT, when it receives an unacceptable low value in the 2XX for the expiration time of the publication. It could use local policy and use the preset value as expiration time. *The minimum hardcoded time is set to 60s
SIP_UA_3903_V_013Ensure that the IUT, when it MUST responsible for refreshing event state if it is EPA, it MUST generate refresh PUBLISH before the life time expires
SIP_UA_3903_V_014Ensure that the IUT, when it do refresh PUBLISH, it MUST create a PUBLISH request that includes in a SIP-If-Match header with NO SDP body and Expires header
SIP_UA_3903_V_015Ensure that the IUT, when it do refresh PUBLISH, it MUST create a PUBLISH request that includes in a SIP-If-Match header with match to the entity-tag from previous 2XX respond, and when it receive new 2XX with entity-tag, it MUST store the new entity-tag value for next PUBLISH
SIP_UA_3903_V_016Ensure that the IUT, when it receives refresh PUBLISH, with a SIP-If-Match header not match stored entity-tag, it MUST respond with 412 (Conditional Request Failed)
SIP_UA_3903_V_017Ensure that the IUT, when it constructs PUBLISH, it may contain a single Expires header for initial, refresh, modify or remove publication
SIP_UA_3903_V_018Ensure that the IUT, when it receieves an initial PUBLISH without an Expires header it should treat is as normal and set Expires header in the respond 2XX
SIP_UA_3903_V_019Ensure that the IUT, when it constructs a modifying PUBLISH, it MUST include a SIP-If-Match header with entity-tag matches previously published event state at the ESC and with SDP body
SIP_UA_3903_V_020Ensure that the IUT, when it recieves a modifying PUBLISH, it MUST check the entity-tag in SIP-If-Match with the reported SIP-Etag. If they are matched, then respond 2XX with new SIP-Etag
SIP_UA_3903_V_021Ensure that the IUT, when it recieves a modifying PUBLISH, it MUST check the entity-tag in SIP-If-Match with the reported SIP-Etag. If they are NOT matched, then respond 412 Conditional Request failed
SIP_UA_3903_V_022Ensure that the IUT, when it constructs a modifying PUBLISH, it MAY include Expires header
SIP_UA_3903_V_023Ensure that the IUT, when it recieves a modifying PUBLISH without Expires header, it it should treat it as normal and put Expires header in 2XX response
SIP_UA_3903_V_024Ensure that the IUT, when it constructs a removal PUBLISH, it MUST set Expires to 0 and set the SIP-IF-Match header field to contain the entity-tag of the event state with NO SDP body
SIP_UA_3903_V_025Ensure that the IUT, when it receives 412 respond for its outbound PUBLISH, it MUST NOT reattempt the PUBLISH request. Instead it SHOULD prefrom a new initial publication (i.e. a PUBLISH request without a SIP-If-Match header field should send)
SIP_UA_3903_V_026Ensure that the IUT, when it receives 412 respond for its outbound PUBLISH, it MUST discard the entity-tag that produced this error response. (i.e. when it receives PUBLISH with that entity-tag after, it should respond 412)
SIP_UA_3903_V_027Ensure that the IUT, when it receives 423 respond for its outbound PUBLISH, it MUST discard the entity-tag that produced this error response. (i.e. when it receives PUBLISH with that entity-tag after, it should respond 412)
SIP_UA_3903_V_028Ensure that the IUT, when it receives a PUBLISH request, if it inspects the Request-URI is NOT targeted to a resource for which it is responsible for maintainning event state, it MUST return 404 Not Found and no doing anything further
SIP_UA_3903_V_029Ensure that the IUT, when it receives a PUBLISH request, and determines the Event header is missing, it MUST respond 489 Bad Event
SIP_UA_3903_V_030Ensure that the IUT, when it receives a PUBLISH request, and examins the Event header containing an evnt package does not support, it MUST respond 489 Bad Event
SIP_UA_3903_V_031Ensure that the IUT, when it receives a PUBLISH request with no SIP-If-Match header, it MUST genearte and store a locally unique entity-tag and respond 200 with the SIP-ETag
SIP_UA_3903_V_032Ensure that the IUT, when it receives a PUBLISH request with SIP-If-Match header with no entity-tag, it MUST return 400 Invalid Request and no doing anything further
SIP_UA_3903_V_033Ensure that the IUT, when it receives a PUBLISH request with SIP-If-Match header with two entity-tag (e.g. SIP-If-Match: tag1, tag2), it MUST return 400 Invalid Request and no doing anything further
SIP_UA_3903_V_034Ensure that the IUT, when it receives a PUBLISH request with SIP-If-Match header with one entity-tag but not match the locally stored entity-tag, it MUST return 412 Conditional Request Failed and no doing anything further
SIP_UA_3903_V_035Ensure that the IUT, when it receives a PUBLISH request with Expires header, it should check the value and return no greater than 2XX in the expires header
SIP_UA_3903_V_036Ensure that the IUT, when it receives a PUBLISH request without Expires header, it should return a preset value in 2XX in the expires header
SIP_UA_3903_V_037Ensure that the IUT, when it receives a PUBLISH request with Expires header, and the value is too small, it MUST return 423 Interval Too Brief with Min-Expires header states the minimu expiration interval
SIP_UA_3903_V_038Ensure that the IUT, when it receives a PUBLISH request with support Event package by the content type does not match or not understand, it MUST reject with 415 (Unsupported Media Type) and not doing anything furture
SIP_UA_3903_V_039Ensure that the IUT, when it receives a PUBLISH request with no message body and no entity-tag, it MUST reject it by sending 400 Invalid Request unless the local police allow initial PUBLISH containing no message body
SIP_UA_3903_V_040Ensure that the IUT, when it receives a PUBLISH request with Expires: 0, it SHOULD immediately remove the entity-tag. (ie. it receive the PUBLISH with entity-tag again, it should return 412)
SIP_UA_3903_V_041Ensure that the IUT, when it receives a PUBLISH request with Expires: 0, it SHOULD immediately remove the entity-tag and NOT store the SIP-ETag in the 2XX to respond the removal PUBLISH. (ie. it receive the PUBLISH with entity-tag again, it should return 412)
SIP_UA_3903_V_042Ensure that the IUT, when it receives a PUBLISH and respond 200, it MUST contain an Expires header as well as SIP-Etag header (This need to be check for initial, modify and removal PUBLISH)
SIP_UA_3903_V_043Ensure that the IUT, when it receives a PUBLISH and respond 200, it MUST contain a unique SIP-Etag header which different than the previous ones with that Request-URI. (This need to be check for initial, modify and removal PUBLISH)
SIP_UA_3903_V_044Ensure that the IUT, Should have a reasonable value for the default minimum expiration value and prefer is configurable. * Note: This is by inspection only
SIP_UA_3903_V_045Ensure that the IUT, when it response 503 to a inbound PUBLISH, it SHOULD contain a Retry-After header field indicating the time interval that the publication source is required to wait until sending another PUBLISH
SIP_UA_3903_V_046Ensure that the IUT, when it response 503 with Retry-After header for outbound PUBLISH, it SHOULD retry after the time interval indicate in the Retry-After header
SIP_UA_3903_V_047Ensure that the IUT, when PUBLISH use for presence event, content type MUST be MIME and event package must be presence when the PIDF format MUST be used. (i.e. check the Event header and content-type header)
SIP_UA_3903_V_048Ensure that the IUT, when it generate a 200 respond for PUBLISH with presence event, it MUST has no message body.
SIP_UA_3903_V_049Ensure that the IUT, when it does support Event state segmentation, the EPA MUST keep the "id" attributes of the tuples consistent in the context of an entity-tag. If A tuple whose "id" is missing it will consider it is being removed. *Not support Event State Segmentation.
SIP_Extensions/
Publish_Compliance_Tests/
Publish_Compliance_Tests_I
SIP_UA_3903_I_001Ensure that the IUT, when it receives a PUBLISH with SIP-If-Match tag (SIP-If-Match: whatever) and with Body Message, but could not find the match, it MUST return 412
SIP_UA_3903_I_002Ensure that the IUT, when it receives a PUBLISH with no SIP-If-Match and no message body with Expires value 0, it SHOULD either return 400 or return 200 with Expires: 0 and not create publication
SIP_UA_3903_I_003Ensure that the IUT, when it receives a PUBLISH with no SIP-If-Match but also NO body message (has no Expires header) it SHOULD return 400 Invalid Request
SIP_UA_3903_I_004Ensure that the IUT, when it receives a PUBLISH with no SIP-If-Message tag has Body Message with Expires: 0 it SHOULD return 200 with Expires: 0 and not create the publication
SIP_UA_3903_I_005Ensure that the IUT, when it receives a PUBLISH with SIP-If-Message tag has Body Message, with Expires: 0 it SHOULD return 200 with Expires: 0 and not create the publication
SIP_UA_3903_I_006Ensure that the IUT, when it receives a PUBLISH with two Event headers it MUST respond 489 Bad Event
SIP_UA_3903_I_006_bEnsure that the IUT, when it receives a PUBLISH with two Event headers it MUST respond 489 Bad Event
SIP_UA_3903_I_007Ensure that the IUT, when it receives a PUBLISH without Contact header, it SHOULD treat it as valid and respond based on a Via header
SIP_UA_3903_I_008Ensure that the IUT, when it receives a 200 response to PUBLISH without SIP-Etag, it SHOULD either send removal PUBLISH or simply delete the publication
SIP_UA_3903_I_009Ensure that the IUT, when it receives a 200 response to PUBLISH with SIP-Etag, but no value, it SHOULD either send removal PUBLISH or simply delete the publication
SIP_UA_3903_I_010Ensure that the IUT, when it receives a 200 response to PUBLISH with message body, it SHOULD be ignored as it does not receive
SIP_UA_3903_I_011Ensure that the IUT, when it receives a second PUBLISH with the same Request-URI before it responds to the first one, it SHOULD answer the first one, either ignores the second one or rejects it
SIP_Extensions/
Asserted_Identity_Compliance_Tests
SIP_Extensions/
Asserted_Identity_Compliance_Tests/
Asserted_Identity_Compliance_Tests_HV
SIP_UA_3325_HV_001Ensure that the IUT, when it constructs P-Asserted-Identity header in the outgoing message, it may have one or two P-Asserted-Identity values
SIP_UA_3325_HV_002Ensure that the IUT, when it constructs P-Asserted-Identity header it MUST consist of exactly one name-addr or addr-spec
SIP_UA_3325_HV_003Ensure that the IUT, when it constructs one P-Asserted-Identity headers in the message, the value MUST be sip or sips URI.
SIP_UA_3325_HV_004Ensure that the IUT, when it constructs two P-Asserted-Identity headers in the message, one value MUST be sip or sips URI and the other MUST be a tel URI.
SIP_UA_3325_HV_005Ensure that the IUT, when it constructs P-Preferred-Identity header in the outgoing message, it may have one or two P-Preferred-Identity values
SIP_UA_3325_HV_006Ensure that the IUT, when it constructs P-Preferred-Identity header, it MUST consist of exactly one name-addr or addr-spec
SIP_UA_3325_HV_007Ensure that the IUT, when it constructs one P-Preferred-Identity header in the message, the value MUST be sip or sips URI.
SIP_UA_3325_HV_008Ensure that the IUT, when it constructs two P-Preferred-Identity headers in the message, one value MUST be sip or sips URI and the other MUST be a tel URI
SIP_UA_3325_HV_009Ensure that the IUT, when it constructs privacy header, it MUST include all the requested privacy types in the privacy header, if the privacy is not enforced, privacy should set to none.
SIP_UA_3325_HV_009_aEnsure that the IUT, when it constructs privacy header, it MUST include all the requested privacy types in the privacy header, if the privacy is not enforced, it may leave out the privacy header.
SIP_UA_3325_HV_010Ensure that the IUT, when it constructs privacy header, it MUST include all the requested privacy types in its privacy header. If the privacy is enforced, privacy should set to id
SIP_UA_3325_HV_011Ensure that the IUT, when it constructs privacy header, it MUST include all the requested privacy types in its privacy header, if the privacy is enforced and critical, privacy should set to id;critical.
SIP_UA_3325_HV_012Ensure that the IUT, it MAY NOT include privacy header in the message if the user selects to not enforce privacy.
SIP_UA_3325_HV_013Ensure that the IUT, when it constructs privacy header, it MUST include all the requested privacy types in its privacy header, if the privacy is enforced and critical, privacy should set to id;critical. From header is anonymous
SIP_UA_3325_HV_014Ensure that the IUT, when it contstructs the P-Asserted-Identity header, it contains a URI and an optional display-name
SIP_Extensions/
Asserted_Identity_Compliance_Tests/
Asserted_Identity_Compliance_Tests_V
SIP_UA_3325_V_002Ensure that the IUT, when it receives an INVITE with P-Asserted-Identity header, SHOULD authenticate the originating user in some way, e.g. send 401 or 407 and get a correct respose
SIP_UA_3325_V_003Ensure that the IUT, when it receives an INVITE with P-Asserted-Identity header, it SHOULD authenticate the originating user by sending 401 or 407. If authentication is correct then IUT should insert the P-Asserted-Identitiy header and forward the message.
SIP_UA_3325_V_004Ensure that the IUT, when it receives an INVITE with a P-Asserted-Identity header, it should authenticate the originating user by sending 401 or 407. If authentication fails then IUT should remove the P-Asserted-Identity header and forward the message if it still needs to, or reject forwarding by returning a 403. Note: this is applicable for SIP-line sending INVITE only, so this is not supported in Unison
SIP_UA_3325_V_005Ensure that the IUT, when it wishes to request the removal of P-Asserted-Identity header fields, they should put header Privacy:id.
SIP_UA_3325_V_006Ensure that the IUT, when it receives an INVITE with P-Asserted-Identity, it should consider the identity provided in P-Asserted-Identity more trustworthy than the From header field of a request. If there is no privacy header, the P-Asserted-Identity information should be displayed
SIP_UA_3325_V_006aEnsure that the IUT, when it receives an UPDATE with P-Asserted-Identity, it should consider the identity provided in P-Asserted-Identity more trustworthy than the From header field of a request. If there is no privacy header, P-Asserted-Identity should be displayed. *Note: RFC3325 does not allow P-Asserted-Identity in an UPDATE*
SIP_UA_3325_V_007Ensure that the IUT, when it receives SUBSCRIBE/NOTIFY with P-Asserted-Identity, it should consider the identity provided in P-Asserted-Identity more trustworthy than the From header field of a request. If there is no privacy header, information from P-Asserted-Identity should be used. Note: Not supported in SUBSCRIBE/NOTIFY
SIP_UA_3325_V_008Ensure that the IUT, when it receives a REFER with a P-Asserted-Identity header, it should consider the identity provided in P-Asserted-Identity more trustworthy than the From header field of a request. If there is no privacy header, information from the P-Asserted-Identity should be displayed
SIP_UA_3325_V_009Ensure that the IUT, when it receives an INVITE with P-Asserted-Identity, it should consider the identity provided in P-Asserted-Identity more trustworthy than the From header field of a request. If privacy value is none, P-Asserted-Identity should be displayed
SIP_UA_3325_V_010Ensure that the IUT, when it receives an UPDATE with P-Asserted-Identity, it should consider the identity provided in P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is none, the information from the P-Asserted-Identity should be displayed. *Note: RFC3325 not allow P-Asserted-Identity in UPDATE.*
SIP_UA_3325_V_011Ensure that the IUT, when it receives SUBSCRIBE/NOTIFY with a P-Asserted-Identity header, it should consider the identity provided in P-Asserted-Identity header more trustworthy than the From header field of a request. If the privacy value is none, the P-Asserted-Identity information should be used
SIP_UA_3325_V_012Ensure that the IUT, when it receives a REFER with P-Asserted-Identity header, it should consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is none, the P-Asserted-Identity information should be displayed
SIP_UA_3325_V_013Ensure that the IUT, when it receives an INVITE with a P-Asserted-Identity header, it should consider the identity provided in P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id, information from the P-Asserted-Identity header should NOT be displayed
SIP_UA_3325_V_014Ensure that the IUT, when it receives an UPDATE with a P-Asserted-Identity header, it should consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id, the P-Asserted-Identity information should NOT be displayed.*Note: RFC3325 not allow P-Asserted-Identity in UPDATE.*
SIP_UA_3325_V_015Ensure that the IUT, when it receives a SUBSCRIBE/NOTIFY with a P-Asserted-Identity header, it should consider the identity provided in P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id, the P-Asserted-Identity information should NOT be used
SIP_UA_3325_V_016Ensure that the IUT, when it receives a REFER with a P-Asserted-Identity header, it should consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id, the P-Asserted-Identity information should NOT be displayed
SIP_UA_3325_V_017Ensure that the IUT, when it receives an INVITE with a P-Asserted-Identity header, it should consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id critical, the P-Asserted-Identity information should NOT be displayed if it supports, or 500 returns
SIP_UA_3325_V_018Ensure that the IUT, when it receives an UPDATE with a P-Asserted-Identity header, it SHOULD consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id;critical, the P-Asserted-Identity information should NOT be displayed if it supports it, or 500 returns. *Note: RFC3325 not allow P-Asserted-Identity in UPDATE.*
SIP_UA_3325_V_019Ensure that the IUT, when it receives SUBSCRIBE/NOTIFY with a P-Asserted-Identity header, it should consider the identity provided in the P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id critical, the P-Asserted-Identity information should NOT be used if it supports it, or it should return a 500 response
SIP_UA_3325_V_020Ensure that the IUT, when it receives a REFER with a P-Asserted-Identity header, it should consider the identity provided in P-Asserted-Identity header more trustworthy than the From header field of a request. If privacy value is id;critical, the P-Asserted-Identity information should NOT be displayed if it supports it, or a 500 response returned
SIP_UA_3325_V_022Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header, one RPID header and a Privacy value set to none, the information in the P-Asserted-Identity headers SHOULD be displayed rather than the RPID information
SIP_UA_3325_V_023Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity headers one RPID header, with Privacy value set to id, information in P-Asserted-Identity headers should NOT be displayed, NOR as RPID
SIP_UA_3325_V_024Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity headers, one P-Preferred-Identity, and one RPID header, with Privacy value set to none, information in P-Asserted-Identity headers should be displayed rather RPID
SIP_UA_3325_V_025Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity headers, one P-Preferred-Identity, and one RPID header, with Privacy value set to id, P-Asserted-Identity headers should be displayed as restricted rather RPID
SIP_UA_3325_V_026Ensure that the IUT, when it receives an INVITE with one P-Preferred-Identity headers and one RPID header, with Privacy value set to none, P-Preferred-Identity headers should be displayed rather RPID
SIP_UA_3325_V_027Ensure that the IUT, when it receives an INVITE with one P-Preferred-Identity headers and one RPID header, with Privacy value set to id, P-Preferred-Identity headers should NOT be displayed, NOR as RPID
SIP_UA_3325_V_028Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers (one SIP or SIPs URI, and one tel URI) and one RPID header, with Privacy value set to none, SIP/SIPs P-Asserted-Identity header should be displayed rather RPID
SIP_UA_3325_V_029Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers (one SIP or SIPs URI, and one tel URI), one RPID header and with the Privacy value set to id; the P-Asserted-Identity information or RPID headers should NOT be displayed
SIP_UA_3325_V_030Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers (one SIP or SIPs URI, and one tel URI), one P-Preferred-Identity, one RPID header and with the Privacy value set to none; the SIP/SIPs P-Asserted-Identity header information rather than the RPID information header SHOULD be displayed
SIP_UA_3325_V_031Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers (one SIP or SIPs URI, and one tel URI), one P-Preferred-Identity, one RPID header and with the Privacy value set to id; the P-Asserted-Identity nor the RPID information headers SHOULD be displayed
SIP_UA_3325_V_032Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header, two P-Preferred-Identity headers, one RPID header, with Privacy value set to none; the P-Asserted-Identity rather than the RPID or PPI information headers SHOULD be displayed
SIP_UA_3325_V_033Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header, two P-Preferred-Identity headers, one RPID header, and the Privacy value set to id; the P-Asserted-Identity headers rather than the RPID header information should be displayed
SIP_UA_3325_V_034Ensure that the IUT, when it receives a 18x response with one P-Asserted-Identity header, two P-Preferred-Identity headers, one RPID header and the Privacy header value set to id; it SHOULD display the P-Asserted-Identity headers should NOT be displayed, nor as RPID
SIP_UA_3325_V_035Ensure that the IUT, when it receives a 18x with P-Asserted-Identity header, P-Preferred-Identity header, and/or RPID header, with Privacy value set to id, Caller/called ID should reflect accordingly *Note:This is extented from RFC3325, which may have draft to address it"
SIP_UA_3325_V_036Ensure that the IUT, when it receives a 200 with P-Asserted-Identity header, P-Preferred-Identity header, and/or RPID header, with Privacy value set to none, Caller/called ID should reflect accordingly *Note:This is extented from RFC3325, which may have draft to address it"
SIP_UA_3325_V_037Ensure that the IUT, when it receives a 200 with P-Asserted-Identity header, P-Preferred-Identity header, and/or RPID header, with Privacy value set to id, Caller/called ID should reflect accordingly *Note:This is extented from RFC3325, which may have draft to address it"
SIP_Extensions/
Asserted_Identity_Compliance_Tests/
Asserted_Identity_Compliance_Tests_I
SIP_UA_3325_I_001Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy: id, (note: there are two spaces between : and id) it should NOT display P-Asserted-Identity
SIP_UA_3325_I_002Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:i d, it should proceed display P-Asserted-Idently correctly. (Privacy:i d value should be ignored.)
SIP_UA_3325_I_003Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:Id, it should proceed display P-Asserted-Idently correctly. (Privacy:Id value should be ignored.)
SIP_UA_3325_I_004Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:iD, it should proceed display P-Asserted-Idently correctly. (Privacy:iD value should be ignored.)
SIP_UA_3325_I_005Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:header, it should not display P-Asserted-Idently correctly. Privacy: header is treated as Privacy: id
SIP_UA_3325_I_006Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:session, it should display P-Asserted-Idently correctly
SIP_UA_3325_I_007Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:user, it should NOT reject this INVITE, and treat is as Privacy: id
SIP_UA_3325_I_008Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:critical, it should reject the INVITE
SIP_UA_3325_I_009Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacy:id<;whatever>, it should not display caller ID in P-Asserted-Identity
SIP_UA_3325_I_010Ensure that the IUT, when it receives an INVITE with one P-Asserted-Identity header with Privacyid;critical<;whatever>, it should NOT display caller ID in P-Asserted-Identity
SIP_UA_3325_I_012Ensure that the IUT, when it receives a UPDATE with one P-Asserted-Identity header with Privacy: id, (note: there are two spaces between : and id)it should NOT display P-Asserted-Identity
SIP_UA_3325_I_013Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:i d, it should proceed display P-Asserted-Idently correctly. (Privacty:i d should be ignored.)
SIP_UA_3325_I_014Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:header, it should proceed display P-Asserted-Idently correctly
SIP_UA_3325_I_015Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:session, it should display P-Asserted-Idently correctly
SIP_UA_3325_I_016Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:user, it should reject this UPDATE
SIP_UA_3325_I_017Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:critical, it should reject the UPDATE
SIP_UA_3325_I_019Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:id<;whatever>, it should NOT display caller ID in P-Asserted-Identity
SIP_UA_3325_I_021Ensure that the IUT, when it receives an UPDATE with one P-Asserted-Identity header with Privacy:id;critical<;whatever>, it should not display caller ID in P-Asserted-Identity
SIP_UA_3325_I_023Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers, both P-Asserted-Identity values are sip URI, it should consider it is invalid, 400 Bad Request should be returned or header should be ignored
SIP_UA_3325_I_024Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers, both P-Asserted-Identity values are tel URI, it should consider it is invalid, 400 Bad Request should be returned or header should be ignored
SIP_UA_3325_I_025Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers, one is sip URI and another is tel URI, and there is Privacy header in between, it should consider it is valid, P-Asserted-Identity should be displayed correctly
SIP_UA_3325_I_026Ensure that the IUT, when it receives an INVITE with two P-Asserted-Identity headers, both are sip and tel URIs, it should consider it is invalid, 400 should be returned
SIP_UA_3325_I_028Ensure that the IUT, when it receives an INVITE with three P-Asserted-Identity headers, two are sip URI and one tel URI, it should consider it is invalid, 400 should be returned
SIP_Extensions/
Resource_Management_3312
SIP_Extensions/
Resource_Management_3312/
Resource_Management_3312_HV
SIP_UA_3312_HV_001Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP status-type SP direction-tag
SIP_UA_3312_HV_002Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP e2e SP none, if the current setting is end-to-end and no resource reservation is needed
SIP_UA_3312_HV_003Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP e2e SP send, if the current setting is end-to-end with QoS in the sending direction
SIP_UA_3312_HV_004Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP e2e SP recv, if the current setting is end-to-end with QoS in the receiving direction
SIP_UA_3312_HV_005Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP e2e SP sendrecv, if the current setting is end-to-end with QoS in both direction
SIP_UA_3312_HV_006Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP status-type SP direction-tag
SIP_UA_3312_HV_007Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP status-type SP direction-tag
SIP_UA_3312_HV_008Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have current-status line a=curr:qos SP status-type SP direction-tag
SIP_UA_3312_HV_009Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP strength-tag SP status-type SP direction-tag
SIP_UA_3312_HV_010Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP mandatory SP e2e SP send if the call precondition is set to mandatory in the sending direction
SIP_UA_3312_HV_011Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP mandatory SP e2e SP recv if the call precondition is set to mandatory in the receiving direction
SIP_UA_3312_HV_012Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP mandatory SP e2e SP sendrecv if the call precondition is set to mandatory in both directions
SIP_UA_3312_HV_013Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP optional SP e2e SP send if the call precondition is set to optional in the sending direction
SIP_UA_3312_HV_014Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP optinoal SP e2e SP recv if the call precondition is set to optional in the receiving direction
SIP_UA_3312_HV_015Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP optional SP e2e SP sendrecv if the call precondition is set to optional in the both directions
SIP_UA_3312_HV_016Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP optional SP e2e SP sendrecv if the call precondition is set to optional in the both directions
SIP_UA_3312_HV_017Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP none SP e2e SP send if no call precondition is set in the sending direction
SIP_UA_3312_HV_018Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP none SP e2e SP recv if no call precondition is set in the receiving direction
SIP_UA_3312_HV_019Ensure that the IUT, when it constructs precodition SDP in INVITE or UPDATE, it MUST have desired-status line a=des:qos SP none SP e2e SP sendrecv if no call precondition is set in both direction
SIP_UA_3312_HV_020Ensure that the IUT, when it constructs precodition SDP in PRACK or UPDATE, it MUST have desired-status line a=conf:qos SP status-type SP direction-tag
SIP_UA_3312_HV_021Ensure that the IUT, when it constructs precodition SDP in PRACK or UPDATE, it MUST have desired-status line a=conf:qos SP e2e SP send if it needs to confirm call precondition in the sending direction
SIP_UA_3312_HV_022Ensure that the IUT, when it constructs precodition SDP in PRACK or UPDATE, it MUST have desired-status line a=conf:qos SP e2e SP recv if it needs to confirm call precondition in the receiving direction
SIP_UA_3312_HV_023Ensure that the IUT, when it constructs precodition SDP in PRACK or UPDATE, it MUST have desired-status line a=conf:qos SP e2e SP sendrecv if it needs to confirm call precondition in both direction
SIP_UA_3312_HV_024Ensure that the IUT, when it constructs precodition SDP in for segmented method, it MUST use status-tag local and remote.*Not supported
SIP_UA_3312_HV_025Ensure that the IUT, when it constructs precodition SDP in the outgoing INVITE, if the offer contains one of more “mandatory" strength-tags, it MUST include Require:precondition header
SIP_UA_3312_HV_026Ensure that the IUT, when it constructs precodition SDP in the outgoing INVITE, if the offer strength-tags are either none or optional, it SHOULD include Supported:precondition header
SIP_UA_3312_HV_027Ensure that the IUT, when it constructs precodition SDP in the outgoing INVITE, it must also have support:100rel header and Allow:UPDATE header in the INVITE
SIP_Extensions/
Resource_Management_3312/
Resource_Management_3312_V
SIP_UA_3312_V_001Ensure that the IUT, when it construct precondition SDP, if the strength-tags for both directions are none, it MUST add one desired status line with tag sendrecv, i.e. a=des:qos none SP e2e SP sendrev in INVITE or UPDATE
SIP_UA_3312_V_002Ensure that the IUT, when it construct precondition SDP, if the strength-tags for both directions are optional, it MUST add one desired status line with tag sendrecv, i.e. a=des:qos optional SP e2e SP sendrev in INVITE or UPDATE
SIP_UA_3312_V_003Ensure that the IUT, when it construct precondition SDP, if the strength-tags for both directions are mandatory, it MUST add one desired status line with tag sendrecv, i.e. a=des:qos mandatory SP e2e SP sendrev in INVITE or UPDATE
SIP_UA_3312_V_004Ensure that the IUT, when it construct precondition SDP, if the strength-tags for both directions are unknown, it MUST add one desired status line with tag sendrecv, i.e. a=des:qos unknown SP e2e SP sendrev in INVITE or UPDATE.*** this is not typical, not supported
SIP_UA_3312_V_005Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is none and receiving direction is optional, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos none SP e2e SP send, a=des:qos optional e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_006Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is none and receiving direction is Mandatory, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos none SP e2e SP send, a=des:qos mandatory e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_007Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is none and receiving direction is unknown, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos none SP e2e SP send, a=des:qos unknown e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_008Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is optional and receiving direction is none, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos optional SP e2e SP send, a=des:qos none e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_009Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is optional and receiving direction is mandatory, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos optional SP e2e SP send, a=des:qos mandatory e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_010Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is Mandatory and receiving direction is none, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos mandatory SP e2e SP send, a=des:qos none e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_011Ensure that the IUT, when it construct precondition SDP, if the strength-tags for sending direction is mandatory and receiving direction is optional, it MUST add at least one desired status line with tag send and aother with the tag recv, i.e. a=des:qos mandatory SP e2e SP send, a=des:qos optional e2e SP recv in INVITE or UPDATE
SIP_UA_3312_V_012Ensure that the IUT, when it construct precondition SDP for segmented status type, it MUST generate two current status lines: one with the tag “local" and the other with the tag “remote".*not supported
SIP_UA_3312_V_013Ensure that the IUT, when it receives the precondition offer, and sending the answer back, it should start resource reservation if the status-type is e2e
SIP_UA_3312_V_014Ensure that the IUT, when it receives the precondition answer after it sending out the offer, it should start resource reservation if status-type is e2e
SIP_UA_3312_V_015Ensure that the IUT, when it receives precondition INVITE , it SHOULD NOT alert the user until there are network resouces reserved in both directions end-to-end, in stead it should send 183 to start Resource reservation to confirm
SIP_UA_3312_V_016Ensure that the IUT, when it receives an INVITE request with no offer, it SHOULD provide an precondition offer in a reliable 1xx respond, and wait for the answer in PRACK, it SHOULD NOT alert the user until there are network resouces reserved in both directions end-to-end
SIP_UA_3312_V_017Ensure that the IUT, when it the precondition SDP never sent in 180 respond when precondition is enable
SIP_UA_3312_V_018Ensure that the IUT, when it need the confirm-status for the mandatory preconditions, it should send SDP with confirm-status a=conf:qos SP e2e SP direction-tag
SIP_UA_3312_V_019Ensure that the IUT, when it receives the confirm-status in 183, the confirm-status is NOT negatiated, it MUST use this value in the confirm-status to send in the UPDATE SDP
SIP_UA_3312_V_020Ensure that the IUT, when it receives the confirm-status in UPDATE, the confirm-status is NOT negatiated, it MUST use this value in the confirm-status to send in the 200 UPDATE SDP
SIP_UA_3312_V_021Ensure that the IUT, it receives INVITE with precondition SDP, but not willing to meet the precondition in the offer, it SHOULD reject the offer by returning 580 (Precondition-Failure) respond with a=des:qos failure e2e send
SIP_UA_3312_V_022Ensure that the IUT, it receives 18x with precondition SDP responds to INVITE, but not willing to meet the precondition in the offer, it SHOULD reject the offer by sending CANCEL respond with a=des:qos failure e2e send
SIP_UA_3312_V_023Ensure that the IUT, it receives 200 with precondition SDP responds to INVITE, but not willing to meet the precondition in the offer, it SHOULD reject the offer by sending BYE respond with a=des:qos failure e2e send
SIP_UA_3312_V_024Ensure that the IUT, it receives re-INVITE with precondition SDP, but not willing to meet the precondition in the offer, it SHOULD reject the offer by returning 580 (Precondition-Failure) respond with a=des:qos failure e2e send
SIP_UA_3312_V_025Ensure that the IUT, when it responds failure SDP for precondition, for each “m=" line in the last SDP it received, there MUST be a corresponding “m=" line in the responding SDP to sescript the failure. The port number of every “m=" line MUST be set to zero, but the connection address is arbitrary
SIP_UA_3312_V_026Ensure that the IUT, when it receives INVITE with precondition a=des: foo mandatory e2e sendrecv, it MUST refuse the offer using a=des:foo unknown e2e send in 580 Precondition-Failure
SIP_UA_3312_V_027Ensure that the IUT, when it receives INVITE with precondition a=des: foo mandatory local sendrecv, it SHOULD NOT reject the offer if it does support segmented status
SIP_UA_3312_V_028Ensure that the IUT, when it receives INVITE with precondition a=des: foo mandatory local sendrecv, it SHOULD reject the offer if it is not willing to meet with 488
SIP_UA_3312_V_029Ensure that the IUT, when it has multiple conditions for a media stream, all the preconditions for a media stream MUST be met in order to resume session establishment. (e.g. if attribut has both e2e and segmented, then both need to be met)
SIP_UA_3312_V_030Ensure that the IUT, when it receives OPTIONS request, it MUST add disred status line indicating all the supported precondition-types for the each media stream. These lines MUST have the “none" strength-tag and supported header has precondition
SIP_UA_3312_V_030AEnsure that the IUT, when it receives INVITE request with Require:precondition, it MUST return 420 with Unsupported:precondition header if it is not support or configured not to support precondition
SIP_Extensions/
Resource_Management_3312/
Resource_Management_3312_I
SIP_UA_3312_I_001Ensure that the IUT, when it receives a 420 respond for INVITE with mandatory precondition, it should ACK it and behavious correctly (based on local policy, either retry without precondition or stop)
SIP_UA_3312_I_002Ensure that the IUT, when it receives a 183 with no precondition SDP, it should know the UAS does not support optional precondition, and continouse the call based on local policy
SIP_UA_3312_I_003Ensure that the IUT, when it receives 488 it SHOULD correctly ACK.
SIP_UA_3312_I_004Ensure that the IUT, when it receives 580 Precondition Failure with a=des:qos failure e2e direction-tag, it SHOULD correctly ACK, and based on local policy try to send new INVITE without precondition
SIP_UA_3312_I_005Ensure that the IUT, when it receives a 302, it SHOULD send new INVITE with same precondition SDP
SIP_UA_3312_I_006Ensure that the IUT, when it receives INVITE with precondition which does not support or understand (e.g. a=des:whatever strong e2e sendrecv), it MUST return 488
SIP_UA_3312_I_007Ensure that the IUT, when it receives a INVITE with Supported: precondition, but set to not support precondition, it should proceed the call like without precondition header
SIP_UA_3312_I_008Ensure that the IUT, when it receives a INVITE with precondition with Require header, and set to not support precondition, it MUST return 420 with Unsupported header
SIP_UA_3312_I_009Ensure that the IUT, when it receives a INVITE with precondition with Require header, and fail to reserve resource, it should respond 580 Precondition Failure
SIP_UA_3312_I_010Ensure that the IUT, when it sends INVITE with precondition and receive 183, but fails to reserve resource, it MUST send CANCEL with a=des:qos failure e2e send for the media
SIP_UA_3312_I_011Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos mandatory e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_012Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:QoS mandatory e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_013Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos MANDATORY e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_014Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos mandatory E2E sendrecv, it should proceed correctly
SIP_UA_3312_I_015Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos mandatory e2e SENDRECV, it should proceed correctly
SIP_UA_3312_I_016Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos what e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_017Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos mandatory p2p sendrecv, it should proceed correctly
SIP_UA_3312_I_018Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=DES:qos mandatory e2e txrx, it should proceed correctly
SIP_UA_3312_I_019Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos mandatory, it should returns 488
SIP_UA_3312_I_020Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos e2e mandatory sendrecv, it should returns 488
SIP_UA_3312_I_021Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des only no a=curr line, it should return 488
SIP_UA_3312_I_022Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=curr only no a=des line, it should returns 488
SIP_UA_3312_I_022AEnsure that the IUT, when it receives a INVITE with precondition for two medias, only one media has precondition attribute, it should returns 488 or 580
SIP_UA_3312_I_023Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos none e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_024Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos unknown e2e sendrecv, it should proceed correctly
SIP_UA_3312_I_025Ensure that the IUT, when it receives a INVITE with precondition with Require header, and with a=des:qos failure e2e sendrecv, it should proceed correctly
SIP_Extensions/
Reason_Header_for_Preemption_Events_4411
SIP_Extensions/
Reason_Header_for_Preemption_Events_4411/
Reason_Header_for_Preemption_Events_4411_HV
SIP_UA_4411_HV_001Ensure that the IUT, when it constructs Reason header for preemption, it SHOULD put Reason: preemption with correct cause value and optional text
SIP_Extensions/
Reason_Header_for_Preemption_Events_4411/
Reason_Header_for_Preemption_Events_4411_V
SIP_UA_4411_V_001Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.priority, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_002Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.immediate, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_003Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_004Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_005Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.immediate, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_006Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_007Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_008Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate and receives a new INVITE with Resource-Priority:dsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_009Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate and receives a new INVITE with Resource-Priority:dsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_010Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.flash and receives a new INVITE with Resource-Priority:dsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_011Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.priority, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_012Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.immediate, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_013Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_014Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_015Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_016Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.immediate, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_017Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_018Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_019Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_020Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_021Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_022Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_023Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash and receives a new INVITE with Resource-Priority:drsn.flash-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_024Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_025Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_026Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override-override and receives a new INVITE with Resource-Priority:drsn.flash-override-override, it MUST terminate the old session and send a Reason: Preemption ,cause=1 ,text="UA Preemption" header in the BYE for old session
SIP_UA_4411_V_027Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.priority with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_028Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.immediate with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_029Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_030Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_031Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.immediate with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_032Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_033Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority and receives a new INVITE with Resource-Priority:dsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_034Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate and receives a new INVITE with Resource-Priority:dsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_035Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate and receives a new INVITE with Resource-Priority:dsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_036Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.flash and receives a new INVITE with Resource-Priority:dsn.flash-override, with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_037Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.priority with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_038Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.immediate with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_039Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_040Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_041Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_042Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.immediate with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_043Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_044Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_045Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_046Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_047Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_048Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_049Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash and receives a new INVITE with Resource-Priority:drsn.flash-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_050Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_051Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_052Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override-override and receives a new INVITE with Resource-Priority:drsn.flash-override-override with QoS precoditions, it MUST terminate the old session and send a Reason: Preemption ,cause=2 ,text="Reserved Resources Preempted" header in the BYE for old session
SIP_UA_4411_V_053Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine and receives a new INVITE with Resource-Priority:dsn.flash, it SHOULD terminate the old session and send a Reason: Preemption ,cause=3 ,text="Generic Preemption" header in the BYE for old session if it does not wish to provide a more precise reason than “preemption"
SIP_UA_4411_V_054Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.priority, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_055Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.immediate, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_056Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_057Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_058Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.immediate, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_059Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_060Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_061Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_062Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.immediate call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_063Ensure that the IUT, when it has an existing call with Resource-Priority:dsn.flash call to the TDM MLPP network, and when it receives a new TDM MLPP with dsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_064Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.priority, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_065Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.immediate, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_066Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_067Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_068Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.routine call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_069Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.immediate, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_070Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_071Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_072Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.priority call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_073Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_074Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_075Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.immediate call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_076Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_077Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_078Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_UA_4411_V_079Ensure that the IUT, when it has an existing call with Resource-Priority:drsn.flash-override-override call to the TDM MLPP network, and when it receives a new TDM MLPP with drsn.flash-override-override, it MUST terminate the session and send a Reason: Preemption ,cause=4 ,text="Non-IP Preemption" header in the BYE for old session
SIP_Extensions/
Reason_Header_for_Preemption_Events_4411/
Reason_Header_for_Preemption_Events_4411_I
SIP_UA_4411_I_001Ensure that the IUT, when it receives a BYE with Reason: PREEMPTION; CAUSE=1 for the outbound call, it should correctly understand
SIP_UA_4411_I_002Ensure that the IUT, when it receives a BYE with Reason: preemption; CAUSE=1,text="higher priority" for the outbound call, it should correctly understand
SIP_UA_4411_I_003Ensure that the IUT, when it receives a BYE with Reason: preemption; cause=5,text="whatever" for the outbound call, it should correctly handle it (ignore)
SIP_UA_4411_I_004Ensure that the IUT, when it receives a BYE with Reason: preemption; cause=0,text="whatever" for the outbound call, it should correctly handle it (ignore)
SIP_UA_4411_I_005Ensure that the IUT, when it receives a BYE with Reason: preemption for the outbound call, it should correctly handle it (ignore)
SIP_UA_4411_I_006Ensure that the IUT, when it receives a BYE with Reason: preempted; cause=1 for the outbound call, it should correctly handle it (ignore)
SIP_UA_4411_I_007Ensure that the IUT, when it receives a BYE with Reason: preemption; text="missing cause" for the outbound call, it should correctly handle it (ignore)
SIP_UA_4411_I_008Ensure that the IUT, when it receives a BYE with Reason: preemption; cause=1; test="missing cause" for the outbound call, it should correctly handle it (ignore unknown tag)
SIP_Extensions/
SIP_UA_4412
SIP_Extensions/
SIP_UA_4412/
SIP_UA_4412_HV
SIP_UA_4412_HV_001Ensure that the IUT, when it constructs Resource-Priority header in the outgoing message, it may have more than one r-value values
SIP_UA_4412_HV_002Ensure that the IUT, when it constructs Resource-Priority header r-value, it MUST consist exactly one namespace without “."
SIP_UA_4412_HV_003Ensure that the IUT, when it constructs Resource-Priority header r-value, it MUST in form of namespace.r-priority.
SIP_UA_4412_HV_004Ensure that the IUT, when it constructs Resource-Priority header, the namespace has at least one priority value.
SIP_UA_4412_HV_005Ensure that the IUT, when it constructs Resource-Priority header in the outgoing message, the Namesspaces and priority values within each namespace MUST be registed with IANA
SIP_UA_4412_HV_006Ensure that the IUT, when it constructs Resource-Priority header, a particular namespace MUST NOT appear more than once in the same SIP message
SIP_UA_4412_HV_007Ensure that the IUT, when it constructs multiple namespaces within the same message, it can either in different Resource-Priority headers or in the same Resource-Priority header and separate by comma.
SIP_UA_4412_HV_008Ensure that the IUT, when it constructs Accept-Resource-Priority header in the message, it SHOULD put multiple namespace and its values seperated by comma rather than multiple Accept-Resource-Priority headers
SIP_UA_4412_HV_009Ensure that the IUT, uses Accept-Resource-Priority header in the Respond Status message 200 and 417 although it is not mandatory.
SIP_UA_4412_HV_010Ensure that the IUT, when it wants to enforce Resource-Priority, it MUST put resource-priority in the Require header
SIP_Extensions/
SIP_UA_4412/
SIP_UA_4412_V
SIP_UA_4412_V_001Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound INVITE if it supports 4412
SIP_UA_4412_V_002Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound UPDATE if it supports 4412
SIP_UA_4412_V_003Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound REFER if it supports 4412.
SIP_UA_4412_V_004Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound PRACK if it supports 4412
SIP_UA_4412_V_005Ensure that the IUT, when it MUST construct Resource-Priority header in ACK for the INVITE if it supports 4412.
SIP_UA_4412_V_006Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound MESSAGE if it supports 4412
SIP_UA_4412_V_007Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound SUBSCRIBE if it supports 4412
SIP_UA_4412_V_008Ensure that the IUT, when it MUST construct Resource-Priority header in the outbound NOTIFY if it supports 4412
SIP_UA_4412_V_009Ensure that the IUT MUST do something with a message containing a Resource-Priority header -- not defined
SIP_UA_4412_V_010Ensure that the IUT MUST accept (DO NOT respond with a 417) an inbound INVITE containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_011Ensure that the IUT MUST accept (DO NOT respond with a 417) an inbound UPDATE containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_012Ensure that the IUT MUST accept (DO NOT respond with a 417) an inbound REFER containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_013Ensure that the IUT MUST accept (DO NOT respond with a 417) an inbound PRACK containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_014Ensure that the IUT MUST accept (DO NOT respond with a 417) an inbound ACK containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_015Ensure that the IUT SHOULD accept (DO NOT respond with a 417) an inbound MESSAGE containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_016Ensure that the IUT SHOULD accept (DO NOT respond with a 417) an inbound SUBSCRIBE containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_017Ensure that the IUT SHOULD accept (DO NOT respond with a 417) an inbound NOTIFY containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_018Ensure that the IUT MAY accept (DO NOT respond with a 417) any other inbound SIP request containing Resource-Priority header with a known r-value and "Require: resource-priority" header
SIP_UA_4412_V_019Ensure when IUT receives Require header with value resource-priority and it is not (configured to) support 4412, it MUST respond with 420 Bad Extension and Unsupported header including resource-priority in the list
SIP_UA_4412_V_020Ensure that the IUT, when it receives OPTIONS message, it SHOULD return 200 with Accept-Resource-Priority header with all the valid resource values it willing to process
SIP_UA_4412_V_021Ensure that the IUT, when it receives OPTIONS message, it MUST binds supported:resource-priority in the respond if it does support 4412
SIP_UA_4412_V_022Ensure that the IUT, when it receives an INVITE namespace with lower priority (dsn.routine), with exsisting call with higher priority (dsn.immediate), the call SHOULD NOT be honored (e.g. get 486 back)
SIP_UA_4412_V_023Ensure that the IUT, when it receives an INVITE namespace with same priority (dsn.flash), with exsisting call with higher priority (dsn.flash), the call SHOULD NOT be honored (e.g. get 486 back)
SIP_UA_4412_V_024Ensure that the IUT, when it receives an INVITE namespace with higher priority (dsn.flash-override), with exsisting call with lower priority(dsn.priority), the call SHOULD be honored (e.g. 183/180 back), and the lower priority call get preempted
SIP_UA_4412_V_025Ensure that the IUT, when it receives INVITE namespace and supports Queuing when no resource avaliable, it should perform FIFO for the same priority and responds back 182.
SIP_UA_4412_V_026Ensure that the IUT, when it receives INVITE namespace and supports Queuing and the requests that exceed a specific waiting time, it should respond back with 408 Request Timeout.
SIP_UA_4412_V_027Ensure that the IUT, when it receives INVITE namespace and supports Queuing and the queue is full, it should reject with 488 or 503. *We do not support Queuing
SIP_UA_4412_V_028Ensure that the IUT, when it receives an INVITE with unknown namespace (whatever.important), with Require: resource-priority optional tag, it SHOULD respond 417 "Unknown Resource-Priority" with Accept-Resource-Priority header when it is config support 4412
SIP_UA_4412_V_029Ensure that the IUT, when it receives an INVITE with unknown namespace (whatever.important), without Require: resource-priority optional tag, it SHOULD just ignore the namespace like without Resource-Priority header
SIP_UA_4412_V_030Ensure that the IUT, when it receives an INVITE with unknown namespace (whatever.important) along with other dsn or drsn namespaces, with Require: resource-priority optional tag, it SHOULD proceed the known namespace and ignore the unknown one
SIP_UA_4412_V_031Ensure that the IUT, when it receives an REFER with unknown namespace (whatever.important), with Require: resource-priority optional tag, it SHOULD respond 417 “Unknown Resource-Priority" with Accept-Resource-Priority header when it is config support 4412
SIP_UA_4412_V_032Ensure that the IUT, when it receives an REFER with unknown namespace (whatever.important), without Require: resource-priority optional tag, it SHOULD just ignore the namespace like without Resource-Priority header
SIP_UA_4412_V_033Ensure that the IUT, when it receives an REFER with unknown namespace (whatever.important) along with other dsn or drsn namespaces, with Require: resource-priority optional tag, it SHOULD proceed the known namespace and ignore the unknown one
SIP_UA_4412_V_034Ensure that the IUT, when it receives an INVITE with known namespaces, but the originator is not authorized for that level of service, 403 Forbidden SHOULD respond
SIP_UA_4412_V_035Ensure that the IUT, when it receives a INVITE with Resource-Priority but with insufficient resouce, it SHOULD return 503 “Service Unavailable"
SIP_UA_4412_V_036Ensure that the IUT, when it receives a INVITE with Resource-Priority but with insufficient bandwidth with the same priority calls, it SHOULD return 488 “Not Acceptable Here" with Warning header “warning code 370 (Insufficient Bandwidth)"
SIP_UA_4412_V_037Ensure that the IUT, when it receives 417 respond for its outbound INVITE, it SHOULD choose authorized resource value from Accept-Resource-Priority header and do re-INVITE
SIP_UA_4412_V_038Ensure that the IUT, when it MUST understand a Reason header in BYE when preemption happen for the low priority call session
SIP_UA_4412_V_039Ensure that the IUT, when it receives a INVITE with higher priority, it MUST terminate a session with lower-priority value then send a valid Reason header in the BYE
SIP_UA_4412_V_040Ensure that the IUT, when it receives a INVITE with Resource-Priority: wps.1, q735.4, ets.3, dsn.routine, it SHOULD respond use dsn.routine if that is the only one supported
SIP_UA_4412_V_041Ensure that the IUT, when it receives a INVITE with Resource-Priority: wps.1, ets.3, dsn.routine, drsn.immediate it SHOULD respond drsn.immediate since that is the best supported namespace matched. Assuming both dsn and drsn are supported. Note: The presence of Require: resource-priority does not matter
SIP_UA_4412_V_042Ensure when IUT receives an INVITE with Require: resource-priority and two Resource-Priority headers. The first contains invalid r-values(e.g. wps.1, q735.4, ets.4) and the second contains a supported r-value, it SHOULD respond with 417 since AS-SIP GSR does not support multiple Resource-Priority headers and only processes the 1st one.
SIP_UA_4412_V_043Ensure when IUT receives an INVITE with Require: resource-priority and two Resource-Priority headers, and the first contains at least one valid r-value, it SHOULD process the best valid r-value in the 1st Resource-Priority.
SIP_Extensions/
SIP_UA_4412/
SIP_UA_4412_I
SIP_UA_4412_I_001Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn-flash, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header
SIP_UA_4412_I_002Ensure when IUT receives an INVITE with invalid priority value (e.g. Resource-Priority:dsn.9), and with Require:resrouce-priority header, it MUST consider it is valid request and use the default ‘routine’ (0) value
SIP_UA_4412_I_003Ensure when IUT receives an INVITE with malformed precedence-domain (e.g. Resource-Priority:dsn-FOOBAR.6), and with Require:resource-priority header, it MUST consider it is valid request and use the default precedence-domain 00000
SIP_UA_4412_I_004Ensure when IUT receives an INVITE with incorrect r-value syntax (e.g. Resource-Priority:dsn-6), and without Require:resource-priority header, it MUST consider it is invalid and discard the header. It MUST process the INVITE as if there is no Resource-Priority
SIP_UA_4412_I_005Ensure when IUT receives an INVITE with invalid priority value (e.g. Resource-Priority:dsn.9), and without Require:resource-priority header, it MAY consider it is valid request and use the default ‘routine’ (0) value
SIP_UA_4412_I_006Ensure when IUT receives an INVITE with malformed precedence-domain (e.g. Resource-Priority:dsn-FOOBAR.6), and without Require:resource-priority header, it MUST consider it is valid request and use the default precedence-domain 00000
SIP_UA_4412_I_009Ensure when IUT receives an INVITE with Resource-Priority:dsn, drsn.4, it MUST consider it is valid and honor the drsn.4 resource request
SIP_UA_4412_I_010Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn.flash, dsn.immediate, and without Require:Resource-priority header, it should consider it is invalid, either honor the higher priority one or just discard it
SIP_UA_4412_I_011Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn.flash, dsn.immediate, and with Require:Resource-priority header, it should consider it is invalid, either honor the higher priority one or just returns 417
SIP_UA_4412_I_012Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn.flash-override-override, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header
SIP_UA_4412_I_013Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn.flash-override-override, and without Require:Resource-priority header, it MUST consider it is invalid, and discard it
SIP_UA_4412_I_014Ensure that the IUT, when it receives an INVITE with Resource-Priority:whatever.flash, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header
SIP_UA_4412_I_015Ensure that the IUT, when it receives an INVITE with Resource-Priority:drsn.whatever, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header
SIP_UA_4412_I_016Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header if it does not support q.735
SIP_UA_4412_I_017Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, and without Require:Resource-priority header, it MUST consider it is invalid, and discard the header if it does not support q.735
SIP_UA_4412_I_018Ensure that the IUT, when it receives an INVITE with Resource-Priority:ets.0, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header if it does not support ets
SIP_UA_4412_I_019Ensure that the IUT, when it receives an INVITE with Resource-Priority:ets.0, and without Require:Resource-priority header, it MUST consider it is invalid, and discard header if it does not support ets
SIP_UA_4412_I_020Ensure that the IUT, when it receives an INVITE with Resource-Priority:wps.0, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header if it does not support wps
SIP_UA_4412_I_021Ensure that the IUT, when it receives an INVITE with Resource-Priority:wps.0, and without Require:Resource-priority header, it MUST consider it is invalid, and discard header if it does not support wps
SIP_UA_4412_I_022Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header if it does not support them
SIP_UA_4412_I_023Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, and without Require:Resource-priority header, it MUST consider it is invalid, and discard the header if it does not support them
SIP_UA_4412_I_024Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, drsn.whatever, and with Require:Resource-priority header, it MUST consider it is invalid, and returns 417 with Accept-Resource-Priority header if it does not support them
SIP_UA_4412_I_025Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, drsn.whatever, and without Require:Resource-priority header, it MUST consider it is invalid, and discard the header if it does not support them
SIP_UA_4412_I_026Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, drsn.whatever, dsn.immediate, and with Require:Resource-priority header, it MUST consider it is valid, and honor the call
SIP_UA_4412_I_027Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, drsn.whatever and Resource-Priority:dsn.immediate, and with Require:Resource-priority header, it MUST consider it is valid, and honor the call
SIP_UA_4412_I_028Ensure that the IUT, when it receives an INVITE with Resource-Priority:q735.0, ets.0, wps.0, drsn.flash, dsn.immediate, and with Require:Resource-priority header, it MUST consider it is valid, and honor the call with drsn.flash
SIP_UA_4412_I_029Ensure when IUT has an exsisting call with Resource-Priority:dsn.4 and receives a new re-INVITE with Resource-Priority:dsn.9, it MUST NOT terminate the old session, and the latest priority value is used. In this case dsn.9 is used from this on
SIP_UA_4412_I_030Ensure when IUT has an exsisting call with Resource-Priority:dsn.4 and receives a new re-INVITE with Resource-Priority:drsn.9, it MUST NOT terminate the old session, and the latest priority value is used. In this case drsn.9 is used from this on
SIP_UA_4412_I_031Ensure that the IUT, when it has an exsisting call with Resource-Priority:dsn.immediate and receives a new INVITE with Resource-Priority:wps.0, drsn.flash, dsn.flash, it MUST terminate the old session and send a valid Reason header in the BYE and honor the new call
SIP_UA_4412_I_032Ensure that the IUT, when it receives an INVITE with Resource-Priority:DSN.FLASH, DSN.IMMEDIATE, and without Require:Resource-priority header, it should consider it is invalid, either honor the higher priority one or just discard it
SIP_UA_4412_I_033Ensure that the IUT, when it receives an INVITE with Resource-Priority:dsn.flash, dsn.immediate, and with Require:Resource-priority header, it should consider it is invalid, either honor the higher priority one or just returns 417
SIP_UA_4412_I_034Ensure that the IUT, when it has an exsisting call with Resource-Priority:DRSN.flash-override and receives a new INVITE with Resource-Priority:drsn.FLASH, it MUST NOT terminate the old session and SHOULD NOT honor the new call
SIP_UA_4412_I_035Ensure that the IUT, when it has an exsisting call with Resource-Priority:drsn.FLASH and receives a new INVITE with Resource-Priority:DRSN.FLaSH-OVERRide, it MUST NOT terminate the old session and SHOULD NOT honor the new call
SIP_UA_4412_I_036Ensure that the IUT, when it has an exsisting call with RESOURCE-PRIORITY:DSN.flash and receives a new INVITE with RESOURCE-PRIORITY:DSn.FLASH-override, it MUST terminate the old session and send a valid Reason header in the BYE and honor the new call
SIP_MISC
CC_TE_CE_V_029_BEnsure that the SUT when a server INVITE transaction is in the Proceeding state, on
Valid_Call_001 Originate a call from the Tester to the SUT to verify basic call capability
SIP_481
SIP_OPTIONS Originate OPTIONS msg
SIP_PUBLISH Originate PUBLISH msg
SIP_NOTIFY Originate NOTIFY msg
SIP_REFER
SIP_INFO Originate INFO msg
SIP_PRACK
SIP_UPDATE Originate UPDATE msg
SIP_Raw_1Send a raw packet
SIP_Raw_2Send a raw packet
SIP_Raw_3Send a raw packet for REGISTER test
Incoming_Call_1Wait in a loop for an incoming call
SIP_100 Originate 100 Trying msg
SIP_Basic_Response_001 Ensure the SUT, after having received a valid INVITE, responds
SIP_Basic_Response_002 Ensure the SUT, when sent OPTIONS in an ACTIVE CALL, responds
Replaces_Valid_001 Ensure SUT, after establishing a call, upon receipt of a new INVITE Request with REPLACES header, responds with a 200 OK
Replaces_Invalid_001 Ensure SUT, after establishing a call, upon receipt of a new INVITE Request with a REPLACES header,
Refer_Valid_001Ensure SUT, having received a REFER Request and having sent a NOTIFY response, responds with a SECOND NOTIFY
Notify_Valid_001Ensure SUT, having received a REFER Request and having sent a NOTIFY response, responds with a SECOND NOTIFY
Subscribe_Valid_001Ensure SUT, having received a SUBSCRIBE Request and having sent a NOTIFY response, responds with a SECOND NOTIFY
Video_Valid_001Ensure SUT, having received a SUBSCRIBE Request and having sent a NOTIFY response, responds with a SECOND NOTIFY
Third_Party_Call_AddedA Two party call is established, a third party is added, the callee can media mix in a third party call
Call_HoldA Two party call is established, the callee places the call on hold, then the callee takes the call off hold,
Call_Hold_2A Two party call is established, the callee places the call on hold, then the callee takes the call off hold,
MESSAGE_Valid_01
Transfer_UnattendedA two party call is established, the callee transfers the caller to a third party, then hangs up. The
Send_MSRP_01Send MSRP
Authentication_01Send REGISTER with MD5 authentication
PING_01Send PING
Authentication_PING_01Send PING, then REGISTER with authentication
Valid_Call_002 Originate a call from the Tester to the SUT with specific SDP content
Get_INVITE_Send_417 Output a 417 Response
Get_INVITE_Send_606 Output a 417 Response
SIP_3GPP_IM
SIP_3GPP_P_CSCF_001Register UE with HSS via P_CSCF
Simple_LoopbackSimple loopback test

VariableDefault ValueDescription
IP_Address_SUT_Link1"192.168.1.36" IP address of SUT (without port) primary link
IP_Address_SUT_Link2"192.168.1.36" IP address of SUT (without port), secondary link for use with Proxy testing
IP_Address_SUT_Link3"192.168.1.36" IP address of SUT (without port), third link for use with Proxy testing
IP_Address_SUT_Link4"192.168.1.36" IP address of SUT (without port), fourth link
IP_Address_SUT_Link5"192.168.1.36" IP address of SUT (without port), fourth link
IP_Address_SUT_Link6"192.168.1.36" IP address of SUT (without port), fourth link
IP_Address_TESTER_Link1"192.168.1.3" IP address of Tester (without port) primary link
IP_Address_TESTER_Link2"192.168.1.4" IP address of Tester (without port), secondary link for use with Proxy testing
IP_Address_TESTER_Link3"192.168.1.10" IP address of Tester (without port), third link for use with Proxy testing
IP_Address_TESTER_Link4"192.168.1.11" IP address of Tester (without port), fourth link
IP_Address_TESTER_Link5"192.168.1.11" IP address of Tester (without port), fourth link
IP_Address_TESTER_Link6"192.168.1.11" IP address of Tester (without port), fourth link
IP_Address_TESTER_Media1""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link1
IP_Address_TESTER_Media2""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link2
IP_Address_TESTER_Media3""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link3
IP_Address_TESTER_Media4""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link4
IP_Address_TESTER_Media5""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link4
IP_Address_TESTER_Media6""Use to override Media IP address. If empty, uses IP_Address_TESTER_Link4
IP_Domain_SUT_Link1"example.com" Domain name of SUT (without port) primary link
IP_Domain_SUT_Link2"example.com" Domain name of SUT (without port) secondary link for use with Proxy testing
IP_Domain_SUT_Link3"example.com" Domain name of SUT (without port), third link for use with Proxy testing
IP_Domain_SUT_Link4"example.com" Domain name of SUT (without port), fourth link
IP_Domain_SUT_Link5"example.com" Domain name of SUT (without port), fourth link
IP_Domain_SUT_Link6"example.com" Domain name of SUT (without port), fourth link
IP_Domain_TESTER_Link1"example.com" Domain name of Tester (without port) primary link
IP_Domain_TESTER_Link2"example.com" Domain name of Tester (without port), secondary link for use with Proxy testing
IP_Domain_TESTER_Link3"example.com" Domain name of Tester (without port), third link for use with Proxy testing
IP_Domain_TESTER_Link4"example.com" Domain name of Tester (without port), fourth link
IP_Domain_TESTER_Link5"example.com" Domain name of Tester (without port), fourth link
IP_Domain_TESTER_Link6"example.com" Domain name of Tester (without port), fourth link
IP_Domain_Use_DomainFALSE Set to TRUE if need to use Domain in messages
IP_Register_With_ProxyFALSE Set to TRUE if register with Proxy is required
IP_Proxy_Addressing_ModeFALSE Set to TRUE if using Proxy Address as local address
IP_SIP_Port_SUT"5060" Port to use for testing
IP_SIP_Port_TESTER"5060" Port to use for testing
IP_Transport_ModeTransport_Param_UDP Transport used for SIP
PHONE_Number_SUT"sip:94167601111" Phone number of SUT
PHONE_Number_SUT_Invalid"sip:9999" Invalid phone number of SUT
PHONE_Number_TESTER_UA1"sip:9057403000" Phone number of Tester
PHONE_Number_TESTER_UA2"sip:9057403001" Phone number of Tester used for proxy test
PHONE_Number_TESTER_UA3"sip:9057403002" Phone number of Tester used for proxy test
PHONE_Number_TESTER_UA4"sip:9057403003" Phone number of Tester
PHONE_Number_TESTER_UA5"sip:9057403004" Phone number of Tester
PHONE_Number_TESTER_UA6"sip:9057403005" Phone number of Tester
PHONE_Number_TESTER_Refer_To"" Phone number to REFER to e.g. sip:1234
PHONE_Number_TESTER_Call_Forward"sip:137001" Phone number of Tester
PHONE_Number_TESTER_Call_Forward_Cancel"sip:14" Phone number of Tester
PHONE_Number_TESTER_Call_Fwd_Busy"sip:157001" Phone number of Tester
PHONE_Number_TESTER_Call_Fwd_Busy_Cancel"sip:16" Phone number of Tester
PHONE_Number_TESTER_Call_Fwd_NoAns"sip:177001" Phone number of Tester
PHONE_Number_TESTER_Call_Fwd_NoAns_Cancel"sip:18" Phone number of Tester
Ext_PHONE_Number_TESTER_UA1"sip:5003" Phone number of Tester
Ext_PHONE_Number_TESTER_UA2"sip:5004" Phone number of Tester used for proxy test
Ext_PHONE_Number_TESTER_UA3"sip:5005" Phone number of Tester used for proxy test
Ext_PHONE_Number_TESTER_UA4"sip:5006" Phone number of Tester used for proxy test
Ext_PHONE_Number_TESTER_UA5"sip:5007" Phone number of Tester used for proxy test
Ext_PHONE_Number_TESTER_UA6"sip:5008" Phone number of Tester used for proxy test
PHONE_Contact_Screen_Name_UA1"UA1"(null)
PHONE_Contact_Screen_Name_UA2"UA2"(null)
PHONE_Contact_Screen_Name_UA3"UA3"(null)
PHONE_Contact_Screen_Name_UA4"UA4"(null)
PHONE_Contact_Screen_Name_UA5"UA5"(null)
PHONE_Contact_Screen_Name_UA6"UA6"(null)
PING_FirewallFALSE Set to TRUE if PING is to be sent to obtain firewall info
PX_AUTH_Authentication_Mode0(null)
PX_AUTH_UA1_CNONCE"135945015"(null)
PX_AUTH_UA1_PASS"1234"(null)
PX_AUTH_UA1_QOP"auth"(null)
PX_AUTH_UA1_REALM""(null)
PX_AUTH_UA1_USER"9057403000"(null)
PX_AUTH_UA2_CNONCE"135945016"(null)
PX_AUTH_UA2_PASS"1234"(null)
PX_AUTH_UA2_QOP"auth"(null)
PX_AUTH_UA2_REALM""(null)
PX_AUTH_UA2_USER"9057403001"(null)
PX_AUTH_UA3_CNONCE"135945017"(null)
PX_AUTH_UA3_PASS"1234"(null)
PX_AUTH_UA3_QOP"auth"(null)
PX_AUTH_UA3_REALM""(null)
PX_AUTH_UA3_USER"9057403002"(null)
PX_AUTH_UA4_CNONCE"135945018"(null)
PX_AUTH_UA4_PASS"1234"(null)
PX_AUTH_UA4_QOP"auth"(null)
PX_AUTH_UA4_REALM""(null)
PX_AUTH_UA4_USER"9057403003"(null)
PX_AUTH_UA5_CNONCE"135945019"(null)
PX_AUTH_UA5_PASS"1234"(null)
PX_AUTH_UA5_QOP"auth"(null)
PX_AUTH_UA5_REALM""(null)
PX_AUTH_UA5_USER"9057403004"(null)
PX_AUTH_UA6_CNONCE"135945020"(null)
PX_AUTH_UA6_PASS"1234"(null)
PX_AUTH_UA6_QOP"auth"(null)
PX_AUTH_UA6_REALM""(null)
PX_AUTH_UA6_USER"9057403005"(null)
PX_Accept_Contact_TESTER"Accept-Contact: sip:sales@sol... Accept-Contact Tester
PX_Accept_Encoding_TESTER"" Accept-Encoding Tester - nt-im-2.0
PX_Accept_Language_TESTER"Accept-Language: en" Accept-Language Tester as English
PX_Acceptable_Payload_1"Session Description Protocol:... Acceptable payload #1
PX_Acceptable_Payload_2"Session Description Protocol:... Acceptable payload #2
PX_Allow_TESTER"Allow: INVITE, ACK, BYE, CANC... Allow header
PX_Authorization_TESTER"Authorization: Digest usernam... Authorization header sent in REGISTER
PX_Auto_Trigger_OFF_HOOKFALSE Automatically tear down active call
PX_Auto_Trigger_ON_HOOKFALSE Automatically answer ringing call
PX_Auto_Trigger_RESET_SUTFALSE Automatically reset SUTs current state
PX_CSeq_Base_TESTER100 Base for starting CSeq
PX_Call_ID_Base_TESTER"c3eF6f58-363323Cd-8058EB88-" Call-ID minus last 8 digits that are randomly generated
PX_Contact_3XX_TESTER"sip:1111@192.168.1.2:5060" Contact used in 3XX responses
PX_Contact_Phone_TESTER"sip:+19725552222@gw1.atlanta.... Contact URI in user=phone form
PX_Content_Disposition_Empty_TESTER"Content-Disposition: session;... Empty Content disposition
PX_Content_Disposition_Invalid_TESTER"Content-Disposition: xyz" Invalid Content disposition
PX_Content_Disposition_Optional_TESTER"Content-Disposition: session;... Optional Content disposition
PX_Content_Disposition_TESTER"Content-Disposition: session;... Content disposition Tester
PX_Content_Encoding_Invalid_TESTER"Content-Encoding: xyz" Invalid content encoding
PX_Content_Encoding_TESTER"Content-Encoding: gzip" Content encoding
PX_Content_Language_Invalid_TESTER"Content-Language: zzz"(null)
PX_Content_Language_TESTER"Content-Language: en"(null)
PX_Content_Type_DTMF_TESTER"Content-Type: application/dtm... DTMF Content-type
PX_Content_Type_TESTER"Content-Type: application/sdp... Content-type used by Tester
PX_Content_Type_Text_TESTER"Content-Type: text/plain"(null)
PX_Content_Type_Unacceptable_TESTER"Content-Type: application/pkc... Unacceptable Content-Type
PX_DomainName_SUT_Home_Registrar"registrar.home1.net"Used in 3GPP environment
PX_DomainName_SUT_Visited_PCSCF"pcscf1.visited1.net"Used in 3GPP environment
PX_Firewall_Mode_OnFALSE Set to TRUE when Tester is outside the firewall where the SUT resides
PX_IP_Address_Different_Via_Sentby"123.123.123.123" UDP/TCP port for different Via sent-by field
PX_IP_Address_Firewall_TESTER"68.163.247.247" Use for SIP messages when PX_Firewall_Mode_On is TRUE
PX_IP_Address_SUT_Invalid"99.99.99.99"(null)
PX_IP_Address_SUT_Visited_PCSCF"192.168.1.201"Used in 3GPP environment
PX_IP_SIP_Port_Different_Via_Sentby"1234"(null)
PX_Private_User_Identity_UE1"user1_private@home1.net"Used in 3GPP environment
PX_Proxy_Domain_Not_Responsible"@anydomain.com" Domain Proxy is not responsible for
PX_Proxy_No_Target"sip:12@domain" Proxy target does not exist
PX_Proxy_Require_TESTER""(null)
PX_Proxy_Require_TESTER_Not_Supported"Proxy-Require: abc" Not supported require
PX_Proxy_Resource_Not_Exist"sip:user@domain" Proxy resource does not exist
PX_Proxy_TESTER"sip:9999@192.168.1.2"(null)
PX_Public_User_Identity_UE1"user1_public1@home1.net"Used in 3GPP environment
PX_Reply_With_Contact_FieldTRUEIf true, use IP address for replies in Contact
PX_Record_Route_1"sip:p1@192.168.1.2" Record route 1
PX_Record_Route_1_LR"sip:p1@192.168.1.2;lr" Record route 1 LR
PX_Record_Route_2"sip:p2@192.168.1.2" Record route 2
PX_Record_Route_2_LR"sip:p2@192.168.1.2;lr" Record route 2 LR
PX_Remove_Branch_RFC_2543_Compatible_ModeFALSE Set to TRUE if no branch is required in Via as per 17.2.3
PX_Use_Accept_EncodingTRUE(null)
PX_Use_Proxy_RequireTRUE(null)
PX_Use_Virtual_UAFALSE(null)
PX_Virtual_UA_Code0(null)
PX_Use_X_NT_GUIDFALSE(null)
PX_Use_X_NT_LocationFALSE(null)
Record_Route_TESTER"" Record-route
Register_Description_TESTER"login" Description contact header for REGISTER messages
Register_Expires_TESTER"expires=86200" Expires contact header for REGISTER messages
Reject_Contact_TESTER"Reject-Contact: sales@xyz.com... Reject-Contact Tester
Request_Disposition_Fork_TESTER"Request-Disposition: fork" Request Disposition Fork
Request_Disposition_Queue_TESTER"Request-Disposition: queue" Request Disposition Queue
Request_Invalid_PX_Proxy_Require_TESTER"Proxy-Require: whatever" Invalid Proxy-Request header value
Request_Invalid_Require_TESTER"Require: whatever" Invalid Request header value
Request_URI_Invalid_URI_TESTER"sip:INVALID@123.123.123.123" Invalid URI
Require_Replaces_TESTER"Require: replaces"(null)
Require_TESTER"" Require
Require_TESTER_Invalid"xyz" Invalid Require
SDP_C_Address_Type_TESTER"IP4" Address type Tester
SDP_C_Network_Type_TESTER"IN" Network type Tester
SDP_M_Attribute_1_TESTER"a=rtpmap:0 pcmu/8000/1" Media PCM µ Law Attribute Tester
SDP_M_Attribute_2_TESTER"a=rtpmap:8 pcma/8000/1" Media PCM A Law Attribute Tester
SDP_M_Attribute_3_TESTER"a=rtpmap:18 g729/8000/1" Media G729 Attribute Tester
SDP_M_Attribute_4_TESTER"a=rtpmap:4 g723.1/8000/1" Media G723.1 Attribute Tester
SDP_M_Attribute_New_TESTER"a=rtpmap:96 eg711u/8000" Media new Attribute Tester
SDP_M_Attribute_OnHold_TESTER"a=sendonly" Media send-only Attribute Tester
SDP_M_Attribute_Unacceptable_TESTER"a=rtpmap:18 g730/8000/1" Media Attribute Unacceptable Tester
SDP_M_Format_1_TESTER"0" Media µ Law Tester
SDP_M_Format_2_TESTER"8" Media A Law Tester
SDP_M_Format_3_TESTER"18" Media G729 Tester
SDP_M_Format_4_TESTER"4" Media new
SDP_M_Format_New_TESTER"96"(null)
SDP_M_Port_TESTER"5008" Media Port Tester
SDP_M_Port_TESTER2"5008" Media Port Tester Link 2
SDP_M_Protocol_TESTER"RTP/AVP" Media Protocol Tester
SDP_Media_LawSDP_Media_Law_Preset_1 Use Media type corresponding to Preset_N e.g. Set to SDP_Media_Law_Preset_1 for SDP_M_Format_1_TESTER & SDP_M_Attribute_1_TESTER Or SDP_Media_Law_Preset_4 for SDP_M_Format_4_TESTER & SDP_M_Atrribute_4_TESTER
SDP_O_Address_Type_TESTER"IP4" IP address type Tester
SDP_O_Network_Type_TESTER"IN" Network type Tester
SDP_O_Session_ID_TESTER"8521" Session ID of Tester
SDP_O_Session_ID_TESTER2"8522" Session ID of Tester on Link 2
SDP_O_Username_TESTER"SOLINET/SAFIRE-UserAgent" Username of Tester
SDP_O_Version_Number_TESTER"32" Version Number of Tester
SDP_S_Session_Name_TESTER"SIP-Call" Session Name Tester
SIP_Torture_Test_Long_Call_Id"kl24ahsd546folnyt2vbak9sad98u...(null)
SIP_Torture_Test_String_2_2_Line_1"INVITE sip:user@company.com S... Torture-test string
SIP_Torture_Test_String_2_2_Line_2"To: sip:j_user@company.com" Torture-test string
SIP_Torture_Test_String_2_2_Line_3"From: sip:caller@university.e... Torture-test string
SIP_Torture_Test_String_2_2_Line_4"Max-Forward: 6" Torture-test string
SIP_Torture_Test_String_2_2_Line_5"Call-ID: 0ha0isndaksdj@10.1.1... Torture-test string
SIP_Torture_Test_String_2_2_Line_6"Require: newfeature1, newfeat... Torture-test string
SIP_Torture_Test_String_2_2_Line_7"Proxy-Require: newfeature3, n... Torture-test string
SIP_Torture_Test_String_2_2_Line_8"CSeq: 8 INVITE" Torture-test string
SIP_Torture_Test_String_2_2_Line_9"Via: SIP/2.0/UDP 135.180.130.... Torture-test string
SIP_Version_TESTERSIP_Version_2 Version used (only supports V2)
Supported_TESTER"" Supported SIP Tester
Supported_TESTER_UE1"path"(null)
T_CALL_ACTIVE_VAL5000 Call duration, time to wait for a response during an Active call
T_INTERVAL_TIMER_VAL1000 Time to wait for possible INVITE retransmission
T_NOACT_VAL10000 Time to wait for No activity
T_T1_VAL550 T1 timer
T_T1_VAL_MAX1000 T1 timer max value
T_T1_VAL_MIN300 T1 timer min value
T_T2_VAL4000 T2 timer, response timeout
T_T4_VAL5000 T4 timer, clean up timeout
T_TIMER_E_VAL500 Timer E value
T_TRANSACTION_TIMER_VAL32000 Timer B (rfc-3261) time to wait for transaction
T_WAIT_ACK_VAL5000 Time to wait for ACK request
T_WAIT_AUTOANSWER_VAL1000 Time to wait for possible autoanswer
T_WAIT_BYE_VAL30000 Time to wait for BYE request
T_WAIT_CANCEL_VAL30000 Time to wait for CANCEL request
T_WAIT_INVITE_VAL30000 Time to wait for INVITE request
T_WAIT_NEXT_PROV_RESPONSE_VAL3000 Time to wait for next provisional response
T_WAIT_OPTIONS_VAL30000 Time to wait for OPTIONS request
T_WAIT_REGISTER_VAL30000 Time to wait for REGISTER request
T_WAIT_RESPONSE_VAL30000 Time to wait for any response after an INVITE
T_WAIT_SEND_CANCEL100 Time to wait before sending a CANCEL
Tag2_TESTER"tag=b4cih" TAG used by the Tester
Tag3_TESTER"tag=c5dji" TAG used by the Tester
Tag4_TESTER"tag=d6ekj" TAG used by the Tester
Tag5_TESTER"tag=e7flk" TAG used by the Tester
Tag6_TESTER"tag=f8gmk" TAG used by the Tester
Tag_TESTER"tag=a3bhg" TAG used by the Tester
Timestamp_TESTER54 Timestamp value
UNACCEPTABLE_PAYLOAD"Unacceptable Description" Unacceptable payload
Unknown_Header_TESTER"Invalid: 6" Unknown header
Unsupported_TESTER"PRACK" Used to generated unsupported method message
User_Agent_TESTER"User-Agent: Nortel PCC 3.0.31... Used to generate unsupported method message
Via_Multiple_Header_TESTER"123.123.123.123:5060" Used in Test Scenario MG_TE_V_010
WWW_Authenticate_TESTER"Digest realm=\"biloxi.com\", ... WWW-Authenticate header to be sent by the Tester
X_NT_GUID_TESTER"x-nt-GUID: f984b8e13343e9e9af...(null)
X_NT_Location2_TESTER"x-nt-location: 71414"(null)
X_NT_Location_TESTER"x-nt-location: 71414"(null)
Subscription_TESTER"presence"(null)
User_Defined_1_Prefix""(null)
User_Defined_2_Prefix""(null)
KeepAliveTRUE(null)

Copyright © ACATS Forum 2009 on behalf of the test suite author. All rights reserved. Specifications may change subject to requirements.

28 Mar 2009Produced by SAFIRE V19.02.10.01
www.SAFIRE-World.com		 Test Suite Overview