Subject: [sipcore] Fwd: Clarifications on draft-ietf-sipcore-reinvite-04.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 06 Jun 2010 17:53:12 +0300

Resending, since the mailing list seemed to be down yesterday.

-------- Original Message --------
Subject: Clarifications on draft-ietf-sipcore-reinvite-04.txt
Date: Sat, 05 Jun 2010 11:57:46 +0300
From: Gonzalo Camarillo <[email-masked]>
To: SIPCORE <[email-masked]>

Hi,

there have been many emails on the glare situations described in:

https://datatracker.ietf.org/doc/draft-ietf-sipcore-reinvite/

I have been asked to clarify the meaning of Sections 3.5 and 4.5 of the
draft.

As the draft indicates, there are glare situations that were not covered
by earlier RFCs such as RFC 3261 and RFC 3311. This draft covers those
situations. In the beginning, we started working on glare detection and
avoidance rules that were as little restrictive as possible. That is, we
tried to minimize false positives (i.e., the rules tell you there is a
glare when there really is no glare). Such rules would need to analyze
the messages involved in a given race condition and decide if the
endpoints could end up with different views on the value of any of all
the parameters involved in the SIP dialog and its related session.

The problem with this approach was that rules were getting too complex.
So, we decided to follow the KISS principle and provide simpler rules.
The idea was to come up with a relatively simple rule that may cause
false positives but would be simple to implement (and understand).

SIP already had glare-related rules. When sending or receiving a message
with an offer or an answer, UAs use those rules to decide whether or not
the outgoing message can be sent at that point and how to respond to the
incoming message. So, we decided to use the already existing rules,
which deal with glares related to offer/answer exchanges and modify them
so that, when using them, UPDATEs were always treated as if they
contained an offer.

For example, RFC 3311 says:

 "If an UPDATE is received that contains an offer, and the UAS has
 generated an offer (in an UPDATE, PRACK or INVITE) to which it has
 not yet received an answer, the UAS MUST reject the UPDATE with a 491
 response."

Before draft-ietf-sipcore-reinvite-04.txt, if a UA sent an UPDATE and
before receiving a 200 for it, the UA received an UPDATE from the remote
end, it would not have been considered a glare if either of the UPDATEs
did not contain an offer. However, those offerless UPDATEs could be
changing non-offer/answer parameters. Consequently, the UAs may end up
with different views on the values of those parameters.
Draft-ietf-sipcore-reinvite-04.txt treats this scenario as glare to keep
the UAs from getting out of synch.

The advantage of this approach is that it is relatively simple. The
disadvantage is that there are false positives (e.g., maybe the UPDATEs
in the example above were not negotiating parameters but simply
communicating the value of a non-negotiable parameter to the other end).

If people can think of situations were the new rules cause false
positives that are *really* problematic, we could look at them. However,
let's all keep in mind the KISS principle. It is way too easy to come up
with very complicated rules that only give us small gains when compared
with the simpler rules in this area.

In any case, I will probably clarify the text in the draft so that it is
clearer in which situations the glare rules are to be applied. Right
now, the draft references RFC 3261 and RFC 3311 but adding informative
descriptions to the draft would probably make it easier to understand.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jun 2010 12:48:06 -0400

Gonzalo,

Thank you for clarification. More inline.

> false positives but would be simple to implement (and understand).

This seems reasonable, especially since such glare situations are rare 
in the first place.

> communicating the value of a non-negotiable parameter to the other end).

I think the case is good wrt two *negotiable* pieces of state, such as 
sdp and session-timer. Not so good wrt non-negotiable state.

> with the simpler rules in this area.

ISTM that when non-negotiable info is concerned the situation is 
different. These don't conflict. There are a couple of those sorts of 
things (I don't know how many others there might be) that have come up 
for discussion:
- called party identity
- remote target

In the case of called party identity, it might be harmless to lump it in 
with the glare cases, even though it really isn't one.

But in the case of remote target, if the sender has lost its old address 
there is only one chance to fix it. Perhaps the probability losing an 
address and getting glare while trying to update it is so low that we 
don't care about it failing. I'm willing to entertain that, as long as 
we all recognize that is what we are doing.

> descriptions to the draft would probably make it easier to understand.

IMO that will go a long way to sorting this out. The "treat as if the 
update had an offer" has proven to leave many questions open to further 
interpretation.

Among other things, 3261 and 3311 address offer/answer glare, and only 
incidentally glare between messages. There is no real addressing of 
invite-update glare. Of course the o/a draft has worked to clarify that. 
We will have to now decide whether to put more specificity into the 
reinvite draft, or to just put some basics there and elaborate in the 
o/a draft.

	Thanks,
	Paul

---

From: [email-masked]
Date: Wed, 9 Jun 2010 14:16:49 +0800

Hi Paul,

> This seems reasonable, especially since such glare situations are rare 

Yes. And I have the same point here.

> sdp and session-timer. Not so good wrt non-negotiable state.

I guess we can do it as your suggestion. 

Or do it like this:
To use a separate text do the clarfication for session timer along the 
basic concept clarified in "Re-INVITE Handling" text.

I think any one of the two ways is OK, so I have no incline here:)

