Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

From: "Brett Tate" <[email-masked]>
Date: Tue, 5 Feb 2008 17:08:41 -0500

> > The following are some questions and comments 
> > concerning draft-ietf-sipping-sip-offeranswer-05.
> > 
> > The draft mentions "PRACK request should not be rejected".  
> > Is this actually mentioned/explained within an RFC or 
> > only within this draft?  
> > I agree that offers within a PRACK should be discouraged.  
> > However I don't a recall an RFC mentioning that PRACK offer 
> > cannot be rejected with 488.
> 
> In RFC 3262, section 3, is the following: "... If the PRACK 
> does match an unacknowledged reliable provisional response, 
> it MUST be responded to with a 2xx response. ..."

Hi Paul,

Certainly some context matters associated with that sentence.  Besides
the 481 mentioned within that paragraph, certainly other responses are
possible: 100 (per rfc4320), 401, 407, 500, 503, etcetera.  Tables 1 and
2 reflect all kinds of responses for PRACK; and certainly the quoted
sentence was not intended to severely limit the possible responses.

I've always interpreted that sentence in relation to what follows it
since it makes little sense to do otherwise.

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

A rewording of the sentence as follows might avoid some difference of
interpretation.  However it causes a long sentence instead of just
requiring interpretation in relation to the 2 sentences which follow it
and the rest of the RFC.

Old: "If the PRACK does match an unacknowledged reliable provisional
response, it MUST be responded to with a 2xx response."

New: "If the PRACK does match an unacknowledged reliable provisional
response, it MUST be responded to with a 2xx response if communicating
that the PRACK was successfully received by the UAS and PRACK does not
need to be tried again to stop related retrying of 1xx."
_______________________________________________
Sipping mailing list  http://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: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Feb 2008 18:56:04 -0500

Brett Tate wrote:
> Certainly some context matters associated with that sentence. 

Yes, that is true.

> Besides
> possible: 100 (per rfc4320),

Not legal for PRACK due to NIT draft (RFC now)

> 401, 407, 500, 503, etcetera.  Tables 1 and

Yes, agreed.

> response, and MUST remove it from the list of unacknowledged provisional

Yup. And IMO the offeranswer draft is talking about that context when it 
makes its statement.

> interpretation. 

You are talking about rewording the sentence in 3262, right?

> However it causes a long sentence instead of just

I'm sorry, but I don't understand what you are trying to achieve with 
that change. You seem to be trying to introduce a new condition under 
which a non-2xx response may be sent, which wasn't included in the 
original text. If so, that is more than a clarification.

The statements in the offeranswer draft are, AFAIK, consistent with 3262 
relative to this point.

The point here is that the primary purpose of the PRACK is to confirm 
the receipt of the response, and the purpose of the response to the 
PRACK it to quench the retransmission of the PRACK. Its a problem if the 
PRACK is rejected because of problems with the body it is carrying.

*Perhaps* it could have been specified so that the PRACK could be 
treated as acknowledging the receipt of the response even if some 
aspects of it require that it be rejected. (This would require 
specification of which responses to the PRACK are evidence that the UAS 
knows the PRACK has still confirmed the reliable response and which do not.)

But the offeranswer draft isn't trying to solve that problem - that is a 
change rather than a clarification.

Is there something that needs to be changed in the o/a draft given the 
constraint that it is not changing normative behavior?

	Thanks,
	Paul

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 6 Feb 2008 12:10:25 +0900

Brett and Paul,

> Brett Tate wrote:
> > Greetings,
> > 
> > The following are some questions and comments concerning
> > draft-ietf-sipping-sip-offeranswer-05.
> > 
> > The draft mentions "PRACK request should not be rejected".  Is this
> > actually mentioned/explained within an RFC or only within this draft?  I
> > agree that offers within a PRACK should be discouraged.  However I don't
> > a recall an RFC mentioning that PRACK offer cannot be rejected with 488.
> 
> In RFC 3262, section 3, is the following: "... If the PRACK does match 
> an unacknowledged reliable provisional response, it MUST be responded to 
> with a 2xx response. ..."
> 
> > Section 4.1 mentions: "Therefore, to simplify implementations, a UA
> > acting as a UAS for an INVITE transaction is recommended not to defer
> > sending an UPDATE request with an offer until after the reliable
> > response with an answer to the offer in the INVITE request is
> > acknowledged with a PRACK request."  This seems to contradict RFC 3311
> > section 5.1 bullet 4 which indicates to wait for PRACK. 
> 
> You seem to be right about this.
> 
> > Since it also
> > appears to contradict recommendation within sipping-sip-offeranswer-05
> > section 4.2, the "recommended not to defer" should potentially be
> > "recommended to defer".
> 
> Lets see what Takuya says. I'm thinking we do need to do something here, 
> even though this is late in the game.
> 
Brett, thank you for pointing this out.

When I read your comment, I thought you are right and I would not recommend
the way as written in -05. And I checked the previous version (-04) and found
the cause;

"a UA acting as a UAS for an INVITE transaction is recommended not to send 
 an UPDATE request until ..."

Well, we originally tried to change "not to send" to "to defer" but
mistakenly to "not to defer". It is a simple editorial error and
I am sure it will be fixed.

Thanks,
Takuya

> 	Paul

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

------------------------------------------------------------------
注意：この電子メールには、KDDI株式会社の機密情報が含まれている
      場合が有ります。正式なメール受信者でない場合、メール複製、
　　　再配信または情報の使用を固く禁じております。
      エラー、手違い等でこのメールを受け取られましたら、お手数を
　　　おかけ致しますが、削除を行い配信者に連絡をお願い致します。
NOTE: This electronic mail message may contain confidential and
　　　privileged information from KDDI Corporation. If you are
　　　not the intended recipient, any disclosure, photocopying,
      distribution or use of the contents of the received
      information is prohibited. If you have received this e-mail
      in error, please notify the sender immediately and
    　permanently delete this message and all related copies.
-------------------------------------------------------------------

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Feb 2008 09:27:51 -0500

> >>> Is this actually mentioned/explained within an RFC or only within 
> >>> this draft?
> >>> However I don't a recall an RFC mentioning that PRACK 
> >>> offer cannot be rejected with 488.
> >> In RFC 3262, section 3, is the following: "... If the PRACK does 
> >> match an unacknowledged reliable provisional response, it MUST be 
> >> responded to with a 2xx response. ..."
> > 
> > Hi Paul,
> > 
> > Besides the 481 mentioned within that paragraph, 
> > certainly other responses are possible: 100 (per rfc4320),
> 

RFC 4320 still allows it; see section 4.1.

> > 401, 407, 500, 503, etcetera.  Tables 1 and 2 reflect 
> > all kinds of responses for PRACK; and certainly the 
> > quoted sentence was not intended to severely limit 
> > the possible responses.
> 
> Yes, agreed.

If so, why should the sentence in question only prevent 488 and 606
(other body related responses?) without preventing all the other sip
responses?

> > I've always interpreted that sentence in relation 
> > to what follows it since it makes little sense to 
> > do otherwise.
> > 
> > "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."
> 
> Yup. And IMO the offeranswer draft is talking about that 
> context when it makes its statement.
> 
> > A rewording of the sentence as follows might avoid 
> > some difference of interpretation.
> 

I'm only indicating that it potentially could be better worded to avoid
people reading the sentence out of context.

I think sipping-sip-offeranswer-05 is reflecting a misinterpretation of
the sentence by not mentioning PRACK 488 response within section 2.2.
The misinterpretation is also evident within sections 3.2 and 4.1:
"PRACK request should not be rejected".  The misinterpretation is also
evident within section 6.1.

> > requiring interpretation in relation to the 2 
> > sentences which follow it and the rest of the RFC.
> > 
> > Old: "If the PRACK does match an unacknowledged 
> > reliable provisional response, it MUST be responded 
> > to with a 2xx response."
> > 
> > New: "If the PRACK does match an unacknowledged 
> > reliable provisional response, it MUST be responded 
> > to with a 2xx response if communicating that 
> > the PRACK was successfully received by the UAS and 
> > PRACK does not need to be tried again to stop related 
> > retrying of 1xx."
> 
> I'm sorry, but I don't understand what you are trying to 
> achieve with that change. You seem to be trying to introduce 
> a new condition under which a non-2xx response may be sent, 
> which wasn't included in the original text. If so, that is 
> more than a clarification.
> 
> The statements in the offeranswer draft are, AFAIK, 
> consistent with 3262 relative to this point.

AFAIK the statements made within the offeranswer draft are a
misinterpretation of the sentence in question.

> The point here is that the primary purpose of the PRACK is to 
> confirm the receipt of the response, and the purpose of the 
> response to the PRACK it to quench the retransmission of the 
> PRACK. Its a problem if the PRACK is rejected because of 
> problems with the body it is carrying.

It is no more of a problem than rejecting for other reasons.  The UAC
receives the 488/606; it adjusts or removes the SDP when re-sending
PRACK using higher CSeq.

<snip>

> Is there something that needs to be changed in 
> the o/a draft given the constraint that it is not 
> changing normative behavior?

I think sipping-sip-offeranswer-05 is reflecting a misinterpretation of
the sentence in question.  

I think that the draft should mention PRACK 488 response within section
2.2.  

Concerning "PRACK request should not be rejected" within sections 3.2
and 4.1, I don't think such a statement should be made without
clarification somewhere concerning the reason. 

I think that the draft should mention PRACK 488 response within section
6.1.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 12:34:53 -0500

> I am sure it will be fixed.

I don't remember for certain, but I strongly suspect that this is my
error in editing.

Good catch for Brett, and to Takuya for figuring out what happened.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 12:53:11 -0500

Brett,

OK, I now see that this isn't just a matter of clarifying wording. It is 
truly a discussion of the proper interpretation of 3262.

The question is:

If a PRACK contains a new offer, is it valid to respond to it with a 488 
or 606 to indicate unhappiness with the offer?

