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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2008 11:22:21 -0400

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 
>>> [email-masked] for questions on current sip Use 
>>> [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Oct 2008 19:29:42 +0200

Hi Paul,

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)?

Regards,

Christer 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> 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
> 
> 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.)
> 
> >>>> 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, 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".
> > 
> > 
> > intermediate, and not the endpoint sending the reliable responses, 
> > which sends the 488 then the reliable responses will keep coming
> > 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).
> > 
> > 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
> > 
> >>> Sipping mailing list  
> https://www.ietf.org/mailman/listinfo/sipping

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2008 14:17:21 -0400

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

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Oct 2008 20:25:34 +0200

Hi, 

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

Regards,

Christer

> >> Subject: Re: VS: [Sipping] Remaining offer/answer issue: how to 
> >> reject an SDP offer sent in PRACK
> >>
> rejecting 
> >> a PRACK. So if a PRACK contains an unacceptable offer, send a 488 
> >> 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.)
> >>
> >>>>> feasible, because the UAS may want to reject the offer based on 
> >>>>> other circumstances (e.g. overload).
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Oct 2008 15:30:52 -0400

> 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

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 2 Oct 2008 22:20:20 +0200

>>>>here will be another PRACK sent anyway)?

When the UAS receives the first PRACK, for which it sends 488, it stores the RAck value. Then, when it receives the second PRACK, it will have the same RAck value. This could be an optional feature.

Earlier I also proposed that the RSeq value could have been added to the 488, indicating that the retransmission was ceased. Then the UAC would know that the second PRACK isn't needed. But, that is of course a bigger change.

Regards,

Christer 

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Fri, 3 Oct 2008 09:23:54 -0500

inline

On Oct 2, 2008, at 2:30 PM, Paul Kyzivat wrote:

>>>> 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.
> machines, etc. Maybe Robert can say.

Unless I'm missing something, this isn't down in the transaction state  
machines - the 3262 provisional retransmissions happen in the TU.

What you're talking about is, I think, scoped to changing exactly the  
logic in the TU that 3262 defines. While you might break that  
horribly, I think you're safe from breaking things outside that box.  
Inside that box, a design decision was made during the creation of  
3262 to punt on the mechanics of recovering from PRACK errors. There  
will be some careful work to do if you let this one in, but I think it  
could be successfully done. (I assume the proposal is to add just this  
code, not open PRACK up to any error, yes?).

> 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.
>
>>>>> 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
>>>>> sent with UPDATE. (But it will probably need to be a different
>>> offer or it
>>>>> will likely fail again.)
>>>>>
>>>>>> 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
>>>>>>>> feasible, because the UAS may want to reject the offer based  
>>>>>>>> on other circumstances (e.g. overload).
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Christer
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Use [email-masked] for questions on
>>> current sip Use

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Oct 2008 11:14:34 -0400

Robert Sparks wrote:
>>>>> sent anyway), or should it cease re-transmitting the 18x 
>>>> IMO there is nothing special about 488. The PRACK has failed, so it 
>>>> has not acknowledged the response, so the response keeps being 
>>>> retransmitted.
> logic in the TU that 3262 defines.

Perhaps.

My initial thought was that if we allow a failing PRACK to stop 
retransmission, we would still need to keep the transaction around as 
reference for handling another PRACK. But perhaps that can be handled 
another way.