> reinvite draft, or to just put some basics there and elaborate in the 

Yes. I think to shift the glare discussion in one text is a nice 
suggestion. 

As glare cases are rare(as mentioned above) and "Glare Handling" is topic 
might need a relative long way to sorting it out, we can remove it from 
"Re-INVITE Handling"'s basic concept(the *in use* concept and which kind 
of final response should be returned by UAS) and make "Re-INVITE Handling" 
go on.

O/A draft is a choice as the container for the "Glare Handling" part. But 
there are two things need be evaluated:
1. "Glare Handling" has content beyond pure O/A handling. (Suggestion 
about this point: modify current O/A text's name as "O/A and Glare 
Handling").
2. "Glare Handling" is *once* aimed for normative text. (Suggestion about 
this point: we can do the "Glare Handling" as informational at first, then 
someday normative.)

Thanks,

Gao

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Brett Tate <[email-masked]>
Date: Thu, 10 Jun 2010 10:43:31 -0700

> If people can think of situations were the new rules 
> cause false positives that are *really* problematic, we 
> could look at them. However, let's all keep in mind the 
> KISS principle. It is way too easy to come up with very 
> complicated rules that only give us small gains when 
> compared with the simpler rules in this area.

It looks like (not sure) the clarification is the same as how I was interpreting the draft.  More specifically, an UPDATE without SDP sent over an early dialog which has not completed the INVITE's offer/answer exchange will result in a 491 or 500 instead of 200.  If this is true, it has the following problems.

1) Solution does not address INFO, REFER, NOTIFY, and etcetera.  Thus if the UPDATE fix is too restrictive, vendors will likely start using other methods (when valid) to update parameters or perform a ping on the early dialog.  This can be good or bad depending upon if you want vendors to start using INFO or define something like UPDATELITE as a workaround for those not willing or able to complete the offer/answer exchange on an early dialog so UPDATE can be used.

2) If caller's device is compliant and called party's device is not, rejecting called party's UPDATE (without SDP) with 491 can lead to numerous retries over the early dialog.  The 491 triggered retry interval would be 0-2 seconds.

3) The work-arounds mentioned within 1 are not possible for some headers (like Contact and Session-Expires).  Thus the work-arounds might be more drastic.  For instance, it might require using things like REFER.  I didn't notice if the draft actually clarifies rfc3261 concerning if an INVITE's 18x and 2xx response with different Contact can "update" a target during call setup.  The clarification was requested within
http://www.ietf.org/mail-archive/web/sipcore/current/msg01472.html 

> In any case, I will probably clarify the text in the 
> draft so that it is clearer in which situations the 
> glare rules are to be applied. Right now, the draft 
> references RFC 3261 and RFC 3311 but adding informative

Since I'm still not positive how to interpret the draft, I definitely would like to see the draft updated.  

Similarly if the draft updates RFC 3311, the draft should indicate that it is updating RFC 3311.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 11 Jun 2010 12:05:40 +0200

I tend to agree with Brett's argument below and would be concerned about the consequences for interoperability if UA's start rejecting UPDATE's without SDP due to this draft. This would probably cause problems for some existing deployments and workarounds would have to be found.

Regards
Andy

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: 10 June 2010 18:44
> To: Gonzalo Camarillo; SIPCORE
> Subject: Re: [sipcore] Fwd: Clarifications on 
> draft-ietf-sipcore-reinvite-04.txt
> 
> It looks like (not sure) the clarification is the same as how 
> I was interpreting the draft.  More specifically, an UPDATE 
> without SDP sent over an early dialog which has not completed 
> the INVITE's offer/answer exchange will result in a 491 or 
> 500 instead of 200.  If this is true, it has the following problems.
> 
> 1) Solution does not address INFO, REFER, NOTIFY, and 
> etcetera.  Thus if the UPDATE fix is too restrictive, vendors 
> will likely start using other methods (when valid) to update 
> parameters or perform a ping on the early dialog.  This can 
> be good or bad depending upon if you want vendors to start 
> using INFO or define something like UPDATELITE as a 
> workaround for those not willing or able to complete the 
> offer/answer exchange on an early dialog so UPDATE can be used.
> 
> 2) If caller's device is compliant and called party's device 
> is not, rejecting called party's UPDATE (without SDP) with 
> 491 can lead to numerous retries over the early dialog.  The 
> 491 triggered retry interval would be 0-2 seconds.
> 
> 3) The work-arounds mentioned within 1 are not possible for 
> some headers (like Contact and Session-Expires).  Thus the 
> work-arounds might be more drastic.  For instance, it might 
> require using things like REFER.  I didn't notice if the 
> draft actually clarifies rfc3261 concerning if an INVITE's 
> 18x and 2xx response with different Contact can "update" a 
> target during call setup.  The clarification was requested within
> Since I'm still not positive how to interpret the draft, I 
> definitely would like to see the draft updated.  
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 12 Jun 2010 00:09:02 +0900

Hi,

In any cases, IMO an interworking of an UPDATE and a 4xx to a
reINVITE should be described more concretely.

Here is the rules that I think.

UAC behavior for an error response to a reINVITE.
 1. In the following cases, a UA should generate a new offer
    request in order to synchronize a common view of both UAs.

    a. The UA receives an error response to a re-INVITE, and
       any offer-answer exchanges by using an UPDATE
       transaction have already completed.

    b. The UAC sends an UPDATE request with an offer, and
       receives an error response to the re-INVITE and a
       following 2xx response to the UPDATE request.

 2. If The UA receive another offer request before sending
    an own offer request, the UA may accept the UPDATE and
    then the UA may not send the own offer request.

UAS behavior for an error response to a reINVITE.
 1. It is recommended that a UAS return a 2xx response to a
    re-INVITE request.

 2. If the UAS return an error response to the re-INVITE,
    the UA may accept an new offer request before receiving
    an ACK.

 3. If the UAS sends an UPDATE with an offer and a following
    error response to the reINVITE, and receives a 2xx to the
    UPDATE, then the offer-answer state is not rolled back.
    To put it another way, it is assumed that the offer-answer
    state doesn't belong to the re-INVITE.

At present, I think that these rules are a minimum set.
And following figures are main puzzles and the answers.

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |               18x-rel(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |<------------------------------|<-+
  s0|ACK                ACK         |s0|
    |------------>      ----------->|  | accept UPDATE
    |                               |  v

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |               18x-rel(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |               /---------------|<-+
    |UPD(offer2)   /                |s0|
    |=============/================>|  | accept UPDATE
    |            /  2xx-UPD(answer2)|  |
    |<==========/===================|  |
  s2|          /                    |s2|
    |<--------/         ----------->|  |
  s0|ACK                            |  |
    |------------->                 |  |
    |UPD(offer0)                    |  |
    |==============================>|  |
    |               2xx-UPD(answer0)|  |
    |<==============================|  |
  s0|                               |s0|
    |                               |  v

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |               18x-rel(answer1)|
    |<------------------------------|
  s1|                    UPD(offer2)|s1
    |                  /============|
    |                 /      non-2xx|
    |<---------------/--------------|<-+
  s0|ACK            /   ACK         |s0|
    |------------> /    ----------->|  | accept UPDATE
    |             /                 |  |
    |<===========/                  |  |
    |2xx-UPD(answer2)               |  |
    |==============================>|  |
  s2|                               |s2|
    |                               |  v

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |               18x-rel(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |                  /------------|<-+
    |                 /  ACK        |s0|
    |                /   ---------->|  | accept UPDATE
    |               /    UPD(offer2)|  |
    |<=============/================|  |
    |2xx(answer2) /                 |  |
    |============/=================>|  |
  s2|           /                   |s2|
    |<---------/                    |  |
  s0|ACK                            |  |
    |----------->                   |  |
    |UPD(offer0)                    |  |
    |==============================>|  |
    |               2xx-UPD(answer0)|  |
    |<==============================|  |
  s0|                               |s0|
    |                               |  v

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |               18x-rel(answer1)|
    |<------------------------------|
  s1|UPD(offer2)                    |s1
    |==============================>|
    |                   2xx(answer2)|
    |                  /============|
    |                 /      non-2xx|s2
    |<---------------/--------------|<-+
  s0|ACK            /       ACK     |s0|
    |------->      /        ------->|  | accept UPDATE
    |             /                 |  |
    |<===========/                  |  |
  s2|UPD(offer0)                    |  |
    |==============================>|  |
    |               2xx-UPD(answer0)|  |
    |<==============================|  |
  s0|                               |s0|
    |                               |  v

>This seems reasonable, especially since such glare situations are rare 

I like KISS too. But unfortunately glare-related rules are not
simple.

Regards,
Shinji