The problem with returning any error to a PRACK that legitimately 
matches a response is that by rejecting it you have also (IMO) prevented 
it from serving its primary role of acknowledging the earlier response. 
I has assumed it was inappropriate for that reason. (Which of course 
leaves a case not covered by the specs.)

How do we resolve that and proceed?

- we could decide that with careful enough reading the spec does cover 
this case, one way or another. If so then we can craft the offeranswer 
draft to explain this clearly.

- we can conclude that this case is not normatively specified and so is 
ambiguous, and requiring of a normative fix. We can call that out for 
future work, and put best practice guidance into the offeranswer draft 
on how best to function in the presence of this ambiguity. This is what 
I think the draft is currently attempting to do.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Feb 2008 19:03:08 +0100

Hi,

I'm glad to see that finally someone else raises the
reject-offer-in-PRACK issue - so far I has been rather alone on that
issue :)

>OK, I now see that this isn't just a matter of clarifying 
>wording. It is truly a discussion of the proper 
>interpretation of 3262.
> 
>The question is:
> 
>If a PRACK contains a new offer, is it valid to respond to it 
>with a 488 or 606 to indicate unhappiness with the offer?
> 
>The problem with returning any error to a PRACK that 
>legitimately matches a response is that by rejecting it you 
>have also (IMO) prevented it from serving its primary role of 
>acknowledging the earlier response. 
>I has assumed it was inappropriate for that reason. (Which of 
>course leaves a case not covered by the specs.)
> 
>- we could decide that with careful enough reading the spec 
>does cover this case, one way or another. If so then we can 
>craft the offeranswer draft to explain this clearly.
> 
>- we can conclude that this case is not normatively specified 
>and so is ambiguous, and requiring of a normative fix. We can 
>call that out for future work, and put best practice guidance 
>into the offeranswer draft on how best to function in the 
>presence of this ambiguity. This is what I think the draft is 
>currently attempting to do.

I think the question is: does it matter whether we receive a 488/606
response to a PRACK?

The UAC sends the PRACK in order to stop the retransmission of the
associated 18x, and possibly to send an offer.

Now, the UAS should stop the retransmission of the 18x no matter what
response it sends to the PRACK, so from that perspective it shouldn't
really matter to the UAC what the response code is (as long as it is not
some call-does-not-exist response).

Regards,

Christer

> only within 
> >>> Besides the 481 mentioned within that paragraph, certainly other 
> >>> responses are possible: 100 (per rfc4320),
> >>> 401, 407, 500, 503, etcetera.  Tables 1 and 2 reflect all 
> kinds of 
> >>> responses for PRACK; and certainly the quoted sentence was not 
> >>> intended to severely limit the possible responses.
> >> Yes, agreed.
> > 
> >>> 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."
> >>> A rewording of the sentence as follows might avoid some 
> difference 
> >>> of interpretation.
> > I'm only indicating that it potentially could be better worded to 
> > avoid people reading the sentence out of context.
> > 
> > I think sipping-sip-offeranswer-05 is reflecting a 
> misinterpretation 
> > of the sentence by not mentioning PRACK 488 response within 
> section 2.2.
> >>> However it causes a long sentence instead of just requiring 
> >>> interpretation in relation to the 2 sentences which follow it and 
> >>> the rest of the RFC.
> >>>
> >>> response, it MUST be responded to with a 2xx response if 
> >>> communicating that the PRACK was successfully received by the UAS 
> >>> and PRACK does not need to be tried again to stop related 
> retrying 
> >>> of 1xx."
> achieve with 
> >> PRACK it to quench the retransmission of the PRACK. Its a 
> problem if 
> >> the PRACK is rejected because of problems with the body it is 
> >> carrying.
> > 
> >> Is there something that needs to be changed in the o/a draft given 
> >> the constraint that it is not changing normative behavior?
> > 
> > I think sipping-sip-offeranswer-05 is reflecting a 
> misinterpretation 
> > I think that the draft should mention PRACK 488 response within 
> > section 2.2.
> > 
> > I think that the draft should mention PRACK 488 response within 
> > section 6.1.
> > 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
> > 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 14:35:24 -0500

> some call-does-not-exist response).

This is a plausible course of action. However it is far from clear that 
this is what 3262 intended. I find two relevant sections of text in 
section 3 of 3262:

    Retransmissions of the reliable provisional response cease when a
    matching PRACK is received by the UA core.  PRACK is like any other
    request within a dialog, and the UAS core processes it according to
    the procedures of Sections 8.2 and 12.2.2 of RFC 3261.  A matching
    PRACK is defined as one within the same dialog as the response, and
    whose method, CSeq-num, and response-num in the RAck header field
    match, respectively, the method from the CSeq, the sequence number
    from the CSeq, and the sequence number from the RSeq of the reliable
    provisional response.

This paragraph supports what Christer proposes - that retransmissions 
cease independent of what response is generated to the PRACK.

However, the following (also 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.

The above *requires* that a 2xx response be sent to the PRACK if matches 
an unacknowledged reliable provisional. This doesn't cover the case 
where the PRACK contains an unacceptable offer.

Section 5 of 3262 says:

    If the UAC receives a reliable provisional response with an offer
    (this would occur if the UAC sent an INVITE without an offer, in
    which case the first reliable provisional response will contain the
    offer), it MUST generate an answer in the PRACK.  If the UAC receives
    a reliable provisional response with an answer, it MAY generate an
    additional offer in the PRACK.  If the UAS receives a PRACK with an
    offer, it MUST place the answer in the 2xx to the PRACK.

To get the effect that Brett and Christer are suggesting, we in effect 
need some changes to 3262:

- remove the requirement in section 3 that the response to matching 
PRACK be 2xx;

- change section 5 to say that it must put an answer in the response to 
a PRACK with offer only when the response is 2xx. Also, say something 
about what should happen to the o/a status if a PRACK with offer is 
rejected. (I think that if the response only affects the transaction (as 
defined in RFC 5057) then the offer is rejected and the prior o/a status 
remains in effect.)

The issue is whether we can convince ourselves that this is just a 
clarification and not a revison.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Feb 2008 15:06:42 -0500

> I'm glad to see that finally someone else raises 
> the reject-offer-in-PRACK issue - so far I has 
> been rather alone on that issue :)

I'd actually rather just see it deprecated.  However if it isn't being
deprecated, it would be nice to have consensus concerning what rfc3262
says or attempted to say.  It sounds like we might have three different
opinions. :)

> I think the question is: does it matter whether we 
> receive a 488/606 response to a PRACK?
> 
> The UAC sends the PRACK in order to stop the retransmission 
> of the associated 18x, and possibly to send an offer.
> 
> Now, the UAS should stop the retransmission of the 18x no 
> matter what response it sends to the PRACK, so from that 
> perspective it shouldn't really matter to the UAC what the 
> response code is (as long as it is not some 
> call-does-not-exist response).

I agree retransmissions of the 18x should typically be stopped:
"Retransmissions of the reliable provisional response cease when a
matching PRACK is received by the UA core."

However the UAC does not know that the PRACK successfully stopped
retransmissions unless it receives a PRACK 2xx.  The UAC should take
subsequent action (if able) related to inability to successfully deliver
the PRACK unless something like an INVITE final response or PRACK 481
indicate otherwise.

Section 4 indicates "Note that the PRACK is like any other non-INVITE
request within a dialog."  Thus UAC should act upon the failure response
(488, 606, 401, 407, 500, 503, etcetera) and resend with higher CSeq if
they want to ensure that the PRACK is successfully processed.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 15:28:49 -0500

> says or attempted to say.  It sounds like we might have three different

This is why there are limits to the "be lenient in what you receive" 
philosophy - it only works if there is agreement about what the proper 
lenient behavior is.

> retransmissions unless it receives a PRACK 2xx. 

That is still TBD. If the response is one of the ones whose effect is 
only on the transaction according to 5057 then I *think* you can infer 
that receipt of the response, even though it is not a 2xx, is evidence 
that it matched the transaction and therefore quenched retransmission.

> The UAC should take

It could retry the PRACK with a different offer, or send an UPDATE with 
a different offer, or decide to live with the existing o/a state. 
However, the likelihood that the UAC can figure out a useful and 
workable thing to do is highly questionable even if it can figure out 
the signaling to do it.

Unless somebody can figure out how this might be used to do something 
productive, its probably not worth the trouble to get the mechanism 
clarified.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Feb 2008 16:15:37 -0500

> That is still TBD. If the response is one of the ones whose 
> effect is only on the transaction according to 5057 then I 
> *think* you can infer that receipt of the response, even 
> though it is not a 2xx, is evidence that it matched the 
> transaction and therefore quenched retransmission.

I currently don't think that leap can me made without mandating what and
where can trigger PRACK 488/606.  Making the leap would impose
restrictions upon middle boxes and checks within UAS.  However I'm sure
those disliking middle boxes might like such a restriction.

> > The UAC should take subsequent action (if able) related 
> > to inability to successfully deliver the PRACK unless 
> > something like an INVITE final response or 
> > PRACK 481 indicate otherwise.
> 
> It could retry the PRACK with a different offer, or 
> send an UPDATE with a different offer, or decide to 
> live with the existing o/a state.  However, the 
> likelihood that the UAC can figure out a useful 
> and workable thing to do is highly questionable even 
> if it can figure out the signaling to do it.

The easy work around is to resubmit PRACK with higher CSeq without SDP
if wants to allow the early dialog to continue.  Hopefully the
additional PRACK will not cause a 481; however I'm sure someone could
interpret rfc3262 in a way where 481 would be appropriate even though
early dialog still exists.

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

> Unless somebody can figure out how this might be used to do 
> something productive, its probably not worth the trouble to 
> get the mechanism clarified.

I think getting it clarified is highly desirable if 1) vendors are
actually sending offers within PRACK or 2) ambiguity is not just with
488 and 606.
_______________________________________________
Sipping mailing list  http://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: "Brett Tate" <[email-masked]>
Date: Wed, 6 Feb 2008 16:45:25 -0500

> craft the offeranswer draft to explain this clearly.

Hopefully this is possible.

