Subject: Re: VS: VS: [Sipping]FW:I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt(Comments 4 to 6)

From: Takuya Sawada <[email-masked]>
Date: Mon, 3 Jul 2006 15:12:50 +0900

Hi,

Basically, I agree to Christer's last comment for new contents.

Let me summarize and propose the results including others.

---
[New contents to be added]

* Introducing a way to reject offers without rejecting PRACK request.
 For example.
 - Message without SDP
 - port 0 in m= line to revert
 - SDP sess-ver decrease (Need to describe how to react decreased sess-ver?)

 -> Proposed Solution: Create new chapter and summarize the problem
    and possible change/extentions to the existing rules to resolve it.
    (They should be FFS and not be fixed in this document)

* How to build the answer to re-INVITE without offer
 - Clarify the recommended format for the answer
 - Note for hold/un-hold issue
 
 This is the offer/answer usage peculiar to SIP and better to be described
 in the document.

 -> Proposed Solution: Create new chapter to describe it.

---
[Clarification]

> That also needs to be clarified. Does it mean that the UAS MAY genereate a 
> reliable provisional response, and it then MUST include an answer? OR, 
> does it mean that the UAS MAY generate a reliable provisional response, 
> and it then MAY include an answer? From the discussions we've had on the 
> mailing lists I believe that it is OPTIONAL to include an answer in a 
> reliable provisional response, and I think it should be clarified in the 
> draft.

 -> I believe it is optional, too. To be clarified.

> (In Chapter 2.2)
> The text does say it, but I think it could be more clearly pointed out that
> a PRACK can be used for sending an offer only when the reliable provisional
> response it is acknowledging contained an answer.

 -> To be more clarified. I am not sure how, yet.

> If a node cannot accept an offer in a SIP response, I think one option should
> also be to simply release the session. It's pretty much an implementation
> issue. And, mandating the clients to start sending new offers/answers simply
> to "synchronize" the SDP state at both ends is again very complex, and may
> (at least in theory) cause never-ending offer/answer loops.

 -> The above mentioned optional case to be added. And also cares for loop
    avoidance may be added.

---
[Nits]
> On page 3 "In pattern 5, PRACK request can contain an offer only if the 
> non-reliable response which it acknowledges..." - the PRACK acks a reliable 
> 1xx, of course.
> 
> I thought the last two paragraphs in section 3.1 were a little hard to make 
> sense of and could be clarified.

 -> To be fixed.
---

Comments?

Regards,
Takuya

> 
> Hi,
> 
> I can understand if we don't want to change the existing rules in this draft, so 
as far as I am concerned we don't need to discuss that.
> 
> HOWEVER, I still DO think it would be very important to DOCUMENT the ISSUES (for 
example how to reject an offer in a PRACK, and why one MUST send an offer in 
the 
first reliable provisional response to an empty INVITE) we've been discussing,
 and 
maybe even give some "hints" on how they COULD be solved (and/or which RFCs 
they 
would impact). The actual changes we can then do as a separate work.
> 
> Otherwise, the same questions will come up over and over again on the list(s), and
 on the interop events...
> 
> When it comes to the issue about what to send in the offer to an empty re-INVITE, 
I think that is something we SHALL document. Because, it does NOT change any 
existing rules - it clarifies a behavior.
> 
> Regards,
> 
> Christer
> 
> 
> 
>  
> 
> -----Original Message-----
> From: Takuya Sawada [mailto:[email-masked]] 
> Sent: 30. kes臾uuta 2006 10:08
> To: [email-masked]; Christer Holmberg (JO/LMF)
> Cc: [email-masked]; [email-masked]
> Subject: Re: VS: VS: [Sipping]FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-
01.txt(Comments 4 to 6)
> 
> Hi,
> 
> > Takuya has been very quiet during this conversation. The draft is 
> > really his, with me as secondary collaborator. So he should get final 
> > say in what goes into the draft.
> 
> Let me excuse myself first.
> I took days off early in this week. After coming back work, I have been busy to 
catch up my daily work (and world-cup games, too).
> Then I have not yet followed the discussion so far.
> I will take time this weekend to follow up and make some comments on the issues 
next week.
> Basically, I will try to incorporate the discussed issues into the draft.
> 
> Also, it may be more imporatnt, I would like to see how this draft goes for the 
next step.
> We should ask the chairs and make consensus in the list. But before doing that, 
probably we must make it clear what is the scope of the draft.
> That is, whether we intend to change the rules described in the existing RFCs, or 
just to summarize the rules and recommend something within the rules. My first
 
intention was the latter, and is still the same so far.
> Let us confirm.
> I believe that many feel it is useful information and worth considering whether it
 should become a working group item.
