Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 01 Jul 2010 10:09:01 +0300

Hi Brett,

> If adjustments are added to the other sections to clearly discuss non
> reliable provisional responses, the proposal appears to adequately
> clarify RFC 3261.

sure, I am going to work on that.

> My understanding of the new section is that an INVITE 2xx response's
> updated Contact can trigger the UAC to update the remote-target.  The
> clarification is not because of the last sentence, it is because of
> the first sentence.  If this is not true, please explain.

Yes, your understanding is correct.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 01 Jul 2010 10:38:12 +0300

Hi Paul,

what I had in mind is exactly what you proposed below. It's good to see
we are on the same page!

I have added a second paragraph to Section 4.6 to address this issue.
The whole section looks as follows now:

4.6.  Early Dialogs

   The rules given in this section about which messages can refresh the
   target of a dialog also apply to early dialogs created by an initial
   INVITE transaction.  Additionally, as specified in Section 13.2.2.4
   of RFC 3261 [RFC3261], on receiving a 2xx response to the initial
   INVITE, the UAC recomputes the whole route set of the dialog, which
   transitions from the "early" state to the "confirmed" state.

   Section 12.1 of RFC 3261 allows unreliable provisional responses to
   create early dialogs.  However, per the rules given in this section,
   unreliable provisional responses cannot refresh the target of a
   dialog.  Therefore, the UAC of an initial INVITE transaction will not
   perform any target refresh as a result of the reception of an
   unreliable provisional response with an updated Contact value on an
   (already-established) early dialog.  Note also that a given UAS can
   establish additional early dialogs, which can have different targets,
   by returning additional unreliable provisional responses with
   different To tags.

Cheers,

Gonzalo

On 30/06/2010 5:07 PM, Paul Kyzivat wrote:
> Replying to myself,
> 
> Perhaps the answer here is that a non-reliable response to an initial 
> INVITE can indeed establish an early dialog. But then the contact 
> address in all subsequent non-reliable responses must remain identical 
> to that in the first non-reliable response. And Contacts received in 
> non-reliable responses, except the first one received, must be ignored.
> 
> That would allow use of INFO and UPDATE in an early dialog without 
> 100rel, and even a remote target change via the UPDATE in that case.
> 
> 	Thanks,
> 	Paul
> 
> Paul Kyzivat wrote:
>>
>>
>> Gonzalo Camarillo wrote:
>>
>>>> The following rule only discusses reliable provisional responses.
>>>> What are rules for non reliable provisional responses?
>>>
>>> non-reliable responses do not refresh the target because SIP does not
>>> provide any type of ordering for them. I can clarify that if you think
>>> it is unclear.
>>
>> Hmm. I think that is debatable.
>>
>> That logic would suggest that non-reliable provisionals also could not 
>> establish an early dialog in the first place, since there might have 
>> been more than one with different targets that got reordered.
>>
>> My reading of 3261 and 3311 leaves me with the conclusion that I could 
>> receive a non-reliable provisional, consider that to establish an early 
>> dialog, and then send an UPDATE, without ever using 100rel.
>>
>> OTOH, there is logic to your argument. So maybe what you propose is the 
>> "right" solution even if it is to some extent incompatible with things 
>> as they stand. If so, then there should be an additional explicit 
>> statement that non-reliable provisionals never establish an early dialog.
>>
>> That would also mean that INFO could not be used before 2xx unless 
>> 100rel was used to establish the early dialog.
>>
>>     Thanks,
>>     Paul
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Jul 2010 11:49:32 -0400

Gonzalo,

I like the new paragraph.

But I think the procedures in the rest of the section are still incomplete.

Section 4.3 is limited to cases when the UAC is attempting to change 
*its* address and 4.4 is limited to cases when the UAS as received a 
request from a UAC that is attempting to change its address.