> currently attempting to do.

I agree that sipping-sip-offeranswer-05 is wisely attempting to
discourage sending offers within PRACK.

If the first option is not possible, this option sounds ok to me.  It
might trigger follow-up concerning potential need for rfc3262bis per SIP
group discussion early 2006:

http://www.ietf.org/mail-archive/web/sip/current/msg13240.html

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 17:08:22 -0500

> those disliking middle boxes might like such a restriction.

I don't understand. I don't *universally* dislike middleboxes. I do 
dislike them when they do non-conforming things. This often happens when 
they try to pretend they are something other than a UA.

A proxy cannot originate requests or responses within the dialog of a 
request it has proxied. It *can* choose to act as a combination of a 
forking proxy and a UA, forking to itself and then sending a response in 
a newly established dialog.

A B2BUA/SBC *is* a UA, so it can do all of this stuff. But it is then 
acting for itself, and must follow the rules for UAs. In that context I 
don't think it would cause any new complications in this discussion.

> if wants to allow the early dialog to continue. 

If we believe that the PRACK accomplished the acknowledgment of the 
reliable response even when it failed then there is no reason to re-send 
it without a body. As long as the failure only affected the transaction 
the early dialog should continue.

> Hopefully the

Perhaps.

If the UAS considers the failed PRACK to have acknowledged the reliable 
provisional, then another PRACK for the same response will not match, 
and so receive a 481 response.

Now that I consider it, I think perhaps 3262 has yet another unique use 
for 481 with semantics somewhat different than all those listed in 5057. 
If the PRACK otherwise matches, but carries an Rseq that isn't 
recognized, or that matches a response that has already been 
acknowledged, then you presumably get a 481. This is somewhat like the 
use of 481 for CANCEL - it has nothing to do with dialogs.

So you can't really even tell if the dialog match failed or not. If it 
failed then retry is futile. But I guess if Rseq doesn't match then 
retry is also futile, even though the reason is different.

> actually sending offers within PRACK or 2) ambiguity is not just with

I hope we get some additional feedback on this.

(We ought to hear from Robert, and Dale or Scott, on this.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Feb 2008 23:27:12 +0100

Hi, 

>>really matter to the UAC what the response code is (as long as it is 
>>not some call-does-not-exist response).
> 
>This is a plausible course of action. However it is far from 
>clear that this is what 3262 intended. I find two relevant 
>sections of text in section 3 of 3262:
> 
>matching PRACK is received by the UA core.  PRACK is like 
>any other request within a dialog, and the UAS core processes it 
>according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261.  A
matching
>This paragraph supports what Christer proposes - that 
>retransmissions cease independent of what response is 
>generated to the PRACK.
> 
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.
> 
>The above *requires* that a 2xx response be sent to the PRACK 
>if matches an unacknowledged reliable provisional. This 
>doesn't cover the case where the PRACK contains an unacceptable offer.
> 
>Section 5 of 3262 says:
> 
>which case the first reliable provisional response will 
>contain the offer), it MUST generate an answer in the PRACK.  If the 
>UAC receives a reliable provisional response with an answer, it MAY
generate an
>To get the effect that Brett and Christer are suggesting, we 
>in effect need some changes to 3262:
> 
PRACK be 2xx;
>- change section 5 to say that it must put an answer in the response to
a PRACK with offer only when the response is 2xx. 
>Also, say something about what should happen to the o/a status if a
PRACK with offer is rejected. (I think that if 
>the response only affects the transaction (as defined in RFC 5057) then
the offer is rejected and the prior o/a status 
>remains in effect.)

I think the o/a status would be the same as if an UPDATE with an offer
is rejected.

Correct. 

But, no matter what it is, we can at least update the offer-answer
draft, and clarify the issue there.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 6 Feb 2008 23:26:44 +0100

Hi,

Calling things ambiguous, fixing them in the future etc is never going
to make anything better - especially since this is an issue which is
raised over and over again.

I agree that it is good that the offer-answer draft tries to discourage
one from using PRACK for sending offers in the first place, but that is
not enough.

My proposal would be that we in the offer-answer draft say that it IS
allowed to send a non-2xx response to a PRACK, e.g. in order to reject
an offer, as has been discussed in this draft.

Now, whether we then need to revise 3262, or we just consider it as a
clarification, we can discuss, but doing nothing will not help.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: 6. helmikuuta 2008 23:45
> To: Paul Kyzivat
> Cc: [email-masked]; IETF Sipping List; Mary Barnes
> Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments 
> and questions
> 
> does cover 
> > - we can conclude that this case is not normatively 
> specified and so 
> > is ambiguous, and requiring of a normative fix. We can call 
> that out 
> > for future work, and put best practice guidance into the 
> offeranswer 
> > draft on how best to function in the presence of this 
> ambiguity. This 
> > is what I think the draft is currently attempting to do.
> 
> I agree that sipping-sip-offeranswer-05 is wisely attempting 
> to discourage sending offers within PRACK.
> 
> If the first option is not possible, this option sounds ok to 
> me.  It might trigger follow-up concerning potential need for 
> rfc3262bis per SIP group discussion early 2006:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Feb 2008 17:49:25 -0500

Christer,

IMO we cannot, in a BCP, recommend behavior that is an outright 
violation of a normative document.

If something is ambiguous, we can recommend a valid alternative that is 
likely to have the most favorable outcome, but we still can't count on 
all parties following that recommendation, and so still need to account 
for the behavior when one party follows the recommendation and the other 
party follows another, possibly legal, interpretation.

In this case, I don't see how we can recommend that a non-2xx response 
be sent to a PRACK that matches the dialog, etc. So I think the best we 
can do it steer people away from sending offers in PRACKs. Which is what 
we have already done.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 6 Feb 2008 17:55:56 -0500

> > However I'm sure those disliking middle boxes 
> > might like such a restriction.
> 
> I don't understand. I don't *universally* dislike 
> middleboxes. 

I apologize if you thought I was referring to you. :)

> A B2BUA/SBC *is* a UA, so it can do all of this stuff. But it 
> is then acting for itself, and must follow the rules for UAs. 
> In that context I don't think it would cause any new 
> complications in this discussion.

The potential complication relates to middle boxes (proxy/SBC/...)
returning PRACK 488/606 (other failure responses?) although it is not
the one performing 100rel response retries.  Thus the UAC does not know
if the PRACK successfully stopped the 100rel retries without using
subsequent 100rel retried response as part of the decision process.

> If we believe that the PRACK accomplished the acknowledgment 
> of the reliable response even when it failed then there is no 
> reason to re-send it without a body. As long as the failure 
> only affected the transaction the early dialog should continue.

Agreed; however I think that it is a leap to know which failure
responses accomplish the acknowledgment.
_______________________________________________
Sipping mailing list  http://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: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2008 09:59:42 -0500

> subsequent 100rel retried response as part of the decision process.

I disagree with the above.

For one thing the situation is very different for a proxy vs. an SBC. 
Lets assume an SBC for now. It is a B2BUA. It *is* the one performing 
retries - it must behave exactly as a UA on each side. It may *want* to 
view itself as simply forwarding messages, but from a technical SIP 
situation it must perform whatever adjustments are necessary to be valid 
on the two sides. That may mean absorbing some messages rather than 
forwarding, or fabricating some new messages.

> responses accomplish the acknowledgment.

I agree it is a straightforward inference that we can assume every UA 
will do given the current state of the specs. Hence the likely need for 
normative changes if we wish to mandate such behavior.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 7 Feb 2008 10:36:14 -0500

> > The potential complication relates to middle 
> > boxes (proxy/SBC/...) returning PRACK 488/606 
> > (other failure responses?) although it is not 
> > the one performing 100rel response retries.  
> > Thus the UAC does not know if the PRACK 
> > successfully stopped the 100rel retries without 
> > using subsequent 100rel retried response as 
> > part of the decision process.
> 
> For one thing the situation is very different 
> for a proxy vs. an SBC. Lets assume an SBC for 
> now. It is a B2BUA. It *is* the one performing 
> retries - it must behave exactly as a UA on each 
> side. It may *want* to view itself as simply 
> forwarding messages, but from a technical SIP 
> situation it must perform whatever adjustments 
> are necessary to be valid on the two sides. That 
> may mean absorbing some messages rather than 

Hi Paul,

Although some of the more transparent B2BUAs might not like it, I agree
that a B2BUA could accommodate such a requirement.

A proxy cannot accommodate such a requirement.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2008 10:50:32 -0500

> A proxy cannot accommodate such a requirement.

Yep. And a proxy also cannot originate its own requests or responses in 
the dialog. (With the exception of 100, which isn't really in the dialog 
anyway.)

(The server that sometimes acts as a proxy may also act as a UA, and as 
such may send responses resulting in the creation of a dialog. But that 
is covered by UA behavior, not proxy behavior.)

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 7 Feb 2008 11:23:24 -0500

