Subject: [Simple] MSRP: updates and re-invites

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 15:52:10 -0500

We have had a lot of discussion on how to handle updated offers in SIP 
updates and re-invites. We had made some proposals back when we 
negotiated connection direction that are not really relevant any more.

The design team spent some time discussing this, and came up with a 
proposal:

Reconnection no longer an issue with connection sharing. TCP connection 
establishment is done on-demand. Therefore we do not need a way to 
signal a desire to establish a new TCP session.

The offerer of a new sdp exchange assumes the role of offerer for all 
purposes, regardless of whether it was the origininal offerer.

An offerer or answer is effectively unchanged if the path does not 
change from the previous version. If either side changes the path, then 
we effectively have a new session.

If offerer does not change anything, answerers can still make changes. 
Answerer must always answer with a currently valid path. These could be 
the same as before the update, or different.

Local policy may choose to re-invite to fix session problems without 
user interaction, or give user a choice. (examples: you get an error 
report to the initial send, a mobile device looses connectivity through 
tunnel, etc.)

I invite everyone who cares to think this through, and make sure we are 
not breaking something important.

Thanks!

Ben.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2004 17:25:59 -0500

In the shared connection model, connections are as-needed. By 
implication, we do not signal connections, we signal sessions. If we 
signal a session, and the endpoints already have a connection that will 
serve, they use it.

So, if we don't signal the connections in the first place, why would we 
signal a new connection?

Paul Kyzivat wrote:

> Ben,
> 
> I think what you describe here is what we discussed at some point, that 
> should work. But the general wording below leaves me a bit uncertain of 
> that. Am I right that point below is that if the path is unchanged then 
> the old connections are reused, while when the path is changed (by 
> either end) then the offerer establishes a new connection?
> 
>     Paul
> 
> Ben Campbell wrote:
> 
>> Reconnection no longer an issue with connection sharing. TCP 
>> connection establishment is done on-demand. Therefore we do not need a 
>> way to signal a desire to establish a new TCP session.
>>
>> change from the previous version. If either side changes the path, 
>> then we effectively have a new session.
>>
>> Answerer must always answer with a currently valid path. These could 
>> be the same as before the update, or different.
>>
>> report to the initial send, a mobile device looses connectivity 
>> through tunnel, etc.)
>>
>> I invite everyone who cares to think this through, and make sure we 
>> are not breaking something important.
>>
>> Thanks!
>>
>> Ben.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jun 2004 18:12:32 -0400

Ben,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jun 2004 18:51:13 -0400

> So, if we don't signal the connections in the first place, why would we 

Unless I missed a change somewhere, connections *at the endpoints* are 
not entirely as-needed. In particular, if a connection has gone away but 
is still needed it cannot just be made again.

But I agree that the need to do that can be defined away, by saying that 
loss of the connection implies loss of the session, so that a new 
session must be requested.

I think this is what you mean, and if so that is fine. I just want to be 
sure.

	Paul

> Paul Kyzivat wrote:
> 
>> Ben,
>>
>> I think what you describe here is what we discussed at some point, 
>> that should work. But the general wording below leaves me a bit 
>> uncertain of that. Am I right that point below is that if the path is 
>> unchanged then the old connections are reused, while when the path is 
>> changed (by either end) then the offerer establishes a new connection?
>>
>>     Paul
>>
>> Ben Campbell wrote:
>>
>>> We have had a lot of discussion on how to handle updated offers in 
>>> SIP updates and re-invites. We had made some proposals back when we 
>>> connection establishment is done on-demand. Therefore we do not need 
>>> a way to signal a desire to establish a new TCP session.
>>>
>>> If offerer does not change anything, answerers can still make 
>>> changes. Answerer must always answer with a currently valid path. 
>>> These could be the same as before the update, or different.
>>>

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2004 13:40:48 -0500

Paul Kyzivat wrote:

>> signal a session, and the endpoints already have a connection that 
>> will serve, they use it.
>>
>> So, if we don't signal the connections in the first place, why would 
>> we signal a new connection?
> 
> 

Oops, yes, you are correct.

> I think this is what you mean, and if so that is fine. I just want to be 

Yes, that is what I mean.

>>>> The offerer of a new sdp exchange assumes the role of offerer for 
>>>> all purposes, regardless of whether it was the origininal offerer.
>>>>