I did think about having the failing PRACK still be treated as 
indicating ack of the transaction, so that there is no need to 
retransmit it. (I think that was one of Christer's proposals.) But the 
more I thought about it the more messy it got. The problem being that 
the PRACK might be rejected before reaching the UAS. If so it definitely 
won't ack the transaction. So the UAC needs to sort out which errors are 
certain to have come from the UAS and which might not. That was just too 
ugly for me to consider acceptable.

Since I made my proposal, I think Christer is proposing that the UAS can 
consider the transaction ack'ed when rejecting the PRACK, but the UAC 
won't, and will still retransmit it. But in that case when it arrives at 
the UAS, there won't be any matching transaction. So the PRACK will fail 
again with a 481. But that PRACK might have had a revised offer in it. 
If it did, then it too would fail. I was thinking that to fix this the 
transaction that was ack'ed by the failing PRACK would have to stick 
around waiting for further PRACKs. But that seems like a really bad idea.

> While you might break that horribly, 
> I think you're safe from breaking things outside that box. Inside that 
> box, a design decision was made during the creation of 3262 to punt on 
> the mechanics of recovering from PRACK errors. There will be some 
> careful work to do if you let this one in, but I think it could be 
> successfully done.

I'm glad to hear that.

> (I assume the proposal is to add just this code, not 
> open PRACK up to any error, yes?).

No. My thought was to open it up for a variety of errors, though I'm 
sure there are a lot of errors that won't make any sense.

As soon as you open it to one, I don't see the point of restricting it. 
For instance, 407 seems like an error that could occur. 580 also seems a 
possibility.

	Thanks,
	Paul

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

---

From: Robert Sparks <[email-masked]>
Date: Fri, 3 Oct 2008 11:05:13 -0500

On Oct 3, 2008, at 10:14 AM, Paul Kyzivat wrote:

>>>>> it has not acknowledged the response, so the response keeps  
>>>>> being retransmitted.
>>> I don't know if it would harm or not. I'm not an expert in the  
>>> state machines, etc. Maybe Robert can say.
>> Unless I'm missing something, this isn't down in the transaction  
>> state machines - the 3262 provisional retransmissions happen in the  
>> TU.
>> What you're talking about is, I think, scoped to changing exactly  
>> the logic in the TU that 3262 defines.
>
> Perhaps.
>
> retransmission, we would still need to keep the transaction around  
> as reference for handling another PRACK. But perhaps that can be  
> handled another way.

I must be a little confused - I _thought_ you were talking about  
stopping retransmission of the 18x. The transaction it's involved in  
is very much still going to be around if you decide to do that (until  
you get a final response or the TU decides for some other reason to  
bail out of the transaction). Did I miss the boat completely? If so,  
what was it you were talking about not retransmitting?

> retransmit it. (I think that was one of Christer's proposals.) But  
> the more I thought about it the more messy it got.
Agreed
> The problem being that the PRACK might be rejected before reaching  
> the UAS. If so it definitely won't ack the transaction.
you mean the "acknowledge receipt of the provisional response" more  
than you mean transaction here I think?

> So the UAC needs to sort out which errors are certain to have come  
> from the UAS and which might not. That was just too ugly for me to  
> consider acceptable.
>
> Since I made my proposal, I think Christer is proposing that the UAS  
> can consider the transaction ack'ed when rejecting the PRACK, but  
> the UAC won't, and will still retransmit it. But in that case when  
> it arrives at the UAS, there won't be any matching transaction. So  
> the PRACK will fail again with a 481. But that PRACK might have had  
> a revised offer in it. If it did, then it too would fail. I was  
> thinking that to fix this the transaction that was ack'ed by the  
> failing PRACK would have to stick around waiting for further PRACKs.  
> But that seems like a really bad idea.
>
>> While you might break that horribly, I think you're safe from  
>> breaking things outside that box. Inside that box, a design  
>> decision was made during the creation of 3262 to punt on the  
>> mechanics of recovering from PRACK errors. There will be some  
>> (I assume the proposal is to add just this code, not open PRACK up  
>> to any error, yes?).
>
> As soon as you open it to one, I don't see the point of restricting  
> it. For instance, 407 seems like an error that could occur. 580 also  
> seems a possibility.
407 are part of the equation  already - Proxies don't know PRACK from  
ADAM.
The place where you'd be introducing change is in the logic in the  
UAS's TU - right now the spec has a pretty simplistic model that  
doesn't allow for the PRACK to be rejected. If you allow it to be  
rejected, you have to go work what that means into the model.

>
>
> 	Thanks,
> 	Paul
>
>>> 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.
>>>
>>>>>>> 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.
>>>>>>>> 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
>>>>>>>>>> feasible, because the UAS may want to reject the offer  
>>>>>>>>>> based on other circumstances (e.g. overload).
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Christer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Oct 2008 13:23:22 -0400

Robert Sparks wrote:
>>> state machines - the 3262 provisional retransmissions happen in the TU.
> stopping retransmission of the 18x. The transaction it's involved in is 
> very much still going to be around if you decide to do that

Duh. Yes. Stupid on my part.

> (until you 
> get a final response or the TU decides for some other reason to bail out 
> of the transaction). Did I miss the boat completely? If so, what was it 
> you were talking about not retransmitting?

I agree it doesn't really require changes to the transaction state 
machine. But it does impact the state required in support of reliable 
provisionals - the list of unacknowledged reliable provisionals.

>> indicating ack of the transaction, so that there is no need to 
                          provisional
>> more I thought about it the more messy it got.
> Agreed
>> The problem being that the PRACK might be rejected before reaching the 
>> UAS. If so it definitely won't ack the transaction.
> you mean the "acknowledge receipt of the provisional response" more than 
> you mean transaction here I think?

Yup. Still my bad.

>> can consider the transaction ack'ed when rejecting the PRACK, but the 
>> UAC won't, and will still retransmit it. But in that case when it 
>> arrives at the UAS, there won't be any matching transaction. So the 
>> PRACK will fail again with a 481. But that PRACK might have had a 
>> revised offer in it. If it did, then it too would fail. I was thinking 
>> that to fix this the transaction that was ack'ed by the failing PRACK 
>> would have to stick around waiting for further PRACKs. But that seems 
>> like a really bad idea.
>>
>>> breaking things outside that box. Inside that box, a design decision 
>>> was made during the creation of 3262 to punt on the mechanics of 
>>> recovering from PRACK errors. There will be some careful work to do 
>>> if you let this one in, but I think it could be successfully done.
>>
>> I'm glad to hear that.
>>
>>> (I assume the proposal is to add just this code, not open PRACK up to 
>>> any error, yes?).
>>
> 407 are part of the equation  already - Proxies don't know PRACK from ADAM.
> The place where you'd be introducing change is in the logic in the UAS's 
> TU - right now the spec has a pretty simplistic model that doesn't allow 
> for the PRACK to be rejected. If you allow it to be rejected, you have 
> to go work what that means into the model.

Yes.
Thanks for clarifying my fuzzy reasoning.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 4 Oct 2008 00:17:05 +0200

I think I fell off the wagon. What is the outcome? :)

Let's see where we are:

Paul's proposal is to allow SDP offers in PRACKs to be rejected with
488. I agree to that proposal, and I have heard no objections to it.

Paul's proposal was also that a 488 response would require a new PRACK
(possibly without SDP, or with a modified SDP) to be sent by the UAC. Ie
when the UAS sends a 488 response it must be prepared to receive a new
PRACK for the specific 18x.

The "optimization" questions I had were:

1. Even if the UAS, when sending 488, must be prepared to receive a new
PRACK, would it still be allowed to cease the retransmission of the 18x
when sending the 488? After all, who could prevent it from doing so? :)