> Yep. And a proxy also cannot originate its own 
> requests or responses in the dialog. (With the 
> exception of 100, which isn't really in the dialog
> anyway.)
> 
> (The server that sometimes acts as a proxy may 
> also act as a UA, and as such may send responses 
> resulting in the creation of a dialog. But that 

I'm mainly just replying incase anyone found the response misleading.
However I also wanted to ensure that we were in agreement that the
middle box (proxy for dialog; UAS for transaction) returning 488/606 is
valid and would cause problems (concerning the proposal/interpretation)
since it is not the one performing the 18x retries.

For example, A calls B using proxy P.  B sends 18x per rfc3262.  A sends
PRACK with SDP; proxy P rejects it with a 488.  The
proposal/interpretation to allow A to think 18x retries are no longer
occurring has problems since B is still retrying and awaiting for PRACK.

Thanks,
Brett

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2008 13:50:38 -0500

> since it is not the one performing the 18x retries.

Hmm. I didn't have that case in mind. But I guess that is indeed possible.

> PRACK with SDP; proxy P rejects it with a 488. 

I have some difficulty with a proxy making such a decision. But 
nevertheless the basic point remains valid. Another example might be a 
407 response to the PRACK.

> The

Yes, I agree.

I seem to remember something from Dale awhile ago wanting a way to know 
whether a response came from the UAS or a middle node. This seems to be 
another case of that. At the moment we don't have a way.

	Paul

---

From: "Fred Seymour" <[email-masked]>
Date: Fri, 8 Feb 2008 18:00:09 +0900

Sorry, I misunderstood problems you are debating about.

In current specifications, even if second offer within PRACK is not
preferable, then UAS cannot keep the first negotiated result without
the acknowledgment of the reliable response.

IMHO, Two scenarios are possible.

A. If following 3261/3262 specifications,
	1. UAS send 200OK for PRACK with SDP(perhaps media port is zero).
	2. UAS send UPDATE request in order to recover the negotiated result.
	3. if UPDATE method is not allowed, UAS send 488/606 response for
	   INVITE with Warning header and SDP(perhaps negotiated first).

B. If enhancing specifications a little,
	1. UAS send 488/606 response with Warning header and SDP(perhaps
       negotiated first)
	2. UAC re-send PRACK request without SDP.
	3. UAS send 200 OK response for PRACK, and cease retransmissions
	   of the reliable provisional response.

I don't think UAS SHOULD cease retransmissions of the reliable provisional
response, when sending 4xx response for PRACK. it cause the problem about
backward compatibility.

Fred.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Feb 2008 12:46:26 +0100

Hi, 

>>>However I'm sure those disliking middle boxes might like such a 
>>>restriction.
>> 
>>I don't understand. I don't *universally* dislike middleboxes.
> 
>>acting for itself, and must follow the rules for UAs.
>>In that context I don't think it would cause any new complications in 
>>this discussion.
> 
>The potential complication relates to middle boxes 
>(proxy/SBC/...) returning PRACK 488/606 (other failure 
>responses?) although it is not the one performing 100rel 
>response retries.  Thus the UAC does not know if the PRACK 
>successfully stopped the 100rel retries without using 
>>reliable response even when it failed then there is no reason to 
>>re-send it without a body. As long as the failure only affected the 
>>transaction the early dialog should continue.
> 
>Agreed; however I think that it is a leap to know which 
>failure responses accomplish the acknowledgment.

I think one could assume that pretty much ANY failure response
accomplished the acknowledgement.

And, even if the UAS for whatever keeps re-transmitting the 18x, won't
the UAC transaction state machine re-transmit the PRACK? There is no
reason for the UAC to create a "new" PRACK just to stop the
re-transmission of the 18x...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Feb 2008 12:48:19 +0100

Hi, 

>IMO we cannot, in a BCP, recommend behavior that is an 
>outright violation of a normative document.

My proposal is that we make a "normative" decission to allow non-2xx
responses to PRACK, in order to reject offers etc. As you said yourself,
some parts of 3262 already seems to allow it.

>If something is ambiguous, we can recommend a valid 
>alternative that is likely to have the most favorable 
>outcome, but we still can't count on all parties following 
>that recommendation, and so still need to account for the 
>behavior when one party follows the recommendation and the 
>other party follows another, possibly legal, interpretation.

If something is ambigiuos, we fix it.

The only thing we will have "in future" is a bigger number of
implementations doing things in a specific way, which means more interop
problems, and more difficulties to specify a "correct behavior".

So, let's make a decission NOW, and then bury this discussion once and
for all :)

>In this case, I don't see how we can recommend that a non-2xx 
>response be sent to a PRACK that matches the dialog, etc.

Sending non-2xx responses to requests, even if thet match the dialog, is
nothing new, is it?

>So I think the best we can do it steer people away from sending 
>offers in PRACKs. Which is what we have already done.

That still doesn't prevent us to make a decission on how to solve
things. As long as it is allowed to use PRACK for sending offers, the
problem will be there.

Regards,

Christer

> > I agree that it is good that the offer-answer draft tries to 
> > discourage one from using PRACK for sending offers in the 
> first place, 
> > but that is not enough.
> > 
> >> Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments and 
> >> questions
> >>
> >> might trigger follow-up concerning potential need for 
> rfc3262bis per

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Feb 2008 13:04:34 +0100

Hi, 

>In current specifications, even if second offer within PRACK 
>is not preferable, then UAS cannot keep the first negotiated 
>result without the acknowledgment of the reliable response.
> 

The problem with setting ports to zero is that resources etc associated
with the media stream is released.

And, there could even be valid use-cases where the UAS actually WANTS to
terminate stream(s), by setting the port(s) to zero. So, therefor I
don't think port zero shall be used to reject an updated offer.

negotiated first)
> 3. UAS send 200 OK response for PRACK, and cease retransmissions of
the reliable provisional response.
> 
>I don't think UAS SHOULD cease retransmissions of the 
>reliable provisional response, when sending 4xx response for 
>PRACK. it cause the problem about backward compatibility.

I agree. If the syntax etc of the PRACK is correct, and the UAS can
"match" the PRACK to an ongoing re-transmission of an 18x, it should
cease the retransmission - no matter what the response code to the PRACK
will be.

Regards,

Christer

> > >> A B2BUA/SBC *is* a UA, so it can do all of this stuff. But it is 
> > >> then acting for itself, and must follow the rules for UAs.
> (proxy/SBC/...) 
> > > returning PRACK 488/606 (other failure responses?) although it is 
> > > not the one performing 100rel response retries.  Thus the 
> UAC does 
> > > not know if the PRACK successfully stopped the 100rel retries 
> > > without using subsequent 100rel retried response as part 
> of the decision process.
> >
> > retries - it must behave exactly as a UA on each side. It 
> may *want* 
> > to view itself as simply forwarding messages, but from a 
> technical SIP 
> > situation it must perform whatever adjustments are necessary to be 
> > valid on the two sides. That may mean absorbing some 
> messages rather 
> > than forwarding, or fabricating some new messages.
> >
> > will do given the current state of the specs. Hence the likely need 
> > for normative changes if we wish to mandate such behavior.
> >
> >        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 8 Feb 2008 13:17:51 +0100

Hi, 

>>>Yep. And a proxy also cannot originate its own requests or responses 
>>>in the dialog. (With the exception of 100, which isn't really in the 
>>>dialog anyway.)
>>>
>>>(The server that sometimes acts as a proxy may also act as a UA, and 
>>>as such may send responses resulting in the creation of a dialog. But

>>>that is covered by UA behavior, not proxy behavior.)
>> 
>>middle box (proxy for dialog; UAS for transaction) returning 488/606 
>>is valid and would cause problems (concerning the 
>>proposal/interpretation) since it is not the one performing the 18x
retries.
>>For example, A calls B using proxy P.  B sends 18x per rfc3262.  A 
>>sends PRACK with SDP; proxy P rejects it with a 488.
> 
>I have some difficulty with a proxy making such a decision. 
>But nevertheless the basic point remains valid. Another 
>example might be a
>>The proposal/interpretation to allow A to think 18x retries are no
longer 
>>occurring has problems since B is still retrying and awaiting for
PRACK.

If P is a proxy, wouldn't it forward the 18x re-transmissions towards
the UAC, even if it has replied with 4xx to the PRACK? The UAC would
then re-transmit the PRACK (in which case it probably would receive the
same response), or the UAC could be smart enough to create a new PRACK
transaction, and e.g. choose not to included the SDP offer.

I agree to the problem, but that could occur even if the PRACK doesn't
contain SDP, couldn't it? So, it is not a pure
how-to-reject-an-offer-in-a-PRACK problem, eventhough in real life it
maybe mostly often occur due to that.

>I seem to remember something from Dale awhile ago wanting a 
>way to know whether a response came from the UAS or a middle 
>node. This seems to be another case of that. At the moment we 
>don't have a way.

If the UAC receives a 4xx to the PRACK, but the 18x is still
re-transmitted, it could assume that the PRACK didn't reach the UAS.

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 8 Feb 2008 07:35:48 -0500

> > Agreed; however I think that it is a leap to know 
> > which failure responses accomplish the acknowledgment.
> 
> I think one could assume that pretty much ANY failure 
> response accomplished the acknowledgement.

Failure response can be generated by proxies.  And responses such as 401
and 503 can also be generated by the UAS without allowing it to stop the
1xx retries.

> And, even if the UAS for whatever keeps re-transmitting the 
> 18x, won't the UAC transaction state machine re-transmit the 
> PRACK? 

Not per the "SHOULD NOT" mentioned within section 4.

> There is no reason for the UAC to create a "new" PRACK 
> just to stop the re-transmission of the 18x...

Per section 3, the lack of PRACK should trigger UAS to reject original
request with a 5xx response.
_______________________________________________
Sipping mailing list  http://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: Fri, 8 Feb 2008 13:50:11 +0100

Hi, 

>Failure response can be generated by proxies.  And responses 
>such as 401 and 503 can also be generated by the UAS without 
>allowing it to stop the 1xx retries.
> 
> 

>>the UAC transaction state machine re-transmit the PRACK?
> 
>>There is no reason for the UAC to create a "new" PRACK just to stop
the re-transmission of the 18x...

So, the call will fail. That may be better than not specifying clear
behavior :)

The question is how often a proxy would reject the PRACK in the first
place.

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 8 Feb 2008 08:58:57 -0500

> >> There is no reason for the UAC to create a 
> >> "new" PRACK just to stop the re-transmission 
> >> of the 18x...
> > 
> > Per section 3, the lack of PRACK should trigger 
> > UAS to reject original request with a 5xx response.
> 
> So, the call will fail. That may be better than not 
> specifying clear behavior :)
>
> The question is how often a proxy would reject 
> the PRACK in the first place.

Typical proxy rejections are 407, 503, 420 (unless proxy-require value
within INVITE), and 488.  The 407 is likely the most common.  Proxy
vendors could likely mention others.  More transparent B2BUAs could
likely mention others such as 401, 500, 606.

-brett

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:26:50 -0500

Brett Tate wrote:
> vendors could likely mention others. 

407: agreed

