Subject: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP]

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 May 2010 11:51:38 +0200

Below are some questions/ideas on how I think we could solve most issues. Some of the stuff shall be seen more as brain storming than actual proposal at this point.

I am fully aware that some of the ideas for sure may limit what is said in RFCs etc, so you don't need to tell me about that.

IDEA #1:  Offer/answer: Usage of SDP o= version parameter

I know this has been discussed at some point, but what is the reason we can't use the SDP o= version parameter to determine in which order the UAS has sent SDPs?

I believe it would solve offer/answer glare situations where the UAC does not known in which order the UAS has sent SDPs.

That should not be controversial, and does not break any RFC etc.

IDEA #2:   Target update: Only outside re-INVITEs

Let's forbid target updates "inside" re-INVITEs. I really doubt there is a need for those while the UAs are doing something else with the re-INVITE.

That at least solves the glare situation where the remote target may be updated in a re-INVITE response and an UPDATE response.

IDEA #3:    UPDATE: Always use re-INVITE glare rules

Let's not allow more than one outstanding UPDATE. Ie if a UA has sent an UPDATE (with or without SDP), and receives another UPDATE request before the answer, it rejects it (same rule as for re-INVITE).

That would at least solve the problem where a UA sends an UPDATE, receives a 200 OK and a UPDATE request, both with different target information.

Ok, let the tomatoes fly...

...and let me know if there are any issues which the ideas above do NOT solve. I have some more ideas, but I am not sure they are needed so I'll them to myself for now :)

Regards,

Christer

---

From: [email-masked]
Date: Thu, 27 May 2010 19:19:17 +0800

Christer,

As I think sections 3.5 and 4.5 of the draft can solve the problem and 
having no more effects on current RFCs, I'd like to focus on the current 
text. 

You can refer to the interpretation in:

http://www.ietf.org/mail-archive/web/sipcore/current/msg02788.html

This is just one referenced implementation to prove that sections 3.5 and 
4.5 is viable, and I think there might be other implementation ways for 
the two sections.

Regards,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Christer Holmberg <[email-masked]> 
发件人:  [email-masked]
2010-05-27 17:51

收件人
"[email-masked]" <[email-masked]>, Brett Tate 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
[sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE 
without SDP]

Below are some questions/ideas on how I think we could solve most issues. 
Some of the stuff shall be seen more as brain storming than actual 
proposal at this point.

I am fully aware that some of the ideas for sure may limit what is said in 
RFCs etc, so you don't need to tell me about that.

I know this has been discussed at some point, but what is the reason we 
can't use the SDP o= version parameter to determine in which order the UAS 
has sent SDPs?

I believe it would solve offer/answer glare situations where the UAC does 
not known in which order the UAS has sent SDPs.

Let's forbid target updates "inside" re-INVITEs. I really doubt there is a 
need for those while the UAs are doing something else with the re-INVITE.

That at least solves the glare situation where the remote target may be 
updated in a re-INVITE response and an UPDATE response.

Let's not allow more than one outstanding UPDATE. Ie if a UA has sent an 
UPDATE (with or without SDP), and receives another UPDATE request before 
the answer, it rejects it (same rule as for re-INVITE).

That would at least solve the problem where a UA sends an UPDATE, receives 
a 200 OK and a UPDATE request, both with different target information.

...and let me know if there are any issues which the ideas above do NOT 
solve. I have some more ideas, but I am not sure they are needed so I'll 
them to myself for now :)

Regards,

Christer

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
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: Christer Holmberg <[email-masked]>
Date: Thu, 27 May 2010 13:32:34 +0200

Hi,

At least the first idea is nothing "new", it's part of existing SDP.

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, May 27, 2010 2:19 PM
To: Christer Holmberg
Cc: Brett Tate; [email-masked]
Subject: Re: [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP]

Christer,

As I think sections 3.5 and 4.5 of the draft can solve the problem and having no more effects on current RFCs, I'd like to focus on the current text.

This is just one referenced implementation to prove that sections 3.5 and 4.5 is viable, and I think there might be other implementation ways for the two sections.

Regards,

Gao

2010-05-27 17:51

收件人
        "[email-masked]" <[email-masked]>, Brett Tate <[email-masked]>
抄送
        "[email-masked]" <[email-masked]>
主题
        [sipcore] New deal [ was draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP]

Regards,

Christer

