Subject: RE: [Simple] MSRP: Some thoughts on session updates

From: [email-masked]
Date: Tue, 16 Dec 2003 17:55:16 +0200

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 16.December.2003 16:26
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] MSRP: Some thoughts on session updates
> 
> 
> [email-masked] wrote:
> 
> > I also agree, but I require a clarification, see inline...
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Ben Campbell
> >>Sent: 15.December.2003 23:20
> >>To: Simple WG
> >>Subject: [Simple] MSRP: Some thoughts on session updates
> >>
> >>
> >>We have had a lot of discussion on how we deal with 
> >>connection failures, 
> >>session continuance across a failure, duplicate supression, 
> >>etc. Much of 
> >>that depends on how we handle session updates. Here are 
> some thoughts 
> >>for discussion.
> >>
> >>Although the sense of the room at IETF58 indicated we 
> needed a way to 
> >>re-establish TCP connections without resignaling, subsequent list 
> >>discussion has indicated consensus that this will not work, 
> >>and we will 
> >>indeed have to re-signal. I am slightly concerned that many 
> >>of those who 
> >>favored reconnection without resignaling at the meeting have not 
> >>participated in the email thread. I must assume that means 
> >>they agree ;-)
> >>
> >>Obviously resignaling means a new SDP exchange. For SIP, that 
> >>would mean 
> >>a re-INVITE or an UPDATE. Since the MSRP spec only 
> tangentally talks 
> >>about sip, I think the re-INVITE vs UPDATE question is out of 
> >>scope, and 
> >>is treated sufficiently well in the UPDATE rfc.
> >>
> >>So, here are some assumptions and observations about how an updated 
> >>offer/answer would work.
> >>
> >>0) We don't have to worry about early media. (I expect this to be 
> >>controversial, but I can always hope. The following are 
> based on that 
> >>assumption.)
> >>
> >>1) The active party must remain the active party. If the 
> active party 
> >>initiates an updated offer, it MUST NOT contain a session URL.
> >>
> >>2) The passive party must remain the passive party. If the 
> >>passive party 
> >>initates an updated offer, it MUST contain a session URL. 
> >>This updated 
> >>URL may be the same as before, or may be completely different, even 
> >>pointing to a completely different location.
> >>
> >>3)If the passive party sends an updated offer with a semantically 
> >>identical URL as the original, this indicates no change. (I 
> >>don't know 
> >>why you would do this, but Paul asked for an example of an 
> >>update that 
> >>changes nothing.) Interestingly, the active party _cannot_ send an 
> >>updated without giving the active party a chance to provide a new 
> >>session URL.
> > 
> > 
> > I assume you mean "without giving the passive party a chance...".
> 
> Uhm, yes. Sorry.
> 
> > 
> > In this case, do you think that 1) will ever happen? Why 
> can't the active party send an update without first the 
> passive party providing a new session URL?
> > 
> > Or have I missed your point?
> 
> I think you missed the point. It can send an update without 
> the passive 
> party first supplying a new URL. Basically, it works like this:
> 
> Active                   Passive
>     new offer (no url)------->
>     <-----resp (may have URL)-
> 
> So, when the active party sends an update, without a URL, the passive 
> party may or may not send a new URL back. The active party cannot 
> prevent the passive party from doing so.

What would the active party do with this URL if it came in the SDP answer from the passive party?

> 
> It occurs to me their may be a problem here. If the active party is 
> sending an update because it has detected a connection 
> failure, it may 
> need a way to _insist_ on a new URL. If the passive party has not yet 
> noticed the failure, it cannot tell the difference between a 
> "no change" 
> update and a "connection broken" update.

The passive party should notice since I would assume the active party is sending an updated offer with a new m-line. The old m-line port is set to 0.

It is a new MSRP session and therefore needs a new media line. You cannot use an already existing m-line if it has not bee n perviously disabled by setting the port to 0.

Regards,
Hisham

> 
> > 
> > /Hisham
> > 
> > 
> >>4) A corrolary of 1) and 2) is that direction=both would not be 
> >>permitted for an update.
> >>
> >>5) Updated offers can occur for both healthy sessions and as 
> >>a result of 
> >>connection failures, etc.
> >>
> >>Thoughts?
> >>
> >>Ben.
> >>
> >>
> >>_______________________________________________
> >>Simple mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/simple
> >>
> 
> 
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2003 10:04:49 -0600

[email-masked] wrote:
[...]It can send an update without
> What would the active party do with this URL if it came in the SDP answer from the passive party?

I think it would visit the new URL. (i.e. resolve the URL, connect, 
visit, etc.) The interesting question to me is, if it thinks the old 
connection is still good, does it disconnect from it? And if so, does it 
need to wait for the new visit to succeed first?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2003 10:04:49 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2003 15:10:07 -0500

> It is a new MSRP session and therefore needs a new media line. You cannot use an already existing m-line if it has not bee n perviously disabled by setting the port to 0.

If it was done this way, how could the recipient know that the new MSRP 
session is intended to *replace* the old one, rather than just dropping 
the old one and creating a new one that is intended to be logically 
distinct?

As long as we reuse the same m-line it is clear that we are dealing with 
the same media session. Otherwise I think we would need to resort to FID 
to tie different ones together.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2003 15:10:07 -0500

Paul

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2003 14:25:44 -0600

Paul Kyzivat wrote:

>>> sending an update because it has detected a connection failure, it 
>>> may need a way to _insist_ on a new URL. If the passive party has not 
>>> yet noticed the failure, it cannot tell the difference between a "no 
>>> change" update and a "connection broken" update.
>>
>>
>>
>> The passive party should notice since I would assume the active party 
>> is sending an updated offer with a new m-line. The old m-line port is 
>> set to 0.
>>
>> It is a new MSRP session and therefore needs a new media line. You 
>> cannot use an already existing m-line if it has not bee n perviously 
>> disabled by setting the port to 0.
> 
> 

Would the "a=reconnect" attribute described in COMDEDIA be useful here?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2003 14:25:44 -0600

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2003 17:15:09 -0500

> Would the "a=reconnect" attribute described in COMDEDIA be useful here?

I need to go reread what ended up getting written in there.
If it ended up so you had to do something special when you want to 
reconnect (as it sounds) then yes. I fussed about how that worked for 
awhile, but finally lost interest in it when it became apparent that it 
wasn't going to work for IM.

Whats bad is if you have to do something special in order to achieve a 
noop condition. Sending the same sdp as the last time when in a steady 
state condition should continue in a steady state condition.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Dec 2003 17:15:09 -0500

Paul