Re: [Sipping] Remaining offer/answer issue: how to reject an SDP offer sent in PRACK

[Paul Kyzivat <pkyzivat at cisco.com>]

Christer Holmberg wrote:
> Hi Paul,
>  
>>> Now when we agreed on a way on how to solve the re-INVITE fallback 
>>> issue, one remaining open issue in the offer-answer draft is how to 
>>> reject SDP offers sent in PRACKs.
>>>
>>> I would like to collect ideas on how it could be done.
>>>
>>> NOTE: At this point I DO NOT want to discuss the pros/cons of different 
>>> alternatives, their impacts on existing normative text, or whether they 
>>> work in the first place, but simply do some brainstorming :)
>>>
>>> Some ideas:
>>>
>>> -       Reply 200 OK without SDP answer
>>>
>>> -       Reply with 4xx responses, indicating that the PRACK itself was 
>>> ok, but the SDP offer was rejected
>>>
>>> -       Reply 200 OK with "dummy" SDP answer, then immediately send 
>>> UPDATE with fallback SDP offer
>>>
>>> -       Do not use PRACK for offer/answer in the first place
>>>
>>> -       Stop using 100rel all together (Dean's proposal in the War On 
>>> Forking)
>>>
>>> Some more?
>> 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.)

> 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.

But the response to the PRACK itself could be coming from a proxy. E.g. 
a 407 or a 408. I could see no way to discern which are which.

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.

> 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? While that could 
work, it seems arcane. Its even hard to describe.

	Thanks,
	Paul

> 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