> 
> Regards,
> Takuya
> 
> > 
> > Christer Holmberg (JO/LMF) wrote:
> > > Hi Paul,
> > > 
> > > Thanks for your clarifications! I think we're getting in on the same 
> > > frequency - at least on this issue :)
> > 
> > Yes, I think we more or less have been all along - just using 
> > different words.
> > 
> > >>> Now, my question: since "Called party" may have no clue about the
> > > scenario, and no clue about all the other entities
> > >>> involved, how does it know that it "wants" to send such offer at 
> > >>> this
> > > point?
> > > 
> > >> This idea of what the UA "wants" to do is a nebulous one, but I 
> > >> think
> > > it can be determined without regard to the intent
> > >> of the other party.
> > >>
> > >> Roughly speaking, I think "want" means "what the UA is *capable* of
> > > doing. For example, if the UA is capable of using 5
> > >> codecs, then it *ought* to list all five, even though in a prior
> > > exchange four of them had been rejected by the other
> > >> party. (That covers your case here.)
> > > 
> > > 
> > > [CHH] Yes. I have used the sentence "creat an offer as for a new 
> > > call", but I guess we mean the same thing. [/CHH]
> > 
> > Its almost the same. There are some subtle potential differences. For 
> > instance, the numbers assigned to the codec types are supposed to 
> > remain unchanged. They might differ from what the UA would put into an 
> > initial invite. In all cases the constraints applied by 3264 need to 
> > be followed. They aren't very severe for subsequent offers, but they exist.
> > 
> > >> But it isn't quite that simple in all cases. Consider a UA that has
> > > both audio and video capabilities. Whether the UA
> > >> "wants" to use video may change over time depending on options in 
> > >> the
> > > UI of the UA. This could change mid-call.
> > > 
> > > [CHH] Correct. And, IF the user is able to interact with the UA it 
> > > may not be a problem. But, in the case of an interworking node that 
> > > may not be possible. [/CHH]
> > 
> > If the user isn't able to interact then what is wanted just doesn't change.
> > 
> > For a UA like a gateway, the "user" is the PSTN, and indicates what it 
> > wants via ISUP or whatever.
> > 
> > >> Similarly for "hold". There is typically a control in the UI which
> > > indicated the user's desire to hold the call. And each
> > >> end has such an option. In each offer/answer, the decision of 
> > >> whether
> > > to offer sendonly, recvonly, sendrecv, or inactive
> > >> is determined by the *local* state, not anything learned about the
> > > remote party in a prior exchange.
> > >> (Some UAs may not have a local control of HOLD. If not, then they
> > > probably always offer sendrecv.)
> > >> If each end asserts its own interests, as well as following the 
> > >> rules
> > > of offer/answer, then the most acceptable mutual
> > >> agreement will be reached.
> > > 
> > > 
> > > [CHH] In the example "called party" had not been on hold. But, if 
> > > "called party" would have been put on hold, prior to receiving the 
> > > empty re-INVITE, the question would have been: when "called party" 
> > > generates the capable-of-doing offer to be sent in the 200 OK, shall 
> > > it also un-hold the call (even if "controller" initially initiated the hold)?
> > 
> > Yes. If the controller still wants the call on hold then it is 
> > perfectly free to do so in the answer.
> > 
> > > In the example, IF "called party" would have been on hold when 
> > > receiving the empty re-INVITE, and would NOT un-hold when sending 
> > > the new offer in 200 OK, "controller" would have to understand that 
> > > IT must send an un-hold offer before "called party" and "pre-paid 
> > > user" can start to communicate. It could become rather complicated...
> > 
> > Nor would it have any reason to believe that would work. For hold, 
> > things become a mess if the UAs don't behave this way.
> > 
> > In particular, if both parties put the call on hold, then if you 
> > aren't careful, there is no way to get out of hold.
> > 
> > > So, whatever "solution" we come up with, I think we shall describe 
> > > in the offeranswer draft. [/CHH]
> > 
> > Takuya has been very quiet during this conversation. The draft is 
> > really his, with me as secondary collaborator. So he should get final 
> > say in what goes into the draft.
> > 
> > But I do agree with you now that his is another of those pieces of 
> > folk wisdom that needs to be written down somewhere.
> > 
> > 	Paul
> > 
> > > Regards,
> > > 
> > > Christer
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.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
> 
> --------
> 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]
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.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

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

_______________________________________________
Sipping mailing list  https://www1.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: Mon, 03 Jul 2006 18:31:56 -0400

All sounds good to me.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 4 Jul 2006 15:26:10 +0200

Hi,
 
Your proposals look good to me too.
 
However, I think you missed one issue: the MUST to include an offer in the FIRST reliable provisinal response in case the INVITE did not contain an offer. It is mandatory today, but it is one of the rules that we MAY want to change in future. It looks like there are no clear justification for it, and I know it has also caused some problems in implementations.
 
Regards,
 
Christer

________________________________

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tue 04/07/2006 00:31
To: Takuya Sawada
Cc: Christer Holmberg (JO/LMF); [email-masked]
Subject: Re: VS: VS: [Sipping]FW:I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt(Comments 4 to 6)

All sounds good to me.

        Paul

Takuya Sawada wrote:
>> Sent: 30. kes?uuta 2006 10:08

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 5 Jul 2006 17:47:34 +0900

Hi,

OK. This item is to be added as new content to record the cyrrent
discussion for the future.

> It looks like there are no clear justification for it, and I know
> it has also caused some problems in implementations.

If someone know "the clear justification" for it, please point
it out.

Regards,
Takuya

> However, I think you missed one issue: the MUST to include an offer in the FIRST 
reliable provisinal response in case the INVITE did not contain an offer. It 
is 
mandatory today, but it is one of the rules that we MAY want to change in 
future. It
 looks like there are no clear justification for it, and I know it has also 
caused 
some problems in implementations.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Jul 2006 12:54:36 -0400

I just fielded a question on offer/answer that raised what seems like a
new issue. Here is the case - Alice calling Bob:

- Alice calls Bob: INVITE w/offer1, 200ok w/answer1, ACK
- Alice reINVITE Bob w/offer2
- Bob respond reliable 18x w/answer2
- Alice PRACK the 18x
- Bob 200ok the PRACK
- Alice UPDATE w/offer3
- Bob 200ok the UPDATE w/answer3
- Bob respond 4xx to reINVITE
- Alice ACK the reINVITE

At this point, what SDP is in effect?
It seems like it should be offer1/answer1,
but I think the various specs don't give guidance that would lead to
that result. It is easy to conclude that according to the specs it
should be offer3/answer3, because the failure of the reinvite doesn't
necessarily influence the UPDATE.

Or do others think the result *ought* to be offer3/answer3?

I was thinking of this in the context of offer3 resolving preconditions
initiated by offer2, but of course this can happen without preconditions
as well.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 19 Jul 2006 02:06:24 +0200

Paul,

I seem to remember that we once said the behavior below is not acceptable 
for a UAS: if it is going to send a 4xx response (or non-2xx in general), it 
should do so as soon as possible, and not first send a reliable 18x. I 
realize this is slightly beside the point, but we could end up defining that 
for the offer-answer sequence any 18x response here is considered as "will 
eventually succeed", and thus any 4xx that follows should be disregarded. 
Following this reasoning, the final outcome would be offer3/answer3

Your question comes down to: does failure of a reINVITE roll back all 
offer/answer exchanges that happen "in the context" of that reINVITE? My 
initial response would be "no", because there is no such context from the 
perspective of the offer/answer mechanism. All it considers is the ordered 
sequence of offer/answer exchanges, disregarding the "vehicle" that is used 
to carry them. When an offer is answered, that pair is the outcome. That 
would imply that without the UPDATE below, offer2/answer2 would be in effect 
even if a 4xx follows.

Regards,

jeroen

---

From: [email-masked]
Date: Wed, 19 Jul 2006 12:47:58 -0400

From: Paul Kyzivat <[email-masked]>