503: while this might make sense for a proxy in some cases
      I find it hard to imagine how it would apply to an
      in-dialog request such as PRACK.

420: I'm again having difficulty imagining a case when this
      would apply here.

488: Why would a proxy be generating this? Are you assuming
      it is doing screening of media even though it is not
      terminating the media??? This offends me, but I guess
      it is done.

But 407 is enough to make the point. And I doubt we should be making a 
formal classification of which may be done by proxies and which may not. 
So I agree with your argument that we cannot assume that the UA has the 
PRACK when we get a final response other than 2xx.

	Paul

> More transparent B2BUAs could

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:30:31 -0500

> cease the retransmission - no matter what the response code to the PRACK

You say "I agree", but then you restate your position as one that is 
contrary to what you just said you agree to.

Hopefully you meant to say: "I *dis*agree. ..."

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:39:02 -0500

> 	   of the reliable provisional response.

IMO B isn't worth the trouble. Its unlikely that a UA will be able to 
figure out how to recover. For real world situations A will be sufficient.

IMO the suitable recommendation (roughly what is there) is that session 
changes offered in PRACK ought to be ones that clearly will be 
acceptable. A couple of cases are: those following 3312, and those that 
are simply subsetting what was in the initial o/a - such as reducing to 
a single codec. We could recommend that this be the only kind of offer 
used in PRACK, and that answerers never object to such an offer.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:44:44 -0500

We can decide what we want to do. But the O/A document is on track to be 
a BCP, not a normative change to the existing specs. So *it* is limited 
in what it can do. We can record a bug in bug tracker, and can 
potentially scope out *additional* work, such as another contribution to 
the corrections document. But I see that as a separate piece of work.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 9 Feb 2008 01:10:57 +0100

Hi, 

>>>I don't think UAS SHOULD cease retransmissions of the reliable 
>>>provisional response, when sending 4xx response for PRACK. it cause 
>>>the problem about backward compatibility.
>> 
>>"match" the PRACK to an ongoing re-transmission of an 18x, 
>>it should cease the retransmission - no matter what the response code
to the 
>>PRACK will be.
> 
>You say "I agree", but then you restate your position as one 
>that is contrary to what you just said you agree to.
> 

That's probably what I meant, yes :) A UAS should cease the
retransmission of the 18x no matter what response is sent for the PRACK.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 9 Feb 2008 01:11:02 +0100

Hi, 

>>>Per section 3, the lack of PRACK should trigger UAS to reject 
>>>original request with a 5xx response.
>> 
>Typical proxy rejections are 407, 503, 420 (unless 
>proxy-require value within INVITE), and 488.  The 407 is 
>likely the most common.  Proxy vendors could likely mention 
>others.  More transparent B2BUAs could likely mention others 
>such as 401, 500, 606.

A B2BUA which sends an error reply to a PRACK can choose to behave "like
a proxy", ie do nothing else, in which case the UAS will send a 5xx
response once the 18x retransmission times out. Or, the B2BUA can e.g.
send a PRACK to the UAS, or a CANCEL in order to terminate the INVITE.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 9 Feb 2008 01:11:11 +0100

Hi, 

>We can decide what we want to do. But the O/A document is on 
>track to be a BCP, not a normative change to the existing 
>specs. So *it* is limited in what it can do. We can record a 
>bug in bug tracker, and can potentially scope out 
>*additional* work, such as another contribution to the 
>corrections document. But I see that as a separate piece of work.

The idea is that the behviour would be documented in the O/A document as
a potential way to solve the problem, while we then decided (as a
separate piece of work) how we would document it in a normative way
elsewhere.

Regards,

Christer

> > responses to PRACK, in order to reject offers etc. As you said 
> > yourself, some parts of 3262 already seems to allow it.
> > 
> alternative that 
> >> is likely to have the most favorable outcome, but we still can't 
> >> count on all parties following that recommendation, and so 
> still need 
> >> to account for the behavior when one party follows the 
> recommendation 
> >> and the other party follows another, possibly legal, 
> interpretation.
> > 
> > implementations doing things in a specific way, which means more 
> > interop problems, and more difficulties to specify a 
> "correct behavior".
> > 
> > Sending non-2xx responses to requests, even if thet match 
> the dialog, 
> > is nothing new, is it?
> > 
> >>>> Sipping mailing list  
> http://www.ietf.org/mailman/listinfo/sipping

---

From: Takuya Sawada <[email-masked]>
Date: Sat, 9 Feb 2008 16:37:21 +0900

Hi,

Well, I am surprised at the huge traffic on this issue.
I cuold not follow them at all last week...

Now I also tend to agree to make this issue done as a separate
work like as a new normative document to correct/update RFC 3262.
Whether the summary of this discussion should be incorporated
in the O/A document or not, I will not be against it if good and
simple additional text can be proposed. That is the way we
did on editing this document. The only issue is the timing,
I think. 

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 10 Feb 2008 12:57:26 +0100

Hi,

Again, I am not proposing to add normative text to the draft.

But, as I have said before, I do think it is important to document discussions and different solution proposals in the draft.

I will take a closer look at the draft in the beginning of the week, and see whether I can propose some text regarding this issue.

Regards,

Christer

> From: Takuya Sawada [mailto:[email-masked]] 
> Sent: 9. helmikuuta 2008 9:37
> To: Christer Holmberg; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Now I also tend to agree to make this issue done as a 
> separate work like as a new normative document to 
> correct/update RFC 3262.
> in the O/A document or not, I will not be against it if good 
> and simple additional text can be proposed. That is the way 
> we did on editing this document. The only issue is the 
> timing, I think. 
> 
> Regards,
> Takuya
> 
> > 
> > Hi,
> > 
> > >We can decide what we want to do. But the O/A document is 
> on track to 
> > >be a BCP, not a normative change to the existing specs. So *it* is 
> > >limited in what it can do. We can record a bug in bug tracker, and 
> > >can potentially scope out
> > >*additional* work, such as another contribution to the corrections 
> > >document. But I see that as a separate piece of work.
> > 
> > The idea is that the behviour would be documented in the 
> O/A document 
> > as a potential way to solve the problem, while we then 
> decided (as a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 12 Feb 2008 10:08:55 +0100

Hi,

Below is some proposed text (starting with "It was also proposed...").

6.1. Rejecting PRACK Offer 

  As stated in section 2.2. and 3.2. , it is recommended that an 
  offer not be sent in a PRACK request unless UAC has strong reasons 
  to assume the receiver will accept it. Even so, there may be cases 
  when the UAS has to reject the offer for some reason. The current 
  RFCs do not provide a way to reject the offer and at the same time 
  to acknowledge the reliable response. 

  Several ideas were presented to resolve this issue, such as sending 
  2xx PRACK response without SDP to reject the offer, or sending SDP 
  with a decreased version value in the o-line. It was also propsed to allow non-2xx responses to PRACK, in order to reject an SDP offer carried in the PRACK. The response would still acknowledge the PRACK, and the UAS would cease transmission of the reliable provisional response acknowledged by the PRACK request. Some of the 
  candidates may also be adapted as a way to reject an unacceptable 
  offer in a response. Anyway, those proposals violate the current 
  rules and lose backward compatibility to some extent (e.g. section 
  5 of RFC 3262). It is beyond the scope of this document and remains 
  for further study. 

       NOTE: Deprecation of the usage of offer in PRACK may be 
       another solution. As the precondition mechanism specification 
       [2] explicitly shows a usage of sending offer in PRACK, its 
       deprecation could cause backward compatibility issues.   

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 10. helmikuuta 2008 13:57
> To: Takuya Sawada; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> But, as I have said before, I do think it is important to 
> document discussions and different solution proposals in the draft.
> 
> I will take a closer look at the draft in the beginning of 
> the week, and see whether I can propose some text regarding 
> this issue.
> 
> Regards,
> 
> Christer
> 
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked]
> > Now I also tend to agree to make this issue done as a separate work 
> > like as a new normative document to correct/update RFC 3262.
> > Whether the summary of this discussion should be 
> incorporated in the 
> > O/A document or not, I will not be against it if good and simple 
> > additional text can be proposed. That is the way we did on editing 
> > this document. The only issue is the timing, I think.
> > 
> > Regards,
> > Takuya
> > 
> > > 
> > > Hi,
> > > 
> corrections

---

From: "Fred Seymour" <[email-masked]>
Date: Fri, 15 Feb 2008 11:22:40 +0900

Hi.

At least, I think that there is a problem concerning security in the
cease of the reliable provisional response when UAS returns 401
responses.

Regards,
Fred

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 15 Feb 2008 07:39:58 +0100

Hi Fred, 

>At least, I think that there is a problem concerning security in the cease of the reliable provisional response when UAS returns 401 responses.

What security problem are you referring to?

Regards,

Christer