2. Could the UAS use the Rseq/Rack header in the 488 to indicate that it
DID cease the retransmission of the 18x, so that the UAC would not need
to send a new PRACK? I don't that would complicate any state machine,
because the UAS would do exactly what it does when sending 200 for the
PRACK. If the 488 does NOT contain the Rseq/Rack header, the UAC can
assume the response was sent by an intermediate, so it must send a new
PRACK.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, October 03, 2008 8:23 PM
To: Robert Sparks
Cc: Christer Holmberg; sipping LIST
Subject: Re: [Sipping] Remaining offer/answer issue: how to reject an
SDP offer sent in PRACK

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

> is very much still going to be around if you decide to do that

> (until you
> get a final response or the TU decides for some other reason to bail 
> out of the transaction). Did I miss the boat completely? If so, what 
> was it you were talking about not retransmitting?

                          provisional

Yup. Still my bad.

>> revised offer in it. If it did, then it too would fail. I was 

ADAM.

Yes.

	Thanks,
	Paul

>>>>>>>>>>> (since the endpoint sending the reliable responses never got

>>>>>>>>>>> the
>>>>>>>>>> I propose it is better for the UAC to assume that any failure

>>>>>>>>>> response
>>>>>>>>> reliable response? In that case I guess the UAS may send a 481

>>>>>>>>> to

>>>>>> -----------------------------------------------------------------
>>>>>> ---
>>>>>>>>>>> -
>>>>>>>>>>> ---
>>>>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Oct 2008 23:37:23 -0400

My feeling is that either of the optimizations you suggest *could* be 
done, requiring different variations on the state that must be retained.

I just question whether the added complexity, in the spec and the 
implementation, is worth the effort.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 5 Oct 2008 05:52:15 +0200

Hi, 

>My feeling is that either of the optimizations you suggest *could* be
done, requiring different variations on the state 
>that must be retained.

The advantage with 1) is that the UAS can cease the retransimisson of
the 18x as soon as it receives the PRACK request - before it knows what
the answer is going to be.