The case where the UAS wants (needs) to change its address is largely 
unmentioned. This is of course a strange situation, which would require 
some freak timing, but it is possible. (To be fair, 4.3 does touch on 
the case where the UAS receives a response with a changed address. But 
since the whole section is restricted to a UAC changing its own address, 
it doesn't cover the case where only the UAS is changing its address.)

If the UAS just *wants* to make the change, then it would be best for it 
to wait until it can send a request of its own. If it *needs* to make a 
change, then it must do what it must do. But then there are limits such 
as you have already identified.

Specifically, if the UAS received an initial or re-INVITE, and send a 
reliable provisional response with one address, then it would be 
permitted to send another reliable response with a different address. 
But if it send an unreliable provisional with one address, then there 
are problems with sending another unreliable provisional with a 
different address. Specifically the problems are with which one the UAC 
believes when some may be lost or reordered.

For an initial invite you already point out one solution in 4.6: change 
the to-tag and thus establish a new early dialog. That is a great 
solution for the UAS in this case.

There is another solution for the UAS in a reINVITE: send an out of 
dialog INVITE/Replaces, transferring the call to the new address.

Perhaps it is sufficient to offer those solutions to the UAS while 
keeping the rules you have spelled out for the UAC to ignore changes to 
the remote address in unreliable responses.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 02 Jul 2010 15:12:23 +0900

Hi Gonzalo,

I'm studying the UAC behavior when it receives a reliable
response to the re-INVITE.

Gonzalo Camarillo <[email-masked]>
Tue, 29 Jun 2010 15:21:20 +0300
(snip)
>>>   If
>>>   the UAC of a re-INVITE transaction sends an UPDATE request, receives
>>>   a reliable response to the re-INVITE, and then a 2xx response to the
>>>   UPDATE request, the UA SHOULD generate a new re-INVITE or UPDATE
>>>   request in order to make sure that both UAs have a common view of the
>>>   state of the session, as described in Section 3.4.
>> 
>> In case that the reliable response is 4xx, this rule is necessary
>> from an offer-answer perspective.
>
>Exactly.
>
>> In case that the reliable response is 2xx or 18x, this rule seems
>> to be also necessary from a remote-target perspective.
>
>Exactly.
>
>> But I'm not sure at present.
>
>Your understanding is correct.

If the reliable response is 18x-rel, IMO signaling sequences
are shown as below.

       A                               B
       |                               |
     s0|re-INVITE (offer1)             |s0
       |------------------------------>|
       |               18x-rel(answer1)|
       |<------------------------------|
     s1|PRACK                          |s1
	   |------------------------------>|
	   |                        2xx-PRA|
	   |<------------------------------|<-+
       |UPDATE                         |  |
       |==============================>|  |
       |                  2xx-UPD(m:c1)|  |
       |              /================|  |
       |             /    18x-rel(m:c2)|  |
       |<-----------/------------------|  |
       |           /                   |  |
       |<=========/                    |  |
       |PRACK                          |  |
       |------------------------------>|  | accept UPDATE
	   |                        2xx-PRA|  |
	   |<------------------------------|  |
       |UPDATE                         |  |
       |==============================>|  |
       |                  2xx-UPD(m:c2)|  |
       |<==============================|  |
       |                               |  |
       |                               |  v

There is no problem for an offer-answer interworking of an
UPDATE and a 18x to a re-INVITE.
Because the 2nd and subsequent 18x doesn't contain an offer.
According to current text, the 18x-rel doesn't refresh a
remote-target. But this draft changes the rules.
That is, new definitions for a target-refresh cause this issue.

And in another cases,

       A                               B
       |                               |
     s0|re-INVITE (offer1)             |s0
       |------------------------------>|
       |               18x-rel(answer1)|
       |<------------------------------|
     s1|PRACK                          |s1
	   |------------------------------>|
	   |                        2xx-PRA|
	   |<------------------------------|<-+
       |                               |  |
       |                   UPDATE(m:c1)|  |
       |<-------------\  /=============|  |
       |               \/              |  |
       |               /\ 18x-rel(m:c2)|  |
       |<=============/  \-------------|  |
       |                               |  | accept UPDATE
       |                               |  |
       |                               |  v

       A                               B
       |                               |
     s0|re-INVITE (offer1)             |s0
       |------------------------------>|
       |               18x-rel(answer1)|
       |<------------------------------|
     s1|PRACK                          |s1
	   |------------------------------>|
	   |                        2xx-PRA|
	   |<------------------------------|<-+
       |                               |  |
       |                  18x-rel(m:c1)|  |
       |<-------------\  /=============|  |
       |               \/              |  |
       |               /\  UPDATE(m:c2)|  |
       |<=============/  \-------------|  |
       |                               |  | accept UPDATE
       |                               |  |
       |                               |  v

After all, I think UAC should send an UPDATE every time it
receives a 18x-rel with a different Contact.

Regards,
Shinji

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Jul 2010 16:01:09 +0300

Hi Paul,

good point. I have re-structured the text so that the four different
scenarios are covered and, additionally, are more clearly described.
Please, review Sections 4.1 through 4.7:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-00.txt

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 02 Jul 2010 16:05:55 +0300

Hi Shinji,

> receives a 18x-rel with a different Contact.

In SIP, a UA can reject a request, but not a response. That is why the
UAS does not need a confirmation from the UAC (e.g., the UPDATE request
you propose) of the fact that the UAC accepted the response. The UAC did
not have a choice; it had to accept the response.

Thanks,

Gonzalo

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 03 Jul 2010 00:42:27 +0900

Hi Gonzalo,

>not have a choice; it had to accept the response.

I don't understand what point you are making.

The UPDATE request I propose make sure which is a current
remort target, c1 or c2. And a UAC needs the confirmation.

You seem to misunderstand my figures.

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jul 2010 12:17:10 -0400

Gonzalo,

> http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-00.txt

Those changes do help. The introduction of "local target" makes things 
clearer to talk about.

A couple more things:

4.6: "... the UA SHOULD send a request to the remote UA ..."

I presume this should say "... the UA SHOULD send an in-dialog request 
to the remote UA ...". If you didn't mean that, then we need to talk 
further.

4.7: I think this should also say: "If a UA receives an unreliable 
provisional response to a target-refresh request, the UA MUST NOT 
replace the dialog's remote target URI." You alude to this in 4.9, but I 
don't find it stated anywhere.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 05 Jul 2010 09:20:17 +0300

Hi Paul,

> to the remote UA ...". If you didn't mean that, then we need to talk 

Fixed.

> don't find it stated anywhere.

I did not originally added such a sentence because the draft already
says that only reliable responses can do that. However, I agree with you
that adding the sentence you propose here make things more explicit and
clearer. So, I have added the sentence per your suggestion.

Thanks,

Gonzalo