---

From: [email-masked]
Date: Thu, 27 May 2010 19:44:45 +0800

Christer,

I just mean to request you to evaluate *my understanding* of sections 3.5 
and 4.5, to see whether it can solve the problem.

Thanks,

Gao 

Christer Holmberg <[email-masked]> 写于 2010-05-27

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 27 May 2010 21:31:47 +0900

Christer,

Christer Holmberg <[email-masked]>
Thu, 27 May 2010 11:51:38 +0200
>Below are some questions/ideas on how I think we could solve
>most issues. Some of the stuff shall be seen more as brain
>storming than actual proposal at this point.
>
>I am fully aware that some of the ideas for sure may limit
>what is said in RFCs etc, so you don't need to tell me
>about that.
>
>
>
>
>I know this has been discussed at some point, but what is
>the reason we can't use the SDP o= version parameter to
>determine in which order the UAS has sent SDPs?
>
>I believe it would solve offer/answer glare situations where
>the UAC does not known in which order the UAS has sent SDPs.
>

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

At least in the above case, o-version seems to be useless for
determining the order. I think the o-version of offer2 should
be the one of answer1 +1.
Even if the UPDATE has the pre-re-INVITE o-version, UA A might
be confused by the decrement.

Regards,
Shinji

>Let's forbid target updates "inside" re-INVITEs. I really
>doubt there is a need for those while the UAs are doing
>something else with the re-INVITE.
>
>That at least solves the glare situation where the remote
>target may be updated in a re-INVITE response and an UPDATE
>response.
>
>
>
>
>Let's not allow more than one outstanding UPDATE. Ie if a UA
>has sent an UPDATE (with or without SDP), and receives
>another UPDATE request before the answer, it rejects it
>(same rule as for re-INVITE).
>
>
>That would at least solve the problem where a UA sends an
>UPDATE, receives a 200 OK and a UPDATE request, both with
>different target information.
>
>
>...and let me know if there are any issues which the ideas
>above do NOT solve. I have some more ideas, but I am not
>sure they are needed so I'll them to myself for now :)
>
>
>Regards,
>
>Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 12:39:28 +0900

Christer,

>target may be updated in a re-INVITE response and an UPDATE

In the same sequence, since it is not possible to forbid a
offer-anser, the idea seems to be ineffective.
At least it might be difficult to actually use the rule.

For example, when a 2xx response to an UPDATE within an
INVITE transaction include both new remote target and an answer,
how should the UAS handle the response?

>(same rule as for re-INVITE).

I couldn't agree more.

Regards,
Shinji

---

From: [email-masked]
Date: Fri, 28 May 2010 12:53:13 +0800

Only the first chart is lawful. As the text from RFC3311:

If a UA
   uses an UPDATE request or response to modify the remote target while
   an INVITE transaction is in progress, and it is a UAS for that INVITE
   transaction, it MUST place the same value into the Contact header
   field of the 2xx to the INVITE that it placed into the UPDATE request
   or response.

If the UPDATE is in-scope of Re-INVITE, the 2xx's contact should be the 
same as the (last) UPDATE's contact. So, the second chart can only has the 
interpretation as the first chart. Then, there's no ambiguous 
representation here.

OKUMURA Shinji <[email-masked]> 
2010-05-28 11:39

收件人
Christer Holmberg <[email-masked]>, "[email-masked]" 
<[email-masked]>, Brett Tate <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [sipcore] New deal - IDEA [ was draft-ietf-sipcore-reinvite-04: glare 
and UPDATE without SDP]

Christer,

I couldn't agree more.

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 May 2010 09:19:16 +0200

Hi, 

>>doubt there is a need for those while the UAs are doing something else with the 
>>re-INVITE.
>>
>>target may be updated in a re-INVITE response and an UPDATE response.
> 
>INVITE transaction include both new remote target and an 
>answer, how should the UAS handle the response?

As I said, the UPDATE request and/or response within the INVITE transation must not include a new remote target.
 
Regards,

Christer

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 16:54:44 +0900

Christer,

We have to prepare to recieve something forbidden.
A UAC cannot reject a response to the UPDATE, even if it include
a new remote target. So does the UAC ignore only the target?

Regards,
shinji

Christer Holmberg <[email-masked]>
Fri, 28 May 2010 09:19:16 +0200
>As I said, the UPDATE request and/or response within the
>INVITE transation must not include a new remote target.
> 
>Regards,
>
>Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 May 2010 09:59:14 +0200