But, I think the possibiliy to do that could be mentioned as a note, or
something. The immportant think is the UAS processes the subsequent
PRACK for the same 18x correctly.

I don't think 2) would add much more complexity, but I agree that does
extend the usage of the Rseq/Rack header(s).

Regards,

Christer

> (possibly without SDP, or with a modified SDP) to be sent by the UAC. 
> Ie when the UAS sends a 488 response it must be prepared to receive a 
> new PRACK for the specific 18x.
> 
> 
> 1. Even if the UAS, when sending 488, must be prepared to receive a 
> new PRACK, would it still be allowed to cease the retransmission of 
> the 18x when sending the 488? After all, who could prevent it from 
> doing so? :)
> 
> 
> 2. Could the UAS use the Rseq/Rack header in the 488 to indicate that 
> it DID cease the retransmission of the 18x, so that the UAC would not 
> need to send a new PRACK? I don't that would complicate any state 
> machine, because the UAS would do exactly what it does when sending 
> 200 for the PRACK. If the 488 does NOT contain the Rseq/Rack header, 
> the UAC can assume the response was sent by an intermediate, so it 
> must send a new PRACK.
> 
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>>>>>>>> But, do we need to say something for the UAS when it sends 488?

>>>>>>>> Should

>>>>>>> being

>>>> decision

>>>>> complication

>>>>>>>>> been
>>>>>>>>> recommended
>>>>>>>>>> 481
>>>>>>>>>>>> based

---

From: "Bram Verburg" <[email-masked]>
Date: Sun, 5 Oct 2008 15:45:03 +0200

Correct me if I'm wrong, but I believe option (2) would re-introduce a
potential SDP offer glare situation that this draft is trying to
resolve.

Section 4.2 states that the UAS should not send an offer while the
acknowledgement of a response is still pending, to avoid having to
reject the PRACK with a 491 response. (This is in line with 3262
recommending not to send another reliable provisional response, or 200
response, until a pending reliable provisional response is acknowledged)

Optimization (2) below, while potentially eliminating a PRACK/200
message round trip, leaves the UAS in a state where it cannot know
whether the UAC will send another PRACK with an updated SDP offer. After
all, there is no way for the UAS to know whether the UAC implements this
optimization as well. The UAS would have to continue on the assumption
that no new PRACK will arrive, which means it can send a new offer
anytime, even if the UAC does intend to send an updated offer in the new
PRACK.

Regards,

