Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

[Takuya Sawada <[e-mail]>]

Hi,

Now I think we can reach the agreement to add Christer's text.
I have already done it.

How about Brett's proposal on PRACK 488?
I don't think we can reach the consensus on PRACK 488 behaviour.
Christer proposed to make separate document to define 'new' normative
behaviour. We may need more discussion.
Then IMO, for the time being, "PRACK request should not be rejected"
approach seems to be good and Christer's text and proposal can hopefully
cover your concern.

Regards,
Takuya

> The following reflects my analysis of rfc3262 concerning PRACK failure
> responses.  My recommendations concerning sipping-sip-offeranswer-05 are
> discussed within the last section.
> 
> -----
> 
> This section reflects analysis indicating support for PRACK failure
> responses and requirement for UAC to handle them appropriately.  When
> appropriate, the failure responses should trigger resubmission of PRACK
> with higher CSeq (unless 503 triggers rfc3263 advancing) and appropriate
> header/body modifications.
> 
> Tables 1 and 2 indicate that failure responses to PRACK were considered
> and are allowed.
> 
> Proxies can return failure responses.  Thus the UAC should not assume
> the PRACK has been processed by the device awaiting PRACK unless the
> response (such as 2xx or 481) provides such indication.
> 
> RFC 3262 section 4: "Note that the PRACK is like any other non-INVITE
> request within a dialog."
> 
> RFC 3262 section 3: "PRACK is like any other request within a dialog,
> and the UAS core processes it according to the procedures of Sections
> 8.2 and 12.2.2 of RFC 3261."
> 
> -----
> 
> This section reflects analysis concerning text within rfc3262 which
> supports treating PRACK more like an ACK instead of other requests
> within a dialog (such as an UPDATE).  This interpretation requires UAS
> to avoid sending failure responses and/or allowing the 100rel
> "acknowledgment" to be based upon receiving PRACK instead of the
> returning of PRACK 2xx.  In my opinion, both of these potential
> interpretations require the text to be interpreted out of context.
> 
> RFC 3262 section 3: "If the PRACK instead contained any other type of
> body, the body is treated in the same way that body in an ACK would be
> treated."  I think it is just a text error since prior text refers to a
> section of rfc3261 which might trigger a 415 response.  And the 415 is
> clearly indicated within rfc3262 table 1.
> 
> RFC 3262 section 3: "If a PRACK request is received by the UA core that
> does not match any unacknowledged reliable provisional response, the UAS
> MUST respond to the PRACK with a 481 response.  If the PRACK does match
> an unacknowledged reliable provisional response, it MUST be responded to
> with a 2xx response.  The UAS can be certain at this point that the
> provisional response has been received in order.  It SHOULD cease
> retransmissions of the reliable provisional response, and MUST remove it
> from the list of unacknowledged provisional responses."  My
> interpretation is that this paragraph does not preempt prior paragraphs
> concerning processing like any other request within a dialog.  However I
> might be missing a subtle difference between this RFCs use of "UA core"
> and "UAS core".
> 
> RFC 3262 section 3: "Retransmissions of the reliable provisional
> response cease when a matching PRACK is received by the UA core." <snip>
> "If a reliable provisional response is retransmitted for 64*T1 seconds
> without reception of a corresponding PRACK, the UAS SHOULD reject the
> original request with a 5xx response."  When read together,
> "retransmitted" could indicate that receiving PRACK
> completes/acknowledges the 100rel transaction instead of it being
> completed/acknowledged by the sending the PRACK 2xx.  However I think
> that it is just an unfortunate use of "retransmitted"; although the
> "retransmitted" aspects could also be reflecting the normative statement
> about stopping retry when sending PRACK 2xx instead of the non normative
> statement "cease when a matching PRACK is received by the UA core".
> 
> -----
> 
> I think the following changes should be made to
> sipping-sip-offeranswer-05.  The text can be discussed after rfc3262
> detailed analysis by Paul, Christer, and others.
> 
> I think that the draft should mention PRACK 488 response within section
> 2.2.
> 
> Concerning "PRACK request should not be rejected" within sections 3.2
> and 4.1, I don't think such a statement should be made without
> clarification somewhere concerning the reason. 
> 
> I think that the draft should mention PRACK 488 response within section
> 6.1.  

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: [phone]
Fax: [phone]
[e-mail]

------------------------------------------------------------------
注意：この電子メールには、KDDI株式会社の機密情報が含まれている
      場合が有ります。正式なメール受信者でない場合、メール複製、
　　　再配信または情報の使用を固く禁じております。
      エラー、手違い等でこのメールを受け取られましたら、お手数を
　　　おかけ致しますが、削除を行い配信者に連絡をお願い致します。
NOTE: This electronic mail message may contain confidential and
　　　privileged information from KDDI Corporation. If you are
　　　not the intended recipient, any disclosure, photocopying,
      distribution or use of the contents of the received
      information is prohibited. If you have received this e-mail
      in error, please notify the sender immediately and
    　permanently delete this message and all related copies.
-------------------------------------------------------------------

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP