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

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

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 17.December.2003 22:10
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] MSRP: Some thoughts on session updates
> 
> 
> 
> 
> [email-masked] wrote:
> > 
> >>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.
> 
> 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
> 
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Dec 2003 17:33:31 -0500

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

I don't offhand have one for the simplest case, though give me some time 
and I may be able to come up with one.

But I do have a slightly more complex one:

- start out with call havine one MSRP session.

- add a 2nd MSRP session for a file transfer.

- lose connectivity  on both.

- decide to attempt restoration of only one.
   (perhaps because don't want to retry the file xfer automatically)

- with your approach, the two original m-lines would each get a zero
   port number, and a 3rd m-line would would be used for the
   recovered session.

How does the answerer know which session the new m-line replaces?

As soon as there are multiple MSRP sessions the number of scenarios like 
this multiply. I think there must be some clear way for the endpoints to 
associate the new session with the old one. Note this is true whether 
lost messages are to be retransmitted or not. This affects the UI - does 
the old window, with its history of the conversation, get attached to 
the new session, or is a new window created?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Dec 2003 17:33:31 -0500

Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Dec 2003 15:12:19 -0600

Paul Kyzivat wrote:

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

So, how would you deal with that if these were RTP session?

Back to the original question of how do we tell a "reconnect" offer from 
a "don't change anything" offer: I just had an offline discussion with 
Robert, where he points out that, if there is any change, the o line 
version will change. So it seems like we could say that, if the active 
sides sends a new offer with the same version number, it means no 
change. If it has a new version number, it means reconnect.

(I note with great embarrassment that the examples in the MSRP draft are 
missing o lines...)

This does not seem to solve Paul's issue of replacing one stream, but 
not another. It is not clear to me that this is an MSRP issue, 
though--how would you handle it for RTP?

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Dec 2003 15:12:19 -0600