Bram

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Christer Holmberg
> Sent: Sunday, October 05, 2008 5:52 AM
> To: Paul Kyzivat
> Cc: sipping LIST
SDPoffer
> sent in PRACK
so
> >>>>>>>>> sent with UPDATE. (But it will probably need to be a
different
> >>>>>>>>>>> Allowing intermediates (proxies) to send reliable
responses
> >>>>>>>>>>> is a
----------------------------------------------------------------

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 07:32:55 +0200

Hi, 

>Correct me if I'm wrong, but I believe option (2) would re-introduce a
potential SDP offer glare situation that this 
>draft is trying to resolve.
>
acknowledgement of a response is still pending, to
>avoid having to reject the PRACK with a 491 response.
>
>(This is in line with 3262 recommending not to send another reliable
provisional response, or 200 response, until a 
>pending reliable provisional response is acknowledged)

I am not sure I understand. Option (2) is not talking about an UAS
sending on offer.

Option (2) is about whether the UAS, when it rejects an SDP offer in a
PRACK, can still indicate that the provisional response associated with
the PRACK has been acknowledged, or whether only a 200 OK response to a
PRACK can be used to indicate that.

>Optimization (2) below, while potentially eliminating a PRACK/200
message round trip, leaves the UAS in a state where it
>cannot know whether the UAC will send another PRACK with an updated SDP
offer. After all, there is no way for the UAS to >know whether the UAC
implements this optimization as well. The UAS would have to continue on
the assumption that no new 
>PRACK will arrive, which means it can send a new offer anytime, even if
the UAC does intend to send an updated offer in 
>the new PRACK.

This has nothing to do with the offer/answer state. The 488 rejects the
SDP offer - period. The UAC may, or may not, send a new SDP offer after
that, but the UAS doesn't need to know whether that is going to happen.

BUT, if the UAS does not cease retransmission of the 18x when it sends
488 to the PRACK, the UAS will have to assume there will be another
PRACK (with or without SDP) for the same 18x.

Regards,

Christer

Regards,

Bram

Behalf Of
SDPoffer

so

different

> >>>>>>>>>> RSeq header to indicate whether the response has been acked

> >>>>>>>>>> or
responses

---

From: "Bram Verburg" <[email-masked]>
Date: Mon, 6 Oct 2008 07:59:49 +0200

Hi,

I was referring to this section (from 4.2) of the draft:

  When offer2 is in a PRACK request (within the current rules, only
  possible if offer1 is in an UPDATE request), the PRACK may be
  accepted with 200 or may be rejected with a 491 response. A 491
  response is valid to satisfy the offer/answer model but it may
  delay the completion of the reliable response transfer mechanism or,
  in worst case, may result in the failure to complete the SIP
  transaction because there is no clear retry rule when a PRACK
  request is rejected with a 491 response. To avoid this glare
  condition, UA A should not send an offer if it has already sent a
  reliable provisional response containing an answer to a previous
  offer and has not received the corresponding PRACK request.

It tries to avoid a glare situation by requiring the UAS to postpone its
next offer until any pending reliable responses have been acknowledged.
What I was trying to establish is whether the PRACK that gets rejected
with a 488 is considered an acknowledgement for this purpose.

I think we can all agree that receiving any PRACK is sufficient to stop
retransmissions. But rejecting the PRACK with 488 may trigger another
one, possibly with a new SDP. So in order to avoid the glare situation
described above, the UAS should still not consider the response to be
fully acknowledged, and it should not send an offer (e.g. in a 200
response) until it is.

If a UAC implements option (2) there won't be a new PRACK, so if the UAS
follows the above recommendation, the UAS will never send its next
offer. Or, if the UAS implements (2) but the UAS doesn't, there is the
possibility of glare. (2) only works reliably if both sides implement
it.

Regards,

Bram 

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, October 06, 2008 7:33 AM
> To: Bram Verburg; Paul Kyzivat
> Cc: sipping LIST
> Subject: RE: [Sipping] Remaining offer/answer issue: how to reject an
SDPoffer
> > > Ie when the UAS sends a 488 response it must be prepared to
receive
> a
> > >>>> recovering from PRACK errors. There will be some careful work
to
> do
> > >>>>> to the state machines? Or at least to the PRACK processing?
How
> do
> > >>>>> already had the 1xx acknowledged from one that isn't expected
at
> > > all.
> > >>>>>>>>> a PRACK. So if a PRACK contains an unacceptable offer,
send
> a
> > >>>>>>>>>>>>> What is wrong with just returning any appropriate
error
> > >>>>>>>>> response -
> > >>>>>>>>>>>>> The main problem with that is whether it did/didn't
ack
> > >>>>>>>>> the response.
> > >>>>>>>>>>> I thought about trying to classify responses as to
whether
> > >>>>>>>>> they imply
> > >>>>>>>>>>>> But, I guess one potential issue with that is that if
is
> an
> > >>>>>>>>>>>> (since the endpoint sending the reliable responses
never
> > >>>>>>>>>>>> got
> > >>>>>>>>>> Yes. Today, neither RSeq nor RAck are inserted in the
PRACK
> > >>>>>>>>> response.

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Oct 2008 10:16:16 -0400

> My proposal is that we just remove the constraints 
> against rejecting a PRACK. 

As mentioned within earlier threads, I agree.

http://www.ietf.org/mail-archive/web/sipping/current/msg15031.html

> 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 in a way 
> that is likely to work. 

I agree; however the UAC is free to give up trying and send CANCEL (or
BYE) when appropriate.

> 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 

Since RFC 3262 has potentially conflicting text (see following thread),
something is required to address the issue.  If clarification within
draft-ietf-sipping-sip-offeranswer isn't adequate, I agree something
needs to update RFC 3262.

http://www.ietf.org/mail-archive/web/sipping/current/msg15146.html

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Oct 2008 10:24:41 -0400

I agree with Paul.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Friday, October 03, 2008 11:37 PM
> To: Christer Holmberg
> Cc: sipping LIST
> Subject: Re: [Sipping] Remaining offer/answer issue: how to 
> My feeling is that either of the optimizations you suggest 
> *could* be done, requiring different variations on the state 
> that must be retained.
> 
> I just question whether the added complexity, in the spec and 
> the implementation, is worth the effort.
> 
> 	Thanks,
> 	Paul
> 
> Christer Holmberg wrote:
> receive a 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Oct 2008 21:22:16 +0200

Hi, 

>It tries to avoid a glare situation by requiring the UAS to postpone
its next offer until any pending reliable responses 
>have been acknowledged.
with a 488 is considered an acknowledgement for 
>this purpose.
retransmissions. But rejecting the PRACK with 488 
>may trigger another one, possibly with a new SDP. So in order to avoid
the glare situation described above, the UAS 
>should still not consider the response to be fully acknowledged, and it
should not send an offer (e.g. in a 200
>response) until it is.
>
>If a UAC implements option (2) there won't be a new PRACK, so if the
UAS follows the above recommendation, the UAS will 
>never send its next offer. Or, if the UAS implements (2) but the UAS
doesn't, there is the possibility of glare. (2) only 
>works reliably if both sides implement it.

True. But, we have to assume that people implement what we specify.

Regards,

Christer

SDPoffer

receive

to

How
at
send

error
ack
whether
is
> > >>>>>>>>>> which sends the 488 then the reliable responses will keep

> > >>>>>>>>>> coming
never
PRACK

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Oct 2008 16:20:36 -0400

> PRACK for the same 18x correctly.

So you are saying that this is a *local* optimization that the UAS may 
do, and that the UAC need not know about - that the presence or absence 
of the retransmissions won't alter the behavior of the UAC. Right?

I guess this is true.

It would require additional state to be kept at the UAS. It still needs 
to keep a record of the response, so it can handle the new PRACK when it 
arrives, but it must now also remember that retransmission should not 
occur. Admittedly this is a very small amount of added state. Its not so 
much a complexity of implementation issue, its just that then we must 
document this additional behavior so that it is legal. It needs 
normative text, not just a note.

> extend the usage of the Rseq/Rack header(s).

Again, its just a matter of spec complexity. One more thing to agree 
upon and write down.

I would not object if this stuff ended up being in there. But I'm not 
enthused about adding it.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Oct 2008 23:43:38 +0200

Hi, 

>the 18x as soon as it receives the PRACK request - before it knows 
>what the answer is going to be.
> 
>But, I think the possibiliy to do that could be mentioned as a note, 
>or something. The immportant think is the UAS processes the subsequent 
do, and that the UAC need not know about - that>the presence or absence
of the retransmissions won't alter the behavior of the UAC. Right?

Correct.

>It would require additional state to be kept at the UAS. It still needs
to keep a record of the response, so it can 
>handle the new PRACK when it arrives, but it must now also remember
that retransmission should not occur.
>
>Admittedly this is a very small amount of added state. Its not so much
a complexity of implementation issue, its just 
>that then we must document this additional behavior so that it is
legal. It needs normative text, not just a note.

Ok.

Regards,

Christer

upon and write down.

	Thanks,
	Paul

>>>>> careful work to do

>>>>>> processing? How do
>>>>>>>>>> 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
>>>>>>>>>>>> Allowing intermediates (proxies) to send reliable responses

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 14 Oct 2008 08:26:57 +0200

Hi, 

>So you are saying that this is a *local* optimization that the UAS may
do, and that the UAC need not know about - that the presence or 
>absence of the retransmissions won't alter the behavior of the UAC.
Right?

Correct.

I was reading the PRACK RFC during the weekend, and the current text
DOES talk about stopping the 18x re-transmission when the PRACK is
received - before any PRACK response has been sent.

Now, whether that is based on the current assumption that a 200 will
always be sent for PRACK I don't know, but I don't think we should
prevent the cease of the 18x re-transmission.

>It would require additional state to be kept at the UAS. It still needs
to keep a record of the response, so it can handle the new PRACK 
>when it arrives, but it must now also remember that retransmission
should not occur. Admittedly this is a very small amount of added state.

>Its not so much a complexity of implementation issue, its just that
then we must document this additional behavior so that it is legal. It 
>needs normative text, not just a note.

Ok.

upon and write down.

I think we should focus on 1) first, and how to document it.

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Oct 2008 15:00:37 -0400

> I was reading the PRACK RFC during the weekend, 
> and the current text DOES talk about stopping 
> the 18x re-transmission when the PRACK is 
> Now, whether that is based on the current 
> assumption that a 200 will always be sent for 
> PRACK I don't know, but I don't think we should 

Concerning stopping retries, the following link presents my
understanding rfc3262.

> I think we should focus on 1) first, and how 

