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

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Dec 2003 15:20:20 -0600

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2003 17:53:26 -0500

Ben,

I agree with what you propose. One clarification below.

	Paul

Ben Campbell wrote:
> changes nothing.)

There are at least two use cases for this:

- the session has session timer active. At some point it is necessary to 
send a reinvite to honor this. It has to have some offer, but there is 
no intent to change anything.

- the session has multiple media - MSRP plus something else, say voice. 
There is a desire to change some attribute of the voice stream, but not 
of the MSRP stream.

 > Interestingly, the active party _cannot_ send an

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Dec 2003 17:53:26 -0500

Ben,

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Dec 2003 16:57:36 -0600

> There is a desire to change some attribute of the voice stream, but not 

You are right, of course.  Don't know what I was thinking...

---

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Dec 2003 16:57:36 -0600

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 18 Dec 2003 16:00:17 -0600

> participated in the email thread. I must assume that means 

No, just that I've been busy. 

We're going to see a truckload of re-signaling. I suppose the user can be
shielded from this by a more sophisticated user interface, but the wireless
users aren't going to like it much.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 18 Dec 2003 16:00:17 -0600

--
Dean