Assuming that offer2 isn't committed to be in effect until the final
response to the re-INVITE (I might be behind on the consensus here),
the UPDATE with offer3 is a glare, and should be rejected with 491.
Actually, Alice shouldn't be sending it at all, since she knows the
re-INVITE isn't finished.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 13:15:31 -0400

> re-INVITE isn't finished.

The above is exactly what would be required if offer2 contained 
unresolved preconditions. In that case, the reinvite will never complete 
until the preconditions are resolved. So you can't ban this usage unless 
you ban preconditions in reinvites.

I don't think glare applies here.

IMO this case is not adequately addressed by any existing RFC or draft.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 13:41:16 -0400

Jeroen van Bemmel wrote:
> Paul,
> 
> I seem to remember that we once said the behavior below is not 
> acceptable for a UAS: if it is going to send a 4xx response (or non-2xx 
> in general), it should do so as soon as possible, and not first send a 
> reliable 18x.

This isn't always possible. For instance the reINVITE might contain an
Expires header. When the time expires, the reINVITE should be aborted,
with a 487 response. Or the UAC could send a CANCEL to the reinvite. Or
the UAS may time out the request on its own.

> I realize this is slightly beside the point, but we could 
> end up defining that for the offer-answer sequence any 18x response here 
> is considered as "will eventually succeed", and thus any 4xx that 
> follows should be disregarded. Following this reasoning, the final 
> outcome would be offer3/answer3
> 
> offer/answer exchanges that happen "in the context" of that reINVITE?

Yup.

> My 
> initial response would be "no", because there is no such context from 
> the perspective of the offer/answer mechanism.

I agree that there isn't one, but perhaps there needs to be.
The problem is really with the language in section 14 of 3261:

   If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.

When combined with PRACK and UPDATE extensions, this seems to require
some notion of a context for the offers and answers.

> All it considers is the 
> ordered sequence of offer/answer exchanges, disregarding the "vehicle" 
> that is used to carry them. When an offer is answered, that pair is the 
> outcome. That would imply that without the UPDATE below, offer2/answer2 
> would be in effect even if a 4xx follows.

What you imply is one possible way of clarifying the situation:

- the offer and answer are "committed" when the answer is formally
received. Once committed, no action rolls them back.

- for a basic reinvite, without 100rel, the answer is not formally
received until the final response. If the final response is >= 300 then
the offer is not committed and things continue in status before the
reinvite was sent. Before the final response, media may be received
based on the pending offer, and if SDP is received in an unreliable 1xx
then media may be sent based on the pending answer while awaiting the
actual answer.

- When 100rel is used, an offer and answer may be committed sooner.

- If a reliable 1xx contained an answer, and a PRACK (without SDP) is
sent to confirm it, then the UAS commits the offer/answer upon sending a
2xx to the PRACK, and the UAC commits the offer/answer upon receiving
the 2xx to the PRACK.

- Working out the commit points when the PRACK contains an offer or
answer makes my head hurt. I'm not going to try to work that out right now.

- When an UPDATE with offer is sent, the UAS commits the offer/answer
when sending a 2xx response w/answer to the UPDATE, and the UAC commits
the offer/answer when receiving the 2xx response.

While I think this could be made to work, I'm inclined to think it would
be better to do the commit only upon completion of the reINVITE. It
would be far better when preconditions are used, because it would mean
you wouldn't end up committing SDP with unresolved preconditions.

(Note that still would be a potential problem if UPDATE is used, with
preconditions, when no reINVITE is in progress.)

	Paul

> Regards,
> 
> jeroen
> 
> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> To: <[email-masked]>

---

From: [email-masked]
Date: Wed, 19 Jul 2006 13:54:56 -0400

Well, I would phrase it thusly:  Previously, any situation in which
one offer/answer negotiation was initated before a previous one had
completed was considered "glare" and was to be considered erroneous.
But we currently have use-cases which need to do this.  So we now have
to extend the offer/answer model to usefully handle situations in
which there are multiple negotiations at the same time.

If processing preconditions requires overlapping offer/answer
negotiations, the standard defining the use of preconditions should
have defined how to handle overlapping negotiations.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 14:29:26 -0400

> completed was considered "glare" and was to be considered erroneous.

I'm not following you. Look at the basic mechanisms in 3312. That RFC 
introduces all this usage. The only part it doesn't address is if it is 
used in a reINVITE.

The cases you are suggesting are glare also occur in the initial invite.

> which there are multiple negotiations at the same time.

I'm not suggesting multiple negotiations concurrently - all the offers 
and answers occur serially. The question is are: when a reINVITE fails, 
what is the state of the session?

	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 19 Jul 2006 17:01:54 -0400

Paul Kyzivat wrote:

>> unresolved preconditions. In that case, the reinvite will never 
>> complete    until the preconditions are resolved. So you can't ban 
>> this usage unless    you ban preconditions in reinvites.
>>
> introduces all this usage. The only part it doesn't address is if it 
> is used in a reINVITE.
>
> and answers occur serially. The question is are: when a reINVITE 
> fails, what is the state of the session?

Note that the issue is larger than just offer/answer. In general, when 
multiple requests are allowed to be processed in parallel, there can be 
various values that have been updated between the reINVITE (or other 
request) and its failure. For example, we may have received information 
about supported extensions, identity, or even a SUBSCRIBE within that 
dialog (not recommended, but certainly still possible), etc. I suspect 
few people will argue that all those changes would have to be rolled 
back to the state before the reINVITE if that reINVITE fails. What seems 
more reasonable (for offer/answer as well as any other value that may 
have been updated by other transactions in between) is for a rule like 
the following: If transaction T modifies a particular parameter P from 
value N to M, and T fails, then parameter P must have its value rolled 
back to N, if, and only if, the value of P is still M (i.e. no 
subsequent transactions modified it). This needs further refinement to 
deal with multiple overlapping transactions (whether issued by one or 
both sides in parallel), but going back to your original example 
(repeated below), I would say that that offer3/answer3 ought to be the 
what is in effect at the end:

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 19:21:34 -0400

Flemming Andreasen wrote:
> request) and its failure.

Yes, this is a bigger question, or multiple questions. I have been 
trying to keep them compartmentalized for sanity's sake.

I believe the offer/answer question is different than some of the others 
(specifically target refresh) for a couple of reasons:
- offer/answer pertains only to the invite dialog usage, not the dialog
   as a whole
- the text pertaining to the rollback of offer/answer state is in the
   chapter on sessions (aka invite dialog usage), whereas the section on
   dialogs gives rules for refresh of targets.

We could get into a similar discussion of session timer state, since 
that is specific to invite dialog usage. But that too is governed by 
text in a different place. Nevertheless, a consistent answer for the two 
would probably be a good thing.

> For example, we may have received information 
> dialog (not recommended, but certainly still possible), etc.

I think we will have to start out by considering these on a case by case 
basis. But we may want to sort them into one of a few buckets and then 
treat the buckets in a consistent way.

E.g. some things fall into the "dialog state" bucket, others into the 
"invite dialog usage state" bucket, others the "subscribe dialog usage 
state" bucket, etc. For some it is clear which bucket applies. For 
others it is far from clear.

All the ones that declare support for one thing or another are an open 
question. There is no clarity on what the scope of such a declaration 
is. If it was clear that the scope was a dialog then I would put them 
into the "dialog state" bucket. But I don't think that is the case.

> I suspect 
> back to the state before the reINVITE if that reINVITE fails.

In general I think I agree. And in general there is no language anywhere 
that says they should be, so its probably not an issue.

> What seems 
> subsequent transactions modified it).

What is another transaction T2 respecifies the value as M? Then the 
value is still M, so by your rule it should be rolled back even though a 
subsequent transaction "modified" it.

> This needs further refinement to 

I think examining use cases and checking the reasonableness of the 
answers is an important test. Does your answer pass the smell test?

Suppose this was a real case I described for somebody else: 
offer/answer1 establishes an audio session. Offer/answer2 adds video 
with unresolved preconditions. Offer/answer3 informs that Alice's 
preconditions have been resolved (but Bob's remain unresolved). Then Bob 
discovers he cannot get the resources and will not be able to resolve 
the preconditions, so fails the reinvite.

Is it reasonable to leave the session status with a media stream having 
unresolved preconditions?

I think the rollback is the better outcome. An alternative would be a 
2xx response with the video stream being refused by Bob. (But I think I 
can probably find another case where that won't work so well.)

> - Bob respond 4xx to reINVITE

In any case, I think it is probably wrong to even talk about "rollback". 
I think it will work much better to replace "rollback" with "delayed 
commit" - where changes made before the completion of the reINVITE 
transaction are not committed until the reinvite successfully completes. 
Meanwhile, for all other uses the original values remain operative.

So I think it comes down to whether we do "delayed commit" or "immediate 
commit" at some well defined points.

	Paul

---

From: [email-masked]
Date: Thu, 20 Jul 2006 16:13:31 -0400

OK, I've read RFC 3312.  Thanks for pointing me to that, Paul.

IMHO, the only way to deal with messy problems like this is to first
get a clear conceptual structure of the situation.  Studying the
precise interpretation of inherently ambiguous English usually leads
to more confusion.

In regard to SDP offer/answer, the original principles were:

1. SDP is negotiated by offer/answer cycles.  Each cycle must end
   before the next one begins.  An attempt to begin a new cycle before
   the previous one ends is a "glare" error.

2. Offer/answer cycles are done by sending an offer in an INVITE or
   UPDATE request, and an answer in a 2xx response, or (ugh) by
   sending an offer in a 2xx response to an INVITE and an answer in
   the ACK.

3. A copy of the answer may be carried by 1xx responses to an INVITE,
   but they do not terminate the offer/answer cycle; that is done only
   by the answer in a 2xx response.

4. If an offer/answer cycle is aborted (due to a failure response to
   the request carrying the offer), the media state is returned to the
   state before that offer/answer cycle started.

With the creation of PRACK (if I understand correctly):

5. If a UAC successfully sends a PRACK to a 1xx response which carried
   an answer, that 1xx is considered to terminate its offer/answer
   cycle.  Later 1xx and 2xx responses to the request need not carry
   the answer, though they may.  Such late answers are not meaningful.
   In such a situation a 2xx response to an INVITE may not carry a new
   offer.

At this point, it would seem natural that a completed offer/answer
cycle remains in effect even if the request bearing the offer fails,
because the cycle has been completed, and since that cycle, there may
have been successful UPDATE transactions.

With the introduction of preconditions, the implied "rollback" rule
is:

6. A precondition negotiation may contain several offer/answer cycles.
   If the precondition negotiation fails, the media state is returned
   to the state before the first precondition offer (which may be
   several cycles ago).

OK, here's where it gets ugly -- the natural interpretation of how to
handle precondition failures (roll back to before the INVITE)
conflicts with the natural interpretation of an INVITE modified by
intervening UPDATEs.

(Note that RFC 3312 spent very little time considering re-INVITEs,
which is probably why they didn't settle this issue -- with original
INVITEs, the failure response terminates the dialog usage, so the
"after" media state is moot.  That's why we need to make the
conceptual structure explicit, it makes these problems easier to see.)

Consider this ugly case:  UAC sends a re-INVITE with preconditions.
Several precondition UPDATEs follow, ending in success (all
preconditions are satisfied).  Then UAC and UAS send several UPDATEs
to modify the media streams.  Then UAS gives a failure response to the
re-INVITE.  Do we do the natural thing for ordinary UPDATEs and retain
media changes from all completed offer/answer cycles, or do we do the
natural thing for precondition INVITEs and roll back to before the
re-INVITE?

Edit the above principles to get the best results...

Dale

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 21 Jul 2006 17:22:37 +0900

Hi,

Now I think that the re-INVITE failure case is the issue
to be addressed in SIP offer/answer draft.
The rule is not clear yet and it is not just an academic problem;
we can imagine the media update failure case with precondition.
If we all can agree, we will add this topic in the next revision.

<Possible Solution>
Then, can we agree that the session state rolls back to the state
before re-INVITE transaction, when re-INVITE fails?
Because:
1) RFC 3261 says that and nothing seems to overwrite it.
2) It can apply to the media failure case with precondition

We should examine if it can also apply to the other cases.
But, for the meantime, this seems to be right behaiviour.

<New Problem>
If roll-back, or delayed commitment, is right thing to do,
then we seem to have another problem; roll-back and new 
offer/answer "glare" case.
Assume that roll-back is excuted when the final failure 
response is recieved (UAC side) or is sent (UAS side, it may
be when ACK is recieved) and almost at the same time new
offer/answer exchange with UPDATE transaction is executed.
There is no guarantee that both ends share the same view
about the order of roll-back and new offer/answer.
That is, it is possible that UA A thinks roll-back happens
first and new offer/answer is valid but UA B thinks new
offer/answer happens first and it is canceled with roll-back.
Is this problem? If yes, what is the solution?