> >  As stated in section 2.2. and 3.2. , it is recommended 
> that an  offer 
> > not be sent in a PRACK request unless UAC has strong reasons  to 
> > assume the receiver will accept it. Even so, there may be 
> cases  when 
> > the UAS has to reject the offer for some reason. The 
> current  RFCs do 
> > not provide a way to reject the offer and at the same time  to 
> > acknowledge the reliable response.
> >
> > with a decreased version value in the o-line. It was also 
> propsed to 
> > allow non-2xx responses to PRACK, in order to reject an SDP offer 
> > carried in the PRACK. The response would still acknowledge 
> the PRACK, 
> > and the UAS would cease transmission of the reliable provisional 
> > response acknowledged by the PRACK request. Some of the  candidates 
> > may also be adapted as a way to reject an unacceptable  offer in a 
> > response. Anyway, those proposals violate the current  
> rules and lose 
> > backward compatibility to some extent (e.g. section
> document 
> > > discussions and different solution proposals in the draft.
> > >
> > > I will take a closer look at the draft in the beginning 
> of the week, 
> > > and see whether I can propose some text regarding this issue.
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > > > > > > The only thing we will have "in future" is a 
> bigger number 
> > > > > > > of implementations doing things in a specific way, which
> > > > means more
> > > > > > >>> Calling things ambiguous, fixing them in the 
> future etc is
> > > > > > >> never going
> > > > > > >>> to make anything better - especially since this is an 
> > > > > > >>> issue
> > > > > > >> which is
> > > > > > >>> My proposal would be that we in the 
> offer-answer draft say
> > > > > > >> that it IS
> > > > > > >>>>> this case, one way or another. If so then we 
> can craft 
> > > > > > >>>>> the
> > > > > > >>>> offeranswer
> > > > > > >>>> If the first option is not possible, this 
> option sounds 
> > > > > > >>>> ok
> > > > > > >> to me.  It
> > > > Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 
> 102-8460, 
> > > > Japan
> > > > Tel: +81-3-6678-2997
> > > > Fax: +81-3-6678-0286
> > > > [email-masked]
> > > >
> > > > 
> > > > privileged information from KDDI Corporation. If you 
> are not the 
> > > > intended recipient, any disclosure, photocopying,
> > > > -

---

From: "Fred Seymour" <[email-masked]>
Date: Fri, 15 Feb 2008 19:23:49 +0900

Hi

IMO, when PRACK request is counterfeited, UAS cease the reliable
provisional response, even if UAC has not received the provisional
response.

Regards,

Fred

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 15 Feb 2008 11:28:05 +0100

Hi, 

>IMO, when PRACK request is counterfeited, UAS cease the 
>reliable provisional response, even if UAC has not received 
>the provisional response.

I don't think this is a PRACK specific problem. "Fake" BYEs, re-INVITEs etc etc etc can cause much worse damages.

Regards,

Christer

> > >At least, I think that there is a problem concerning 
> security in the cease of the reliable provisional response 
> when UAS returns 401 responses.
> >
> > > > response acknowledged by the PRACK request. Some of the  
> > > > > > > > > things. As long as it is allowed to use PRACK for 
> > > > > > > > > sending
> > > > > > > > offers, the
> > > > > > > > > problem will be there.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Christer
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >> Christer Holmberg wrote:
> > > > > > > > >>> Hi,
> > > > > > > > >>>
> > > > > > > > >>> allowed to send a non-2xx response to a 
> PRACK, e.g. in
> > > > > > > > >> order to reject
> > > > > > > > >>> clarification, we can discuss, but doing 
> nothing will
> > > > > > not help.
> > > > > > > > >>>
> > > > > > > > >>> Regards,
> > > > > > > > >>>
> > > > > > > > >>> Christer
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > NOTE: This electronic mail message may contain confidential 
> > > > > > and privileged information from KDDI Corporation. If you
> > > are not the
> > > > > [email-masked] for questions on current sip

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 15 Feb 2008 20:01:06 +0900

Hi,

I think the proposed text can be added if all can agree.
It is just to add another idea which was proposed in the
recent discussion. Several ideas have already been there
reflected from the similar type of discussion in the past.
I think it is not a big change.

There may be a matter of timing. How do you think?

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 15 Feb 2008 13:00:37 +0100

Hi, 

>There may be a matter of timing. How do you think?

Since my proposal is that we, as a separate item, actually DO move forward with the non-2xx-response-to-PRACK solution, I think it would be very useful to list it as one of the discussed solutions in the offer-answer draft.

Regards,

Christer

> propsed to allow non-2xx responses to PRACK, in order to 
> reject an SDP offer carried in the PRACK. The response would 
> still acknowledge the PRACK, and the UAS would cease 
> transmission of the reliable provisional response 
> acknowledged by the PRACK request. Some of the

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 15 Feb 2008 08:07:56 -0600

Takuya,

If this change can be agreed quickly, let's go ahead and make it prior to forwarding to Jon/IESG (currently targetted for March) - that way we don't have a repeat of this discussion during IETF LC.  

So, anyone else that might have feedback on this proposed text, please comment ASAP. 

Thanks,
Mary. 

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: Friday, February 15, 2008 5:01 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; Barnes, Mary (RICH2:AR00); [email-masked]
Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

Hi,

I think the proposed text can be added if all can agree.
It is just to add another idea which was proposed in the recent discussion. Several ideas have already been there reflected from the similar type of discussion in the past.
I think it is not a big change.

Regards,
Takuya

> > But, as I have said before, I do think it is important to document 
> > I will take a closer look at the draft in the beginning of the week, 
> > > > > > The only thing we will have "in future" is a bigger number 
> > > > > >>>>> this case, one way or another. If so then we can craft 
> > > > > >>>>> the
> > > > > >>>> offeranswer
> > > > > >>>> If the first option is not possible, this option sounds 
> > > > > >>>> ok
> > > > > >> to me.  It
> > > Garden Air Tower, 3-10-10, Iidabashi, Chiyoda-ku, Tokyo 102-8460, 
> > > Japan
> > > Tel: +81-3-6678-2997
> > > Fax: +81-3-6678-0286
> > > [email-masked]
> > > 

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Fred Seymour" <[email-masked]>
Date: Sat, 16 Feb 2008 05:11:59 +0900

Hi.

Strictly speaking, this problem concerns not offeranswer but the
correction of a normative specification about rfc3262. Therefore, I
agree that UAS's behavior for 401 response is not described to
draft-offeranswer. However, should all the responses(including 401)
unconditionally causes the stop of the reliable provisional response ?

Regards,

Fred

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2008 16:26:41 -0500

I believe discussion has demonstrated that non-2xx final responses must
not be taken to demonstrate that the PRACK was received by the UAS,
because the non-2xx final response may not have come from the UAS.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 15 Feb 2008 22:50:01 +0100

Hi,

Correct.
 
The problem, as has been discussed, is that the UAC doesn't know where the response comes from. So, if the UAC assumes the response comes from the UAS, it will most likely discard the re-transmitted 18x that will keep coming, and at some point the UAS will release the call. But, we can strongly recommend against sending non-2xx responses to PRACK (at least by intermediates), unless it is really unavoidable.
 
Regards,
 
Christer

Fred Seymour wrote:
>>>>>>> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of
>>> Christer Holmberg
>>>>>>>> From: Takuya Sawada [mailto:[email-masked] <mailto:[email-masked]> ]
>>>>>>>>>>>>>> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of
>>>>> Brett Tate
>>> http://www.ietf.org/mail-archive/web/sip/current/msg13240.html <http://www.ietf.org/mail-archive/web/sip/current/msg13240.html> 
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Brett
>>>>>>>>>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
>>>>>>>> ??:??????????KDDI????????????????
>>>>>>>>       ?????????????????????????????
>>>>>>>> ??????????????????????
>>>>>>>>       ?????????????????????????????
>>>>>>>> ?????????????????????????????
>>>>>>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
>>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
>>>>> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
>>> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping> 
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 18 Feb 2008 17:14:49 +0900

Hi,

> Takuya,
> 
> If this change can be agreed quickly, let's go ahead and make it prior to 
forwarding to Jon/IESG (currently targetted for March) - that way we don't 
have a 
repeat of this discussion during IETF LC.  
> So, anyone else that might have feedback on this proposed text, please comment 
ASAP. 

I haven't heard any comments on Christer's proposal so far.
If no one speaks up today (Monday) in US time, can I modify the 
document as proposed and submit it?

Then, do we need new version (-06)?

Regards,
Takuya

> It is just to add another idea which was proposed in the recent discussion. 
Several ideas have already been there reflected from the similar type of 
discussion 
in the past.
> >   with a decreased version value in the o-line. It was also propsed to allow non
-2xx responses to PRACK, in order to reject an SDP offer carried in the PRACK.
 The 
response would still acknowledge the PRACK, and the UAS would cease 
transmission of 
the reliable provisional response acknowledged by the PRACK request. Some of 
the 

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2008 10:02:40 -0500

I agree that the proposed addition is accurate in that it does indeed
describe something that was proposed. So I don't have any great
objection to including this statement.

That doesn't mean I agree such a solution is workable.

	Thanks,
	Paul

---

From: "Fred Seymour" <[email-masked]>
Date: Tue, 19 Feb 2008 01:53:58 +0900

Hi.

OK, I agree the proposed text of yours.

Regards,

Fred

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 18 Feb 2008 13:34:41 -0500

I agree with Paul concerning Christer's proposed text.  The text is
accurate; but the additional proposal does not appear to be a workable
solution.

I prefer PRACK 488 be discussed within the draft separately from
Christer's proposed solution.  This would potentially impact sections
2.2, 3.2, 4.1, and/or 6.1.  As suggested by Paul within a prior email,
the text would be based upon the resolution of the careful analysis of
rfc3262.  As mention earlier, my analysis is that the UAC should act
upon the PRACK 488 and resend the PRACK with higher cseq and appropriate
SDP adjustments (or no SDP).  I'll read rfc3262 again; and I assume Paul
and Christer will do the same.

Based upon my re-reading of rfc3262, I'll send a follow-up email later
today or tomorrow.

Thanks,
Brett

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, February 18, 2008 10:03 AM
> To: Takuya Sawada
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Brett Tate
> I agree that the proposed addition is accurate in that it 
> does indeed describe something that was proposed. So I don't 
> have any great objection to including this statement.
> 
> > forwarding to Jon/IESG (currently targetted for March) - 
> that way we 
> > don't have a repeat of this discussion during IETF LC.
> >> So, anyone else that might have feedback on this proposed text, 
> >> please comment
> > ASAP. 
> > 
> recent discussion. 
> > Several ideas have already been there reflected from the 
> similar type 
> > of discussion in the past.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 Feb 2008 23:03:33 +0100

Hi,
 
My proposal (and I guess it's what Paul said also) is that the detailed investigation whether/how PRACK 488 works should be done as a separate task.
 
The only thing proposed is that we in the offer-answer drafts indicates it as one of the alternatives (there are others too) which has been proposed. That it not an agreement that we will go for that specific solution, nor is it an agreement that it would actually work (a detailed investigation would be needed for that). And, so far nobody has objected to adding the text, so... :)
 
Then, if we want to continue the PRACK 488 discussion, I propose we change the topic to "PRACK 488" and leave the offer-answer draft out of it :)
 
