Re: [Sipping] I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt

[OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>]

Hi,

I'll modify these sentences as follows.

   There is a possibility for UAC to receive a 488 response.
   In that case, UAC may send again a PRACK request without an offer
   or send a CANCEL request to terminate the INVITE transaction.

      NOTE: In [RFC3262], the following restriction is defined with
      regard to responding to a PRACK request.

      "If the PRACK does match an unacknowledged reliable provisional
      response, it MUST be responded to with a 2xx response."

      This restriction is not clear.  There are cases where
      it is unacceptable to send a 2xx response.  For example, 401
      response can not be avoided.  This is an open issue and out of
      the scope for this document.

Regards,
Shinji

Paul Kyzivat <pkyzivat@xxxxxxxxx>
Tue, 11 May 2010 10:54:56 -0400
>gao.yang2@xxxxxxxxxx wrote:
>> 
>> Hi Shinji,
>> 
>> 
>>  > IMO, Paul, Christer and I agree with this NOTE.
>>  > And in previous discussions it seems to be agreed.
>>  > Therefore, I think this is not a normative change but a BCP text.
>> 
>> Considering personal feeling or tendency, it is OK. But I just feel in 
>> INFORMATIVE text, it is not proper to put conclusion as parts of RFC3262 
>> is not correct.
>
>Do we agree that the issue here is the following from section 3 of 3262:
>
>    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.
>
>
>Because of the "MUST be responded to with a 2xx response", we would be 
>recommending violation by recommending a 488.
>
>I do agree this is a *bug* in in 3262, since there are cases (such as 
>authorization failures) where it would be entirely unacceptable to send 
>a 2xx response. This case is not *that* bad - it is *possible* to send a 
>2xx, though the outcome from doing so is not so good.
>
>I think I agree with Gao here that we must not *advocate* sending 488 
>here. We might still note that the 488 might be sent anyway, and what to 
>do if it is received.
>
>	Thanks,
>	Paul
>_______________________________________________
>Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>This list is for NEW development of the application of SIP
>Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
>Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP