[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Questions regarding ETSI TIPHON DTS06021-1
Hello,
I have some questions regarding the ETSI TIPHON DTS06021-1 document. I hope, that this is the right forum for these questions. If not, any help, URL or advise is appreciated, where to ask questions regarding DTS06021-1.
I refer to the following version of the document in this mail:
http://docbox.etsi.org/TIPHON/TIPHON/07-drafts/wg6/RTS06021-1[2]/v2.0.12/
Q1:
The test cases SIP_CC_OE_CE_V_016 and SIP_CC_OE_CE_V_023 refer to the 'Calling state' and I could not find any similar test case, which refer to the 'Proceeding' state. IMHO the same tests must be executed also in the 'Proceeding' state, as RFC 3261 states in section 17.1.1.2:
When in either the "Calling" or "Proceeding" states, reception of a
2xx response MUST cause the client transaction to enter the
"Terminated" state, and the response MUST be passed up to the TU.
The handling of this response depends on whether the TU is a proxy
core or a UAC core. A UAC core will handle generation of the ACK for
this response, while a proxy core will always forward the 200 (OK)
upstream. The differing treatment of 200 (OK) between proxy and UAC
Is there any reason, why these test cases are not tested in the 'Proceeding' state?
TPId: SIP_CC_OE_CE_V_016
Status: Mandatory
Ref: 12.2.1.1[1], 13.2.2.4 [1], figure 5 [1], 17.1.1.3 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a Success (200 OK) response sends an ACK request with the same CSeq sequence number as in the original INVITE request and the CSeq method field value set to "ACK".
TPId: SIP_CC_OE_CE_V_023
Status: Mandatory
Ref: 12.2.1.1[1], 13.2.2.4 [1], figure 5 [1]
Purpose: Ensure that the IUT when an INVITE client transaction is in the Calling state, on receipt of a Success (200 OK) response with a Record-Route header set to a list in which the last element does not contain lr parameter, sends an ACK request with the Request-URI set to this element and a Route header set to the remainder list in a reverse order of the received Record-Route appended with the received Contact URI.
Q2:
Why is test case SIP_CC_OE_CE_V_045 only recommended and not mandatory? According to RFC 3261 section 20.14 it should be 'mandatory' for TCP and can be 'recommended' only for UDP, IMHO.
The Content-Length header field indicates the size of the message-
body, in decimal number of octets, sent to the recipient.
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. If a stream-based protocol (such as TCP) is used as
transport, the header field MUST be used.
TPId: SIP_CC_OE_CE_V_045
Status: Recommended
Ref: 20.14 [1], 13.2.1 [1]
Purpose: Ensure that the IUT while is establishing a call, sends a Content-Length header set to the size of the body in the message that contains the session description.
Q3:
Why is test case SIP_CC_TE_CE_V_010 not 'mandatory'? IMHO this test case should be 'mandatory' according to RFC 3261 section 8.2.3:
Assuming the UAS understands any extensions required by the client,
the UAS examines the body of the message, and the header fields that
describe it. If there are any bodies whose type (indicated by the
Content-Type), language (indicated by the Content-Language) or
encoding (indicated by the Content-Encoding) are not understood, and
that body part is not optional (as indicated by the Content-
Disposition header field), the UAS MUST reject the request with a 415
(Unsupported Media Type) response. The response MUST contain an
Accept header field listing the types of all bodies it understands,
in the event the request contained bodies of types not supported by
the UAS. If the request contained content encodings not understood
...
TPId: SIP_CC_TE_CE_V_010
Status: Recommended
Ref: 8.2.3 [1], 13.2.1 [1], 13.3.1 [1], 20.11 [1]
Purpose: Ensure that the IUT on receipt of an INVITE request including a Content-Language header value that it cannot understood, a Content-Disposition header including a handling empty sends an Unsupported Media Type (415 Unsupported Media Type) response with an Accept header that lists the types of all bodies it understands.
Q4:
IMHO there might be a contradiction in test case SIP_CC_PR_MP_RS_V_006, which is valid for stateless proxies: stateless proxies cannot have transactions, so the clause "that does not match to an existing client transaction" should be removed from the test case description.
TPId: SIP_CC_PR_MP_RS_V_006
Status: Mandatory for Stateless
Ref: 16.7 [1], 16.11 [1]
Purpose: Ensure that the IUT, on receipt of a Trying (100 Trying) provisional response that does not match to an existing client transaction, removes the topmost via from the response and forwards it to the address indicated in the next Via header.
Any help, URL or reference regarding any of the questions would be highly appreciated.
Thank you in anticipation,
Szelenyi Csaba
T-Systems RIC
mailto:Csaba.Szelenyi@t-systems.co.hu
+36 1 456 5507
+36 20 477 7778
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip