Hi Shinji,
I am OK with the new text.
Thanks,
Gao
===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : gao.yang2@xxxxxxxxxx
===================================
| OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2010-05-12 12:05 |
|
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
-------------------------------------------------------- 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
