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

Hi Shinji,

I am OK with the new text.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email protected]
===================================



OKUMURA Shinji <[email protected]> 
发件人:  [email protected]
2010-05-12 12:05

收件人
[email protected]
抄送
Paul Kyzivat <[email protected]>
主题
Re: [Sipping] I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt






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 <[email protected]>
Tue, 11 May 2010 10:54:56 -0400
>[email protected] 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 [email protected] for questions on current sip
>Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

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