Regards,
Takuya

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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 21 Jul 2006 11:13:34 +0200

Hi,

I have nothing against adding text about the issue into the draft. BUT, I don't think we shall make any decissions about the rollback issue at this point. We need to study it more.

Because, while performing the precondition offer/answer transactions, you may also have include non-precondition procedures for some m= lines (e.g. changing some parameter for media you have already done preconditions for, and which does not require a new precondition procedure). You may even have added new media, without preconditions, and started to send/receive media on it. 

Regards,

Christer

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: 21. heinäkuuta 2006 11:23
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01

Hi,

Now I think that the re-INVITE failure case is the issue to be addressed in SIP offer/answer draft.
The rule is not clear yet and it is not just an academic problem; we can imagine the media update failure case with precondition.
If we all can agree, we will add this topic in the next revision.

<Possible Solution>
Then, can we agree that the session state rolls back to the state before re-INVITE transaction, when re-INVITE fails?
Because:
1) RFC 3261 says that and nothing seems to overwrite it.
2) It can apply to the media failure case with precondition

<New Problem>
If roll-back, or delayed commitment, is right thing to do, then we seem to have another problem; roll-back and new offer/answer "glare" case.
Assume that roll-back is excuted when the final failure response is recieved (UAC side) or is sent (UAS side, it may be when ACK is recieved) and almost at the same time new offer/answer exchange with UPDATE transaction is executed.
There is no guarantee that both ends share the same view about the order of roll-back and new offer/answer.
That is, it is possible that UA A thinks roll-back happens first and new offer/answer is valid but UA B thinks new offer/answer happens first and it is canceled with roll-back.
Is this problem? If yes, what is the solution?

Regards,
Takuya