Regards,
 
Christer

________________________________

From: Brett Tate [mailto:[email-masked]]
Sent: Mon 18/02/2008 19:34
To: Takuya Sawada
Cc: [email-masked]; Christer Holmberg; [email-masked]; Paul Kyzivat
Subject: RE: [Sipping] sipping-sip-offeranswer-05: comments and questions

Thanks,
Brett

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 18 Feb 2008 20:19:06 -0500

The following reflects my analysis of rfc3262 concerning PRACK failure
responses.  My recommendations concerning sipping-sip-offeranswer-05 are
discussed within the last section.

-----

This section reflects analysis indicating support for PRACK failure
responses and requirement for UAC to handle them appropriately.  When
appropriate, the failure responses should trigger resubmission of PRACK
with higher CSeq (unless 503 triggers rfc3263 advancing) and appropriate
header/body modifications.

Tables 1 and 2 indicate that failure responses to PRACK were considered
and are allowed.

Proxies can return failure responses.  Thus the UAC should not assume
the PRACK has been processed by the device awaiting PRACK unless the
response (such as 2xx or 481) provides such indication.

RFC 3262 section 4: "Note that the PRACK is like any other non-INVITE
request within a dialog."

RFC 3262 section 3: "PRACK is like any other request within a dialog,
and the UAS core processes it according to the procedures of Sections
8.2 and 12.2.2 of RFC 3261."

-----

This section reflects analysis concerning text within rfc3262 which
supports treating PRACK more like an ACK instead of other requests
within a dialog (such as an UPDATE).  This interpretation requires UAS
to avoid sending failure responses and/or allowing the 100rel
"acknowledgment" to be based upon receiving PRACK instead of the
returning of PRACK 2xx.  In my opinion, both of these potential
interpretations require the text to be interpreted out of context.

RFC 3262 section 3: "If the PRACK instead contained any other type of
body, the body is treated in the same way that body in an ACK would be
treated."  I think it is just a text error since prior text refers to a
section of rfc3261 which might trigger a 415 response.  And the 415 is
clearly indicated within rfc3262 table 1.

RFC 3262 section 3: "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."  My
interpretation is that this paragraph does not preempt prior paragraphs
concerning processing like any other request within a dialog.  However I
might be missing a subtle difference between this RFCs use of "UA core"
and "UAS core".

RFC 3262 section 3: "Retransmissions of the reliable provisional
response cease when a matching PRACK is received by the UA core." <snip>
"If a reliable provisional response is retransmitted for 64*T1 seconds
without reception of a corresponding PRACK, the UAS SHOULD reject the
original request with a 5xx response."  When read together,
"retransmitted" could indicate that receiving PRACK
completes/acknowledges the 100rel transaction instead of it being
completed/acknowledged by the sending the PRACK 2xx.  However I think
that it is just an unfortunate use of "retransmitted"; although the
"retransmitted" aspects could also be reflecting the normative statement
about stopping retry when sending PRACK 2xx instead of the non normative
statement "cease when a matching PRACK is received by the UA core".

-----

I think the following changes should be made to
sipping-sip-offeranswer-05.  The text can be discussed after rfc3262
detailed analysis by Paul, Christer, and others.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 19 Feb 2008 10:07:13 +0100

Hi Brett, 

>The following reflects my analysis of rfc3262 concerning 
>PRACK failure responses.  My recommendations concerning 
>sipping-sip-offeranswer-05 are discussed within the last section.
> 
>-----
> 
>This section reflects analysis indicating support for PRACK 
>failure responses and requirement for UAC to handle them 
>appropriately.  When appropriate, the failure responses 
>should trigger resubmission of PRACK with higher CSeq (unless 
>503 triggers rfc3263 advancing) and appropriate header/body 
>modifications.
> 
>Tables 1 and 2 indicate that failure responses to PRACK were 
>considered and are allowed.
> 
>Proxies can return failure responses.  Thus the UAC should 
>not assume the PRACK has been processed by the device 
>awaiting PRACK unless the response (such as 2xx or 481) 
>provides such indication.
> 
>RFC 3262 section 4: "Note that the PRACK is like any other 
>non-INVITE request within a dialog."
> 
>RFC 3262 section 3: "PRACK is like any other request within a 
>dialog, and the UAS core processes it according to the 
>procedures of Sections
>This section reflects analysis concerning text within rfc3262 
>which supports treating PRACK more like an ACK instead of 
>other requests within a dialog (such as an UPDATE).  This 
>interpretation requires UAS to avoid sending failure 
>responses and/or allowing the 100rel "acknowledgment" to be 
>based upon receiving PRACK instead of the returning of PRACK 
>2xx.  In my opinion, both of these potential interpretations 
>require the text to be interpreted out of context.
> 
>RFC 3262 section 3: "If the PRACK instead contained any other 
>type of body, the body is treated in the same way that body 
>in an ACK would be treated."  I think it is just a text error 
>since prior text refers to a section of rfc3261 which might 
>trigger a 415 response.  And the 415 is clearly indicated 
>within rfc3262 table 1.
> 
>RFC 3262 section 3: "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."  My interpretation is that this 
>paragraph does not preempt prior paragraphs concerning 
>processing like any other request within a dialog.  However I 
>might be missing a subtle difference between this RFCs use of 
>"UA core" and "UAS core".
>
>RFC 3262 section 3: "Retransmissions of the reliable 
>provisional response cease when a matching PRACK is received 
>by the UA core." <snip> "If a reliable provisional response 
>is retransmitted for 64*T1 seconds without reception of a 
>corresponding PRACK, the UAS SHOULD reject the original 
>request with a 5xx response."  When read together, 
>completes/acknowledges the 100rel transaction instead of it 
>being completed/acknowledged by the sending the PRACK 2xx. 

Correct. This is similar to ACK, which is going to cease the
re-transmission of 200 OK no matter whether what the UAS will do with a
potential SDP body in the ACK.
 
>However I think that it is just an unfortunate use of 
>"retransmitted"; although the "retransmitted" aspects could 
>also be reflecting the normative statement about stopping 
>retry when sending PRACK 2xx instead of the non normative 

I doubt we will find clear answers from 3262. We have to decided how we
want to have it, if we want to fix it.

Regards,

Christer

---

From: Takuya Sawada <[email-masked]>
Date: Tue, 19 Feb 2008 22:32:27 +0900

Hi,

Now I think we can reach the agreement to add Christer's text.
I have already done it.

How about Brett's proposal on PRACK 488?
I don't think we can reach the consensus on PRACK 488 behaviour.
Christer proposed to make separate document to define 'new' normative
behaviour. We may need more discussion.
Then IMO, for the time being, "PRACK request should not be rejected"
approach seems to be good and Christer's text and proposal can hopefully
cover your concern.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 19 Feb 2008 14:56:57 -0500

> I don't think we can reach the consensus 
> on PRACK 488 behaviour.  Christer proposed to 
> make separate document to define 'new' normative 
> approach seems to be good and Christer's text 
> and proposal can hopefully cover your concern.

Christer's proposed text does not satisfy my concern.  It potentially
makes it worse since the wording is unclear about which aspect (if any)
"violates current rules".  I think the violation is thinking that the
response satisfactorily "acknowledges" the reliable response; however
others might think it is the sending of the 488/606.  (The UPDATE 504
response is discussed within rfc3311; however I'm not sure if anyone
would similarly send a PRACK 504 or a PRACK SDP that would cause it.)

I think that sipping-sip-offeranswer-05 is misleading, incomplete, or
inaccurate concerning PRACK 488 and "PRACK request should not be
rejected".  

Section 2.2 does not indicate the potential for PRACK 488.  Thus devices
might not realize that a PRACK 488 may be sent or understand would
should occur when received.  I have no issue with the draft discouraging
PRACK 488 in favor of a "rejection" SDP within PRACK 200.  However since
PRACK 488 can be compliantly triggered by proxies; the UAC should expect
488 and realize that the 100rel might not have been satisfactorily
acknowledged.

The "PRACK request should not be rejected" statements are used without
providing justification or insurance that rfc3262 actually indicates
"PRACK request should not be rejected".

Section 6.1 is misleading, incomplete, or inaccurate concerning the
issue with and without Christer's proposed text.  PRACK 488 is valid and
be sent by proxies; it is an open issue concerning compliance and
meaning if sent by non proxy.  Thus the PRACK 488 may or may not
currently contradict "The current RFCs do not provide a way to reject
the offer and at the same time to acknowledge the reliable response".
It obviously satisfies the "way to reject the offer"; however it
requires subsequent PRACK without or with modified SDP to ensure
acknowledgement of reliable response.

> > sipping-sip-offeranswer-05.  The text can be discussed 
> > after rfc3262 detailed analysis by Paul, Christer, and others.
> > 
> > Concerning "PRACK request should not be rejected" within 
> > sections 3.2 and 4.1, I don't think such a statement should be 
> > made without clarification somewhere concerning the reason.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 16:20:00 -0500

Brett,

I think I agree with your points. Can you propose text that will satisfy 
your concerns?

	Thanks,
	Paul

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 20 Feb 2008 10:38:48 +0900

Hi, Brett,

I think I see your points, too.
As Paul also said, we will be happy and incorporate it if you could
provide the text to be added or modified.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 19 Feb 2008 21:13:22 -0500

The following is my proposed text.  However I'm currently awaiting
replies from the SIP working group:
http://www.ietf.org/mail-archive/web/sip/current/msg22131.html.  The
replies might obviously cause the need for further adjustment.

I propose adding the following to section 2.2.  I have no strong
recommendation concerning folding the text within paragraph 4 or adding
new paragraph 5.

"The validity and consequences of a 488 response to PRACK is an open
issue which is discussed within a sequent section.  If a 488 response is
received, the UAC should ensure acknowledgment of the reliable response
by sending a new PRACK with the offer removed or modified based upon the
received 488 response.  If a 488 response is sent by UAS, it should
accommodate receiving the altered PRACK with higher CSeq without
expecting it to trigger a 481 response."

