Subject: [Simple] MSRP: Ending a session

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 7 Jun 2004 18:48:42 +0200

Hi,

Chapter 6.5.4 in the MSRP draft (version -06) says:

"When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for the
signaling protocol.  For example, in SIP, it would send a BYE request
to the peer.  After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the session."

Later in the chapter it is also described how possible outstanding MSRP transactions
are handled when a session is to be released.

Now, I don't think it should be a must for a node to wait for a node to receive the BYE response before the TCP resources are released. Many nodes releases the media resources at the same time as the BYE is sent. And, even if would keep the connection open for possible outstanding MSRP transactions they would most likely be "lost" anyway, since a user will not (in gateway scenarios may not even be able to) wait for possible messages after the release message is sent.

Also, chapter 15.1.1 in RFC3261 says:

"Once the BYE is constructed, the UAC core creates a new non-INVITE
client transaction, and passes it the BYE request.  The UAC MUST
consider the session terminated (and therefore stop sending or
listening for media) as soon as the BYE request is passed to the
client transaction."

To me this clearly indicates that a node does not need to keep resources and wait for anything after the BYE is sent.

Regards,

Christer Holmberg
Ericsson Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Jun 2004 13:53:38 -0400

Christer,

Obviously you can't force anybody to do anything. If they want to cut 
you off in mid conversation then that is what they will do, just like 
hanging up on you in a conversation. But its not polite.

In some sense the situation is no different with MSRP than it is with 
voice and RTP. However I think MSRP exposes issues that are small enough 
to ignore with voice. In particular, with voice, if you lose a small 
number of packets typically nobody cares, because with voice there is 
little information content in a small number of packets. But with MSRP, 
a "packet" (message) can have substantial content, so that whether it 
gets thru or not can have considerable significance.

This will be true in all sorts of call flows, such as transfers, and is 
true here at the end of a session. So we should be defining mechanisms 
that can work gracefully, without loss of messages. Whether people use 
them that way is up to them.

Also, I see many people talk as if BYE was the only way to end an MSRP 
session. But it is not. It may be ended simply by sending a reINVITE (or 
UPDATE) that drops the MSRP stream (by setting the port number to zero). 
This may not be a very useful thing to do when MSRP is the only medium 
in use, but it can make a lot of sense when there are other media. For 
instance, I might start in an IM session, then decide to add voice. Once 
voice has been added, I may just close my IM window, killing the MSRP 
stream.

In a case like that there is more lattitude to keep the state of the 
stream until all the signaling to kill it is complete. For instance, 
when I close my IM window that can implicitly initiate the reinvite to 
drop the stream. But even though the window disappears, its state can 
remain. If another incoming message is received, the window can be 
popped again to show it to me.

	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 08 Jun 2004 15:53:41 -0500

> Now, I don't think it should be a must for a node to wait for a node to receive the BYE response before the TCP resources are released. Many nodes releases the media resources at the same time as t…

The intent was not that you must wait until that point, but that you 
must eventually release the resources. I agree it could be worded a 
little better.