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: [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
> 
> 

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

---

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

Hi Ben,

I agree with what you state below.

Just to make sure I understand it correctly though, the restrictions for the active party to stay active and the passive to stay passive when updating do indeed also apply to adding another MSRP media component to an existing session?

Because, it makes little sense to repeat a "offer both-> try active and fail -> answer passive" sequence for each new MSRP component added to a session. This is an additional benefit we would get by the below restrictions, which is a good thing. Of course, this would not allow negotiating 'direction' per MSRP session inside a SIP dialog, but I don't see much use for that anyway.

Cheers,
Aki

 > Sent: 15 December, 2003 23:20
 > To: Simple WG

---

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

Ben Campbell wrote:
 > > Because, it makes little sense to repeat a "offer both-> 
 > try active and fail -> answer passive" sequence for each new 
 > MSRP component added to a session. This is an additional 
 > benefit we would get by the below restrictions, which is a 
 > good thing. Of course, this would not allow negotiating 
 > 'direction' per MSRP session inside a SIP dialog, but I 
 > don't see much use for that anyway.
 > 
 > I think I agree, as long as we are only talking about MSRP 
 > sessions. I 
 > don't think the direction of some other kind connection 
 > oriented media 
 > session would necessarily imply the direction for MSRP, but 
 > I think one 
 > MSRP session can definitely imply a direction for a second 
 > MSRP session.

Definitely agree that this would only apply to MSRP. Other connection oriented medias (or indeed the COMEDIA stuff in general) may define their own ways for handling this. 

Cheers,
Aki

---

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

> 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:
> 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Ben Campbell
> 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?
> > 
> 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

---

From: [email-masked]
Date: Tue, 16 Dec 2003 18:14:21 +0200

> Sent: 16.December.2003 18:05
> [...]It can send an update without
> >>the passive 
> 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?

As I said in the previous email (I'm not sure if you read down that far :) The new offer sent by the active party will contain a new media line (m-line), the old m-line would have the port set to 0 disabling it. This is how the passive party knows that it needs to disconnect from the old one.

/Hisham

---

From: [email-masked]
Date: Thu, 18 Dec 2003 10:35:11 +0200

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 17.December.2003 22:10
> Cc: [email-masked]; [email-masked]
> > 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.
> 
> 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?

What are the use cases where an end point would end an old IM session only to start a new one, where the new one is not *replacing* the old one?

/Hisham

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