Hi, 

>A UAC cannot reject a response to the UPDATE, even if it 
>include a new remote target. So does the UAC ignore only the target?

Correct - in the same way as it would ignore a "new" SDP answer.

Regards,

Christer

> Christer Holmberg <[email-masked]> Fri, 28 
> May 2010 09:19:16 +0200
> >Hi,
> >
> doubt there 
> >>>is a need for those while the UAs are doing something else 
> with the 
> >>>re-INVITE.
> >>>
> target may 
> >>>be updated in a re-INVITE response and an UPDATE response.
> >> 
> >>For example, when a 2xx response to an UPDATE within an INVITE 
> >>transaction include both new remote target and an answer, 
> how should 
> >As I said, the UPDATE request and/or response within the INVITE 
> >transation must not include a new remote target.
> > 
> >Regards,
> >
> >Christer
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 18:12:47 -0400

> That should not be controversial, and does not break any RFC etc.

Shinji refuted this one.

> That at least solves the glare situation where the remote target may be updated in a re-INVITE response and an UPDATE response.

For the case of a UA that loses its IP address and must switch to 
another, it may be essential to send the UPDATE immediately. And it 
won't be getting the response to the reINVITE in that case, so it can't 
wait till it does.

In general you should almost never ignore a target refresh, unless there 
is something grievous such as an authentication failure.

> That would at least solve the problem where a UA sends an UPDATE, receives a 200 OK and a UPDATE request, both with different target information.

I'm not convinced this solves anything. And if it prevented an essential 
target refresh then it would be a bad thing.

As I stated elsewhere, I think glare should be detected individually for 
each piece of state being negotiated. Then the request can be rejected 
if some form of glare has been detected.

Target refresh isn't a glare situation, so would never fall into that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 May 2010 12:24:19 +0200

Hi, 

>>Below are some questions/ideas on how I think we could 
>>solve most issues. Some of the stuff shall be seen more as 
>>brain storming than actual proposal at this point.
>> 
>>what is said in RFCs etc, so you don't need to tell me about that.
>> 
>> 
>> 
>> 
>>I believe it would solve offer/answer glare situations 
>>where the UAC does not known in which order the UAS has sent SDPs.
>> 

Yes, but I think I didn't agree with what he said :)

So, I still think it would work.

>For the case of a UA that loses its IP address and must 
>switch to another, it may be essential to send the UPDATE 
>immediately. And it won't be getting the response to the 
>reINVITE in that case, so it can't wait till it does.

Will it EVER get the response to the re-INVITE? As far as I know a target update doesn't change the routing of responses. The re-INVITE will most likely time-out. I am not sure the re-INVITE draft talks about re-INVITE timeouts, but I assume it shall be regarded as a failure resposne?

So, eventhough I agree it could happen, I REALLY doubt you are going to be able to handle it inside a re-INVITE. As I've said before, in most cases it will also require a new registration.

>In general you should almost never ignore a target refresh, 
>unless there is something grievous such as an authentication failure.
> 
>>Let's not allow more than one outstanding UPDATE. Ie if a 
>>UA has sent an UPDATE (with or without SDP), and receives 
>>another UPDATE request before the answer, it rejects it (same 
>>rule as for re-INVITE).
>> 
>> 
>I'm not convinced this solves anything. And if it prevented 
>an essential target refresh then it would be a bad thing.

The target refresh can still be done in the UPDATE 200 OK.

>As I stated elsewhere, I think glare should be detected 
>individually for each piece of state being negotiated. Then 
>the request can be rejected if some form of glare has been detected.

But, if you receive a request first, and a response after, it may be too late to reject the request.

>Target refresh isn't a glare situation, so would never fall into that.

I think the case where you receive UPDATE 200 with target A and UPDATE request with target B is. In which order were they sent from the remote end? Which target is valid?

I just think that, by making some restrictions, we would have a much bigger chance of reaching interoperability, instead of trying to specify complicated rules, which are going to require even more complicated code to implement...

Regards,

Christer

> > ...and let me know if there are any issues which the ideas above do 
> > NOT solve. I have some more ideas, but I am not sure they 
> are needed 
> > so I'll them to myself for now :)
> > 
> > 
> > Regards,
> > 
> > Christer
> > 
> >