Section 3.2 old: "However, as a PRACK request should not be rejected,
the UA is recommended to send a PRACK request only when it has strong
reasons to expect the receiver will accept it."

Section 3.2 new: "However, to avoid problems or delays caused by PRACK
offer rejection, the UA is recommended to send a PRACK request only when
it has strong reasons to expect the receiver will accept it."

I assume the following section 4.1 snippet corresponds to re-INVITE
since I think the UPDATE offer otherwise appears non compliant to
rfc3311.  However the following proposal also applies if corresponds to
initial INVITE.

Section 4.1 old: "As a PRACK request should not be rejected, UA A is
recommended to wait for answer1 before sending a PRACK response with the
answer to the offer2."

Section 4.1 new: "To avoid rejecting the PRACK or PRACK offer, UA A is
recommended to wait for answer1 before sending a PRACK response with the
answer to the offer2."

Section 6.1 old: "The current RFCs do not provide a way to reject the
offer and at the same time to acknowledge the reliable response."

Section 6.1 new: "The current RFCs do not provide a way to reject the
offer and at the same time indicate that the PRACK adequately
acknowledged the reliable response."

I also propose adding the following new paragraph to section 6.1 as the
third paragraph.

"The 488 response is another proposed solution; however the validity and
consequences of a 488 response to PRACK is an open issue.  Because the
488 response may be sent by a proxy, the UAC cannot assume the reliable
transaction has been adequately acknowledged.  If a 488 response is
received, the UAC should ensure acknowledgment of the reliable response
by sending a new PRACK with the offer removed or modified based upon the
received 488 response.  If the 488 response is sent by UAS (open issue),
it cannot assume that the UAC thinks that the reliable transaction has
been adequately acknowledged even though the UAS may treat otherwise
(open issue).  If a 488 response is sent by UAS, the UAC should
accommodate receiving the altered PRACK with higher CSeq without
expecting it to trigger a 481 response."

Thanks,
Brett

> Sent: Tuesday, February 19, 2008 4:20 PM
> To: Brett Tate
> Cc: Takuya Sawada; [email-masked]; 
> I think I agree with your points. Can you propose text that 
> will satisfy your concerns?
> 
> 	Thanks,
> 	Paul
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 20 Feb 2008 09:32:44 +0100

Hi,

>The following is my proposed text.  However I'm currently 
>awaiting replies from the SIP working group:
>http://www.ietf.org/mail-archive/web/sip/current/msg22131.html
>.  The replies might obviously cause the need for further adjustment.
> 
>I propose adding the following to section 2.2.  I have no 
>strong recommendation concerning folding the text within 
>paragraph 4 or adding new paragraph 5.
> 
>"The validity and consequences of a 488 response to PRACK is 
>an open issue which is discussed within a sequent section.  
>If a 488 response is received, the UAC should ensure 
>acknowledgment of the reliable response by sending a new 
>PRACK with the offer removed or modified based upon the 
>received 488 response.  If a 488 response is sent by UAS, it 
>should accommodate receiving the altered PRACK with higher 
>CSeq without expecting it to trigger a 481 response."

I am not sure I understand. First you say that PRACK 488 is an open
issue, which is true, but then you continue saying what the UAC/UAS
should do regard to PRACK 488. I think THAT is the open issue we're
supposed to continue investigating.

So, shouldn't we just keep the first two lines in chapter 2.2? The rest
should be in chapter 6.1, which you also propose futher down in the
mail.

>Section 3.2 old: "However, as a PRACK request should not be 
>rejected, the UA is recommended to send a PRACK request only 
>when it has strong reasons to expect the receiver will accept it."
> 
>Section 3.2 new: "However, to avoid problems or delays caused 
>by PRACK offer rejection, the UA is recommended to send a 
>PRACK request only when it has strong reasons to expect the 
>receiver will accept it."

Looks good.

>I assume the following section 4.1 snippet corresponds to 
>re-INVITE since I think the UPDATE offer otherwise appears 
>non compliant to rfc3311.  However the following proposal 
>also applies if corresponds to initial INVITE.
> 
>Section 4.1 old: "As a PRACK request should not be rejected, 
>UA A is recommended to wait for answer1 before sending a 
>PRACK response with the answer to the offer2."
> 
>Section 4.1 new: "To avoid rejecting the PRACK or PRACK 
>offer, UA A is recommended to wait for answer1 before sending 
>a PRACK response with the answer to the offer2."

Looks good.
 
>Section 6.1 old: "The current RFCs do not provide a way to 
>reject the offer and at the same time to acknowledge the 
>reliable response."
> 
>Section 6.1 new: "The current RFCs do not provide a way to 
>reject the offer and at the same time indicate that the PRACK 
>adequately acknowledged the reliable response."

I would add the follwoing: "It is unclear whether a non-200 response
still indicates an acknowledgement of the reliable response."

>I also propose adding the following new paragraph to section 
>6.1 as the third paragraph.
> 
>"The 488 response is another proposed solution; however the 
>validity and consequences of a 488 response to PRACK is an 
>open issue.  Because the 488 response may be sent by a proxy, the UAC
cannot assume 
>the reliable transaction has been adequately acknowledged.
>If a 488 response is received, the UAC should ensure 
>acknowledgment of the reliable response by sending a new 
>PRACK with the offer removed or modified based upon the 
>received 488 response.
>If the 488 response is sent by UAS (open issue), it cannot assume that
the UAC thinks that the 
>reliable transaction has been adequately acknowledged even though the
UAS may treat otherwise (open issue).  If a 488 
>response is sent by UAS, the UAC should accommodate receiving the
altered PRACK with higher CSeq without expecting it to trigger a 481
response."

I think that we should add "(open issue)" also to the last sentence,
because that is something we are still discussing.

Also, you don't clearly say whether the 488 (if sent by the UAS) ceases
the re-transmission of the 18x response. Reading the text about I guess
that is what you mean.

Regards,

Christer

> > I think I agree with your points. Can you propose text that will 
> > satisfy your concerns?
> > 
> > 	Thanks,
> > 	Paul
> >

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 20 Feb 2008 18:14:03 +0900

Hi,

Basically, I agree with Christer's responses.
Anyway I will wait for the replies from SIP ML for a while

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 20 Feb 2008 11:19:43 -0500

Hi Christer,

Thanks for the response.  Replies inline.

> >issue which is discussed within a sequent section.
> acknowledgment of 
> >the reliable response by sending a new PRACK with the offer 
> removed or 
> >modified based upon the received 488 response.  If a 488 response is 
> >sent by UAS, it should accommodate receiving the altered PRACK with 
> >higher CSeq without expecting it to trigger a 481 response."
> 
> I am not sure I understand. First you say that PRACK 488 is 
> an open issue, which is true, but then you continue saying 
> what the UAC/UAS should do regard to PRACK 488. I think THAT 
> is the open issue we're supposed to continue investigating.
>
> So, shouldn't we just keep the first two lines in chapter 
> 2.2? The rest should be in chapter 6.1, which you also 
> propose futher down in the mail.

I currently think that the paragraph is applicable regardless of the
resolution of the open issues.  However your proposed adjustment is ok
with me since similar statements are mentioned within the open issues
section.

> reject the 
> reject the 
> I would add the following: "It is unclear whether a non-200 
> response still indicates an acknowledgement of the reliable response."

The addition is ok with me if it is reworded to be something like "It is
unclear which failure responses might indicate adequate acknowledgement
of the reliable response."  The rewording is needed because some failure
responses like 401 and 407 could never indicate acknowledgement of the
reliable response.

> >"The 488 response is another proposed solution; however the validity 
> >and consequences of a 488 response to PRACK is an open 
> issue.  Because 
> >the 488 response may be sent by a proxy, the UAC
> cannot assume 
> acknowledgment of 
> >the reliable response by sending a new PRACK with the offer 
> removed or 
> >modified based upon the received 488 response.
> altered PRACK with higher CSeq without expecting it to 
> trigger a 481 response."
> 
> I think that we should add "(open issue)" also to the last 
> sentence, because that is something we are still discussing.

Because failure responses can be returned by proxies, the UAS should
tolerate the subsequent PRACK since UAC does not know if 488 triggered
by proxy or UAS seeking acknowledgement of the reliable response.  Thus
the UAS needs to tolerate the PRACK instead assuming the 481 would more
appropriate.  I do not consider it an open issue; however if others do,
adding "(open issue)" is ok with me.

> Also, you don't clearly say whether the 488 (if sent by the 
> UAS) ceases the re-transmission of the 18x response. Reading 
> the text about I guess that is what you mean.

I was attempting to keep sipping-sip-offeranswer neutral concerning
stopping the retransmissions.  The retransmissions are not needed since
the UAS knows the UAC received the 18x and UAC should not re-transmit
the PRACK again if 18x received again.  However stopping the
retransmissions is one aspect of "even though the UAS may treat
otherwise (open issue)."
_______________________________________________
Sipping mailing list  http://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, 20 Feb 2008 19:28:29 +0100

Hi Brett,
 
>>and consequences of a 488 response to PRACK is an open issue.  Because
>>the 488 response may be sent by a proxy, the UAC cannot assume
>>If a 488 response is received, the UAC should ensure acknowledgment of
>>the reliable response by sending a new PRACK with the offer removed or
>>the UAC thinks that the reliable transaction has been adequately acknowledged even though the
>>UAS may treat otherwise (open issue).  If a 488 response is sent by UAS, the UAC should accommodate receiving the
>>altered PRACK with higher CSeq without expecting it to trigger a 481 response."
>

I consider it an "open issue", since it is not cdefined in 3262 (or anywhere else today). So, I don't see it as a "offer/answer clarification", but more like a normative procedure.

Again, that doesn't necessarily mean I disagree with you argument :)

>retransmissions is one aspect of "even though the UAS may treat

I agree that the retransmission is not directly related to offer/answer, so I am ok if we leave it out. But, again, it IS something that we will have to specify somewhere else :)
 
Regards,
 
Christer