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

["Christer Holmberg" <christer.holmberg at ericsson.com>]

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