Subject: RE: [Simple] MSRP: Ending a session

From: "Lisa Guo" <[email-masked]>
Date: Mon, 7 Jun 2004 10:17:56 -0700

Could anybody tell me how to unsubscribe from this mailing list?

Thanks,
Lisa

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
Sent: Monday, June 07, 2004 9:49 AM
To: [email-masked]'; [email-masked]'
Subject: [Simple] MSRP: Ending a session

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

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

---

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

Hi Paul,

Comments inline ([CHH])

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

[CHH] Of course, there may be scenarios where it's good, or even required, to wait for the release response. So, the draft could say that a node MAY do so. But, at the same time we sould respect the SIP core rules, and not defining behaviour which overrides those. Otherwise things will get very messy, and things may get out of hand when new extensions, features and/or media types are defined...

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

[CHH] That is true. And RFC3264 (offer/answer) says that the parameters in an updated offer won't replace the old ones before an answer has been received. However, even then, in the special case when someone removes a stream by setting the port to zero, I am pretty sure the media resources (wether it's RTP or MSRP) in many cases are "gone", no matter if the other party accepts the offer or not. But again, of course one may keep state and resources until the answer is received, if there is a reason/possibility to do so. But, this are generic offer/answer rules, and again I don't think we should avoid re-defining them.

Regards,

Christer Holmberg
Ericsson Finland

> 
> 	Paul
> 
> Christer Holmberg (JO/LMF) wrote:
> > Hi,
> > 
> > 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.
> > 
> > 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
> > 
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 9 Jun 2004 12:14:59 +0200

Hi Ben,

>>"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
>>Later in the chapter it is also described how possible 
>>outstanding MSRP transactions are handled when a session is to be released.
>> 
>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.

[CHH] Again, RFC3261 is very clear about this, so I don't think we shall define anything different than that.

Regards,

Christer Holmberg
Ericsson Finland