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

From: [email-masked]
Date: Tue, 16 Dec 2003 11:10:04 +0200

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...".

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?

/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 08:25:57 -0600

> I assume you mean "without giving the passive party a chance...".

Uhm, yes. Sorry.

> 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.

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.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2003 08:25:57 -0600

Uhm, yes. Sorry.

Active                   Passive