Re: Remaining offer/answer issue: how to reject an SDP offer sent in PRACK
Paul Kyzivat <pkyzivat <at> cisco.com>
2008-10-02 19:30:52 GMT
Christer Holmberg wrote:
> Hi,
>
>>> Your suggestion looks ok.
>>>
>>> But, do we need to say something for the UAS when it sends 488? Should
>
>>> it keep re-transmitting the 18x (SINCE there will be another PRACK
>>> sent anyway), or should it cease re-transmitting the 18x (EVENTHOUGH
>>> there will be another PRACK sent anyway)?
>> IMO there is nothing special about 488. The PRACK has failed,
>> so it has not acknowledged the response, so the response
>> keeps being retransmitted.
>
> But, would it harm if the UAS was allowed to cease the retransmission?
> Of course, the UAS has to be prepared to receive the PRACK, and respond
> with a 200 OK as if it was still retransmitting the 18x.
I don't know if it would harm or not. I'm not an expert in the state
machines, etc. Maybe Robert can say. But do we want to open pandora's
box by adding another complication to the state machines? Or at least to
the PRACK processing? How do you distinguish a PRACK that you are
expected even though you already had the 1xx acknowledged from one that
isn't expected at all.
Just seems simpler to treat it as a real error.
Thanks,
Paul
> Regards,
>
> Christer
>
>
>
>
>
>
>
>>>> -----Original Message-----
>>>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>>>> Sent: 2. lokakuuta 2008 18:22
>>>> To: Christer Holmberg
>>>> Cc: sipping LIST
>>>> Subject: Re: VS: [Sipping] Remaining offer/answer issue: how to
>>>> reject an SDP offer sent in PRACK
>>>>
>>>> We need to reach closure on this.
>>>>
>>>> My proposal is that we just remove the constraints against
>> rejecting
>>>> a PRACK. So if a PRACK contains an unacceptable offer, send a 488
>>>> response, and consider that the response still has not been
>>>> acknowledged. A UA that receives an error on a PRACK that it sent
>>>> must retry it it a way that is likely to work. In a case
>> of a PRACK
>>>> that failed with a 488, retrying with no SDP is the recommended
>>>> approach.
>>>> Then if there is still need to send another offer, it can be sent
>>>> with UPDATE. (But it will probably need to be a different
>> offer or it
>>>> will likely fail again.)
>>>>
>>>> I guess this needs to be an update to 3262.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> Christer Holmberg wrote:
>>>>> Hi Paul,
>>>>>
>>>>>>>> There are no perfect choices here.
>>>>>>>>
>>>>>>>> What is wrong with just returning any appropriate error
>>>> response -
>>>>> e.g. 488?
>>>>>>> That is the second alternative in my list.
>>>>>>>
>>>>>>>> The main problem with that is whether it did/didn't ack
>>>> the response.
>>>>>>>> After considering alternatives, ISTM that this should
>> then also
>>>>>>>> mean that the reliable response has not yet been
>>>> acknowledged, and
>>>>>>>> so another PRACK must be sent - preferably one without
>> an offer.
>>>>>>> ...or, we could define that a 488 must not be sent for
>>>> PRACK unless
>>>>> the reliable response was acknowledged.
>>>>>> I thought about trying to classify responses as to whether
>>>> they imply
>>>>> that the response has been acked or not. (Obviously 200
>>>> does. You are
>>>>> proposing that 488 should. Most likely there would be
>>>>>> others.)
>>>>> Or, as I suggested, instead of the response code we use the RSeq
>>>>> header to indicate whether the response has been acked or
>>>> not. Maybe
>>>>> that would be more "safe".
>>>>>
>>>>>
>>>>>>> But, I guess one potential issue with that is that if is an
>>>>> intermediate, and not the endpoint sending the reliable
>> responses,
>>>>> which sends the 488 then the reliable responses will keep coming
>>>>>>> (since the endpoint sending the reliable responses never got the
>>>>> PRACK).
>>>>>> Allowing intermediates (proxies) to send reliable responses is a
>>>>> *terrible* idea. I thought we had already excluded that.
>>>>>
>>>>> What I meant was that a UAS is sending the reliable
>> response. But,
>>>>> then an intermediate rejects the PRACK with 488 (because it
>>>> contains
>>>>> an offer the intermediate doesn't like). In this case the
>> UAS will
>>>>> keep re-transmitting the reliable response, so the UAC
>> will have to
>>>>> send a new PRACK (without SDP).
>>>>>
>>>>>> I propose it is better for the UAC to assume that any failure
>>>>>> response
>>>>> to a PRACK requires a new PRACK to be sent to ack the response.
>>>>>
>>>>> But, what IF the first PRACK actually acknowledged the reliable
>>>>> response? In that case I guess the UAS may send a 481 to
>> the second
>>>>> PRACK? Will the UAC just accept it and "move on"?
>>>>>
>>>>> But, in any case, I will document this
>>>> send-a-new-PRACK-without-SDP as
>>>>> one option.
>>>>>
>>>>>
>>>>>>> Maybe we could specify that the RSeq header shall be
>>>> included in the
>>>>> PRACK response, to indicate that the relaible response
>> has NOT been
>>>>> acknowledged yet?
>>>>>> ???
>>>>>>
>>>>>> So you are suggesting that something special be added to
>> a non-200
>>>>> PRACK response to acknowledge the PRACK while rejecting it?
>>>>>
>>>>> Yes. Today, neither RSeq nor RAck are inserted in the PRACK
>>>> response.
>>>>> So, an RSeq in the non-200 PRACK response would have the
>>>> same meaning
>>>>> as in a reliable provisional resonse: "Hey, this is the seq
>>>> number you
>>>>> have to send a PRACK for".
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Paul
>>>>>>
>>>>>>> Personally I don't see a
>>>>>>> make-sure-you-send-an-offer-which-will-not-be-rejected
>>>> alternative
>>>>>>> as
>>>>>>> feasible, because the UAS may want to reject the offer based on
>>>>>>> other circumstances (e.g. overload).
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>> --------------------------------------------------------------------
>>>>>>> -
>>>>>>> ---
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Sipping mailing list
>>>> https://www.ietf.org/mailman/listinfo/sipping
>>>>>>> This list is for NEW development of the application of SIP Use
>>>>>>> sip-implementors <at> cs.columbia.edu for questions on
>> current sip Use
>>>>>>> sip <at> ietf.org 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 <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
RSS Feed