> >>> Well, I would phrase it thusly:  Previously, any situation in 
> >>> which one offer/answer negotiation was initated before a previous 
> >>> one had completed was considered "glare" and was to be considered erroneous.
> >>
> >>
> >> I'm not following you. Look at the basic mechanisms in 3312. That 
> >> RFC introduces all this usage. The only part it doesn't address is 
> >> if it is used in a reINVITE.
> >>
> >>> But we currently have use-cases which need to do this.  So we now 
> >>> have to extend the offer/answer model to usefully handle 
> >>> situations in which there are multiple negotiations at the same time.
> >>
> >>
> >> I'm not suggesting multiple negotiations concurrently - all the 
> >> offers and answers occur serially. The question is are: when a 
> >> reINVITE fails, what is the state of the session?
> > 
> > Note that the issue is larger than just offer/answer. In general, 
> > when multiple requests are allowed to be processed in parallel, 
> > there can be various values that have been updated between the 
> > reINVITE (or other
> I believe the offer/answer question is different than some of the 
> others (specifically target refresh) for a couple of reasons:
> text in a different place. Nevertheless, a consistent answer for the 
> two would probably be a good thing.
> 
> > For example, we may have received information about supported 
> > extensions, identity, or even a SUBSCRIBE within that dialog (not 
> > recommended, but certainly still possible), etc.
> 
> I think we will have to start out by considering these on a case by 
> case basis. But we may want to sort them into one of a few buckets and 
> then treat the buckets in a consistent way.
> 
> In general I think I agree. And in general there is no language 
> anywhere that says they should be, so its probably not an issue.
> 
> > What seems
> > more reasonable (for offer/answer as well as any other value that 
> > may have been updated by other transactions in between) is for a 
> > rule like the following: If transaction T modifies a particular 
> > parameter P from value N to M, and T fails, then parameter P must 
> > have its value rolled back to N, if, and only if, the value of P is 
> > still M (i.e. no subsequent transactions modified it).
> 
> value is still M, so by your rule it should be rolled back even though 
> a subsequent transaction "modified" it.
> 
> > deal with multiple overlapping transactions (whether issued by one 
> > or both sides in parallel), but going back to your original example 
> > (repeated below), I would say that that offer3/answer3 ought to be 
> > the what is in effect at the end:
> 
> preconditions have been resolved (but Bob's remain unresolved). Then 
> Bob discovers he cannot get the resources and will not be able to 
> resolve the preconditions, so fails the reinvite.
> 
> Is it reasonable to leave the session status with a media stream 
> having unresolved preconditions?
> 
> 2xx response with the video stream being refused by Bob. (But I think 
> I can probably find another case where that won't work so well.)
> 
> So I think it comes down to whether we do "delayed commit" or 
> "immediate commit" at some well defined points.
> 
> 	Paul
> 
> > -- Flemming
> > 
> > 
> > 
> >>
> >>     Paul
> >>
> >>> negotiations, the standard defining the use of preconditions 
> >>> should have defined how to handle overlapping negotiations.
> >>>
> >>> Dale
> >>>
> >>> Sipping mailing list  
> >>> https://www1.ietf.org/mailman/listinfo/sipping
> >> Sipping mailing list  
> >> https://www1.ietf.org/mailman/listinfo/sipping

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

---

From: "Nataraju A B" <[email-masked]>
Date: Fri, 21 Jul 2006 16:28:25 +0530

Comments inline...

Thanks & Regards,
Nataraju A.B.
> Sent: Friday, July 21, 2006 1:53 PM
> To: [email-masked]
> Cc: [email-masked]
[ABN] I feel, once any offer/answer negotiation completes according to
this draft (intern inline with all the other related drafts on this
topic), the latest committed one should be considered... otherwise we
need to think over sequencing (or versioning) the offer/answer
negotiations. 

> Is this problem? If yes, what is the solution?
[ABN] rolling back to state before reINVITE needs sequencing/versioning
of offer/answer negotiation. None of the existing RFCs addresses the
versioning/sequencing offer/answer negotiation. 

> > >>>    IMO this case is not adequately addressed by any existing RFC
or
> > >>> Well, I would phrase it thusly:  Previously, any situation in
which
> > >> I'm not following you. Look at the basic mechanisms in 3312. That
RFC
> > >> I'm not suggesting multiple negotiations concurrently - all the
offers
> > > Note that the issue is larger than just offer/answer. In general,
when
> > I believe the offer/answer question is different than some of the
others
> > text in a different place. Nevertheless, a consistent answer for the
two
> > I think we will have to start out by considering these on a case by
case
> > In general I think I agree. And in general there is no language
anywhere
> > > more reasonable (for offer/answer as well as any other value that
may
> > > deal with multiple overlapping transactions (whether issued by one
or
the
> > preconditions have been resolved (but Bob's remain unresolved). Then
Bob
> > Is it reasonable to leave the session status with a media stream
having
> > So I think it comes down to whether we do "delayed commit" or
"immediate
> > >>> negotiations, the standard defining the use of preconditions
should

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jul 2006 10:03:16 -0400

> I have nothing against adding text about the issue into the draft. BUT, I don't think we shall make any decissions about the rollback issue at this point. We need to study it more.

We haven't made any *final* "decisions" until and unless this draft 
becomes an RFC. At the moment it is still an individual draft, so the 
author can include anything he wants.

I agree we are not yet to "rough concensus", but I think it is valuable 
to write *something* down in the draft about it. That can serve to focus 
the email discussions on proposing changes to that text.

There is the question of how to add this to the draft:

- One way is to say that while this is obscure there is one valid 
interpretation of the existing specs, and write that down. Then note 
that there are issues about whether this interpretation is the way it 
*should* work, and that a change may be needed.

- Another way is to say that the specs are ambiguous about how this 
should be interpretted, and that the issue is to resolve the ambiguity.

I am on the fence about this, but I am inclined to take the position 
that the specs are not ambiguous on this point, and so the current 
interpretation should be that all changes made in the negotiated SDP 
beginning with the reinvite should be rolled back if the reinvite fails. 
(And, during this entire time, the SDP in effect before the reinvite 
shall remain operational. The new SDP may also be operational in some 
cases.)

> Because, while performing the precondition offer/answer transactions, you may also have include non-precondition procedures for some m= lines (e.g. changing some parameter for media you have alread…

I think the same rules apply to that.

Take a simple case: assume we have a session with a single m-line for 
audio, and audio is flowing. Then a reinvite changes the port number for 
the audio, using a single offer/answer, with the answer in a reliable 
1xx. At that point audio can start flowing using the new port. Then the 
reinvite fails. The specs are very clear that status should revert to 
the original session with the original ports.

AFAIK the case you cite above doesn't present any new issues over what 
is in the simple case.

	Paul

>>>>> or draft.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jul 2006 10:39:49 -0400

Dale,

good analysis. But I don't quite agree with the conclusion.

Dale,

I think there may be some value in looking at preconditions as 
introducing a special kind of special multi- offer/answer "transaction". 
But I think that can be left to another day.

IMO, even without considering preconditions, the interactions among 
3261, 3262 (PRACK), 3264 (offer/answer), and 3311 (UPDATE) requires the 
notion of a sort of multi- offer/answer "super-transaction" that can be 
rolled back, whether there are precondition negotiations in it or not.

There may be some value in looking at preconditions as introducing some 
added requirements. But I think that can be left to another day. (An 
example of when this might come into play is when using UPDATE (without 
reinvite) to add a stream using preconditions, which will require 
multiple UPDATES.)

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 21 Jul 2006 22:11:42 -0400

Paul Kyzivat wrote:
>> then we seem to have another problem; roll-back and new offer/answer 
>> "glare" case.
>> Assume that roll-back is excuted when the final failure response is 
>> recieved (UAC side) or is sent (UAS side, it may
> I guess it depends on who sent the update, and whether it was actually 
> sent before or after the failure of the reinvite:
> 
> - suppose Alice sends the UPDATE before receiving the failure response 
> from Bob for the reinvite. But it is received by Bob after having sent 
> the failure response. In that case, I think Bob needs to treat this as a 
> glare condition since the failure response in effect changes the session 
> and hasn't been ACKed yet. (491 response to update.)

But this is a non-2xx final response so Bob will get the ACK from the 
last-but-one proxy. Without an explicit indication in the UPDATE 
regarding whether it's scoped to the INVITE or not it's going to be 
difficult for Bob's UA to know whether to honor the UPDATE or not...

Anders

> 
> - Alice sends the UPDATE after receiving the failure response but before 
> sending the ACK. THis is just broken. It will look the same to Bob as 
> the above, and should be treated the same.
> 
> - Alice sends the UPDATE after sending the ACK to the reinvite failure. 
> Perhaps the ACK was lost. Bob will see it the same as above and treat 
> same way. The backoff from the 491 will give time for Bob to retransmit 
> the reinvite failure and then Alice to send another ACK. Eventually this 
> will work out.
> 
> - Bob sends the update after sending the failure response and receiving 
> the ACK. There is no problem here.
> 
> - Bob sends the UPDATE after sending the failure response but before 
> receiving the ACK, and it arrives after the failure response is 
> received. There is no problem here.
> 
> - Bob sends the UPDATE after sending the failure response but it arrives 
> before the failure response. This could be a really ugly case. The 
> simple answer is that Bob should not send a new offer until receiving an 
> ACK for the reinvite. If he does it anyway, then the condition you 
> mention does arise, and it is a mess.
> 
>     Paul
> 
> 
> 
> 
>> Regards,
>> Takuya
>>
>>>
>>>>>>    The above is exactly what would be required if offer2 
>>>>>> contained    unresolved preconditions. In that case, the reinvite 
>>>>>> will never complete    until the preconditions are resolved. So 
>>>>>> you can't ban this usage unless    you ban preconditions in 
>>>>>> reinvites.
>>>>>>
>>>>>> have
>>>> reINVITE (or other request) and its failure.
>>>
>>> case basis. But we may want to sort them into one of a few buckets 
>>> and then treat the buckets in a consistent way.
>>>
>>> "invite dialog usage state" bucket, others the "subscribe dialog 
>>> usage state" bucket, etc. For some it is clear which bucket applies. 
>>> For others it is far from clear.
>>>
>>> All the ones that declare support for one thing or another are an 
>>> open question. There is no clarity on what the scope of such a 
>>> declaration is. If it was clear that the scope was a dialog then I 
>>> would put them into the "dialog state" bucket. But I don't think that 
>>> is the case.
>>>
>>>> I suspect few people will argue that all those changes would have to 
>>>> be rolled back to the state before the reINVITE if that reINVITE fails.
>>>
>>>> What seems more reasonable (for offer/answer as well as any other 
>>>> value that may have been updated by other transactions in between) 
>>>> is for a rule like the following: If transaction T modifies a 
>>>> particular parameter P from value N to M, and T fails, then 
>>>> parameter P must have its value rolled back to N, if, and only if, 
>>>> the value of P is still M (i.e. no subsequent transactions modified 
>>>> it).
>>>
>>> value is still M, so by your rule it should be rolled back even 
>>> though a subsequent transaction "modified" it.
>>>
>>>> This needs further refinement to deal with multiple overlapping 
>>>> transactions (whether issued by one or both sides in parallel), but 
>>>> going back to your original example (repeated below), I would say 
>>>> that that offer3/answer3 ought to be the what is in effect at the end:
>>>
>>> In any case, I think it is probably wrong to even talk about 
>>> "rollback". I think it will work much better to replace "rollback" 
>>> with "delayed commit" - where changes made before the completion of 
>>> the reINVITE transaction are not committed until the reinvite 
>>> successfully completes. Meanwhile, for all other uses the original 
>>> values remain operative.
>>>
>> 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]
>>
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 22 Jul 2006 20:10:08 +0200

Hi,
 
First, one of the reasons for all this is the fact that all media control is "bundled" in SIP, i.e. you always have to include information for ALL streams in your SDP offer, eventhough you're only modifying one stream, and if the offer is rejected due to one stream, any simultanous offer to other streams are also automatically rejected. The reason for that is of course:
 
1. We have all media information collected in a single SDP (single sequence- and version numbers etc)
2. Since the m= lines aren't "numbered", they all have to be included in each SDP so that the receiver knows which m= line is associated with each stream.
 
You can call all this a "feature" if you want, but it's something we have to keep in mind when we try to come up with a solution.
 
Second, instead of using re-INVITE and reliable 18x responses, e.g. for pre-conditions (or any other mid-call procedure where multiple offer/answer transactions are required), we could use multiple UPDATEs. We would still have the question how many SDPs to roll-back if a pre-condition related offer fails, but at least we would not have a pending re-INVITE transaction while possible performing other offer/answer transactions. OR, we can choose not to do any roll-back in that situation. If one UPDATE fails, the UAC can e.g. choose to send a new UPDATE where it "removes" whatever it has done until the UPDATE failed. That way SDP modifications that DID succeed can still be used.
 
Regards,
 
Christer

Lähettäjä: Paul Kyzivat [mailto:[email-masked]]
Lähetetty: pe 21.7.2006 16:27
Vastaanottaja: Takuya Sawada
Kopio: [email-masked]
Aihe: Re: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01

        Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 23 Jul 2006 09:25:02 +0200

Hi,

>reinvite) to add a stream using preconditions, which will require

As I wrote in another mail, an alternative to allowing 18x responses for a re-INVITE would be to use multiple UPDATEs instead. Then it would be much easier to "keep control", because if an  UPDATE fails there is no possibility that there may have been other offer/answer transactions between the UPDATE request and failure response.
 
Regards,
 
Christer

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 24 Jul 2006 23:53:28 +0900

Hi,

Comments inline.
> 
> Hi, 
> 
> >>I have nothing against adding text about the issue into the draft. BUT, I don't 
think we shall make any decissions about 
> >>the rollback issue at this point. We need to study it more.
> >
> >We haven't made any *final* "decisions" until and unless this draft becomes an 
RFC. At the moment it is still an 
> >individual draft, so the author can include anything he wants.
> >
> >I agree we are not yet to "rough concensus", but I think it is valuable to write 
*something* down in the draft about it. 
> >That can serve to focus the email discussions on proposing changes to that text.
> 
> I agree. But, I think the draft should list all the different options, and issues 
related to those options. Then we'll go from there.
I think whether the UA rolls back the session status to the state before 
the re-INVITE or keeps the completed offer/answer state is not an option.
Because it will cause serious problem if both ends behave different ways
with each other.

Can we agree that we must have consensus on this issue?

And if we must choose one, it seems to me that the rollback is the one 
for us to take.

The main reason is that RFC 3261 says that and no RFC overrides explicitly.

Can we reach "rough consensus"?
Anyway, I need to add one subsection on this issue...

> >- One way is to say that while this is obscure there is one valid interpretation 
of the existing specs, and write that 
> >down. Then note that there are issues about whether this interpretation is the 
way it
> >- Another way is to say that the specs are ambiguous about how this should be 
interpretted, and that the issue is to 
> >resolve the ambiguity.
> 
> I think we can say what the spec(s) currently say, but mention that there are 
issues with those solutions, and then list alternative solutions. I am not 
sure I 
would say the current text is ambiuous - there are just lots of things that 
most 
likely weren't taken into consideration when the text was written.
> 
> >I am on the fence about this, but I am inclined to take the position that the 
specs are not ambiguous on this point, and 
> >so the current interpretation should be that all changes made in the negotiated 
SDP beginning with the reinvite should be 
> >rolled back if the reinvite fails. 
> >(And, during this entire time, the SDP in effect before the reinvite shall remain
 operational. The new SDP may also be 
> >operational in some cases.)
> 
> We can say that is the current interpretation, yes. But, again, we should then 
list the issues with that interpretation, and list other possible solutions 
(and the
 issues with those).

I can describe the non-rollback possibility and what is the current
interpretation (why we do not take it, if we reach "consensus" on it). 
I will also list the issues with rollback behaviour, such as new 
"glare" considerations.
> 
> >>Because, while performing the precondition offer/answer transactions, you may 
also have include non-precondition 
> >>procedures for some m= lines (e.g. changing some parameter for media you have 
already done preconditions for, and which 
> >>does not require a new precondition procedure). You may even have added new 
media, without preconditions, and started to 
> >>send/receive media on it. 
> >>
> Yes, but the question is whether the current interpretation really gives the 
desired behavior.

I will describe incompleteness on rollback and offer the other option to use
multiple UPDATEs, which may unfortunately be incomplete as well.
> 
> >Take a simple case: assume we have a session with a single m-line for audio, and 
audio is flowing. Then a reinvite 
> >changes the port number for the audio, using a single offer/answer, with the 
answer in a reliable 1xx. At that point 
> >audio can start flowing using the new port. Then the reinvite fails. The specs 
are very clear that status should revert 
> >to the original session with the original ports.
> >
> >AFAIK the case you cite above doesn't present any new issues over what is in the 
simple case.
> 
> There may be MULTIPLE offer/answer transactions before the re-INVITE fails. Yes, 
when a new offer is sent it should be possible to use the "previous" SDP, in 
case 
the offer is rejected. 
> 
> BUT, if there are multiple offer/answer transactions the SDP you had before you 
sent the re-INVITE will not be the "previous" anymore - because everytime you 
send a
 new offer (or answer, if the offer is initiated by the remote side) the 
previous 
will be the one you're using before sending the offer. And, it may be 
difficult to 
store BOTH the previous SDP, and the SDP which was valid before the re-INVITE 
you 
sent.
> 
> Your port example may not be a big problem, but during the offer/answer 
transactions (between the re-INVITE request and error response) streams may 
have 
been added, removed, etc - things which really affect the resources of the 
clients 
may have taken place.
> 
> Of course, if the rollback isn't technically possible the entities can release the
 call.
> 
> I am not saying that the rollback isn't the right solution - I am saying that we 
need to study it :)
I agree. It is ugly and probably not considered so musch so far.

> Also, as we know, this does not only affect the SDP, but also other information (e.
g. the Contact header). So, should we look at the whole picture, or each issue
 
separate? Do we accept a situation where some information may be rolled back, 
while 
other information may not?
OK. I want to keep the scope of offer/answer draft as it is, that is I want
keep it as a separate issue.
But how do you think other information than session state?

Regards,
Takuya

> > Sent: 21. hein臾uuta 2006 11:23
> > To: [email-masked]
> > Cc: [email-masked]
> > The rule is not clear yet and it is not just an academic problem; we can imagine
 the media update failure case with precondition.
> > Then, can we agree that the session state rolls back to the state before re-
INVITE transaction, when re-INVITE fails?
> > If roll-back, or delayed commitment, is right thing to do, then we seem to have 
another problem; roll-back and new offer/answer "glare" case.
> > Assume that roll-back is excuted when the final failure response is recieved 
(UAC side) or is sent (UAS side, it may be when ACK is recieved) and almost at
 the 
same time new offer/answer exchange with UPDATE transaction is executed.
> > That is, it is possible that UA A thinks roll-back happens first and new offer/
answer is valid but UA B thinks new offer/answer happens first and it is 
canceled 
with roll-back.
> >> would put them into the "dialog state" bucket. But I don't think that is the 
case.

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

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 24 Jul 2006 23:57:42 +0900

Hi,

> mention does arise, and it is a mess.
Yes, that is one of the cases of which I think we need to take some care.
Also, as it is already pointed out, the first case needs some consideration
on hop-by-hop ACK request.

Regards,
Takuya

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2006 09:51:53 -0400

Its getting hard to follow, but I think I am in agreement with Takuya.

Regarding rollback (or not) of state other than SDP:

I think this needs to be considered separately, but should take into
account what is being discussed here.

The main reason these need to be considered separately is that they are
addressed separately in the existing specs, so there are special
considerations for each.

The two main pieces of state that have come up are: SDP, remote target.
These are quite different because SDP is *session* (invite dialog usage)
state, while the remote target is *dialog* state. So I can imagine
getting different answers for the two.

I don't believe there is any other dialog state that is permitted to
change. There is other session state that can change - at least the
session timer. Offhand I think it probably should be treated the same
way as SDP, but I want to think about it and discuss it (later) before
committing to that.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jul 2006 19:16:50 -0400

Anders Kristensen wrote:
>> the failure response. In that case, I think Bob needs to treat this as 
>> a glare condition since the failure response in effect changes the 
>> session and hasn't been ACKed yet. (491 response to update.)
> 

I've been putting this off until I had time to think about it.

This is a nasty issue! If a proxy is record-routed there is no good way 
for Bob to tell if Alice sent the UPDATE before or after receiving the 
final response to the reINVITE. (Well, I guess it knows after enough 
time has passed for the reINVITE transaction to time out, but that isn't 
very helpful.)

It certainly is valid for Alice to send an UPDATE after the failed 
reINVITE, and it is also quite proper for Alice to have sent an UPDATE 
when the reINVITE seemed to be going well. But as you say, there is no 
way for Bob to know which is the case and hence whether to honor it.

Without changes, I think the best that can be done is to evaluate 
whether the offer in the UPDATE is consistent with the session state 
given the reINVITE failed, and to honor it iff it is consistent. That 
isn't ideal, because it could be consistent and yet not appropriate 
given the reINVITE failed.

I guess if every reliable answer was committed immediately then this 
would not be a problem. But then we have problems with half resolved 
preconditions being committed from reINVITEs that fail.

What a mess!

	Paul

> Anders
> 
>>
>> - Alice sends the UPDATE after receiving the failure response but 
>> before sending the ACK. THis is just broken. It will look the same to 
>> Bob as the above, and should be treated the same.
>>
>> - Alice sends the UPDATE after sending the ACK to the reinvite 
>> failure. Perhaps the ACK was lost. Bob will see it the same as above 
>> and treat same way. The backoff from the 491 will give time for Bob to 
>> retransmit the reinvite failure and then Alice to send another ACK. 
>> Eventually this will work out.
>>
>> - Bob sends the update after sending the failure response and 
>> receiving the ACK. There is no problem here.
>>
>> - Bob sends the UPDATE after sending the failure response but it 
>> arrives before the failure response. This could be a really ugly case. 
>> The simple answer is that Bob should not send a new offer until 
>> receiving an ACK for the reinvite. If he does it anyway, then the 
>> condition you mention does arise, and it is a mess.
>>
>>     Paul
>>
>>
>>
>>
>>> Regards,
>>> Takuya
>>>
>>>>
>>>> E.g. some things fall into the "dialog state" bucket, others into 
>>>> the "invite dialog usage state" bucket, others the "subscribe dialog 
>>>> would put them into the "dialog state" bucket. But I don't think 
>>>> that is the case.
>>>>
>>>>> I suspect few people will argue that all those changes would have 
>>>>> to be rolled back to the state before the reINVITE if that reINVITE 
>>>>> fails.
>>>>
>>>> I think the rollback is the better outcome. An alternative would be 
>>>> a 2xx response with the video stream being refused by Bob. (But I 
>>>> think I can probably find another case where that won't work so well.)
>>>>