<snip>

> > > 1. Even if the UAS, when sending 488, must be 
> > > prepared to receive a new PRACK, would it still 
> > > be allowed to cease the retransmission of 
> > > the 18x when sending the 488? After all, who 
> > > could prevent it from doing so? :)

I'm not opposed to allowing retries to stop.  However in doing so, are
you also proposing to allow the rejected PRACK to be the acknowledgement
of the reliable response?  I ask because rfc3262 indicates situations
currently requiring other INVITE 101-299 to be queued until
acknowledgement of the reliable response.  If not considered
acknowledged, the T1*64 timer to receive PRACK should likely continue
even though optimizing to stop retries of INVITE 1xx.  Note that one
reason for the queuing is to allow the PRACK to contain an offer.

By "prepared to receive a new PRACK", are you indicating that returning
PRACK 481 would be acceptable?
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 10:15:06 +0200

Hi, 

>>>1. Even if the UAS, when sending 488, must be prepared to receive 
>>>a new PRACK, would it still be allowed to cease the retransmission 
>>>of the 18x when sending the 488? After all, who could prevent it 
>>>from doing so? :)
>
you also proposing to allow the rejected PRACK to be the acknowledgement
of the reliable response?

Well, that was my proposal 2), that the Rack (and/or( Rseq header could
be used in the rejected PRACK response to indicate that the reliable
response WAS acknowledged.

Because, we can not assume that the error response by default
acknowledges the reliable response, since the error response may have
been sent by an intermediate (ie the UAS never got the PRACK request,
and keeps re-transmitting the reliable response).

But, if we don't go for proposal 2), the rejected PRACK response would
NOT formally indicate that the reliable response was acknowledged - EVEN
if the UAS actually has ceased the re-transmission of the reliable
response. Ie a new PRACK must always be sent.

>I ask because rfc3262 indicates situations currently requiring other
INVITE 101-299 to be queued until acknowledgement of the reliable
response.  If not considered acknowledged, the T1*64 timer 
>to receive PRACK should likely continue even though optimizing to stop
retries of INVITE 1xx.

Correct. The only thing which changes, as far as state is concerned, is
that the 18x is not re-transmitted, eventhough the state still indicates
"not yet acknowledged".

Unless the 18x has been acknowledged, I think 200 OK shall be sent
(unless there is a reason for the UAS to again reject the PRACK, e.g.
due to unacceptable new SDP offer).

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 15 Oct 2008 09:46:14 -0400

> Well, that was my proposal 2), that the Rack 
> (and/or( Rseq header could be used in the 
> rejected PRACK response to indicate that the 
> reliable response WAS acknowledged.

<snip>

> > By "prepared to receive a new PRACK", are you 
> > indicating that returning PRACK 481 would be 
> > acceptable?
> 
> Unless the 18x has been acknowledged, I think 
> 200 OK shall be sent (unless there is a reason 
> for the UAS to again reject the PRACK, e.g.

Proposal 2 currently doesn't allow UAC and UAS to agree that it was
acknowledged.  It only provides a way for UAS to indicate that it was
acknowledged; thus the subsequent PRACK could trigger 481 instead of
expected 200.  The ambiguity could be resolved by UAC including a new
option-tag within PRACK for indicating that it supports the
optimization; however I currently don't think option 2 is worth the
extra specification effort.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Oct 2008 15:52:12 +0200

Hi, 

>>Well, that was my proposal 2), that the Rack (and/or( Rseq header 
>>could be used in the rejected PRACK response to indicate that the 
>>By "prepared to receive a new PRACK", are you indicating that 
>>returning PRACK 481 would be acceptable?
>> 
acknowledged.  It only provides a way for UAS to indicate that it was
acknowledged; thus the subsequent PRACK could trigger 
>481 instead of expected 200.  The ambiguity could be resolved by UAC
including a new option-tag within PRACK for indicating that it supports
the optimization; however I currently don't think 
>option 2 is worth the extra specification effort.

Fair enough. And, if we think it is useful, we can always define it in
an extension, together with the option-tag etc.

Regards,

Christer