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
