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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 3 Jul 2004 13:31:56 +0200

Hi Paul,

If you really want to make sure you receive everything on the TCP connection (or any other transport mechanism) before freeing the resources I guess you would have to first send an "inactive" or "sendonly" re-INVITE, get a response, wait for a while (to make sure everything "on the line" reaches you) and then send BYE. 

Yes, this behaviour is very "heavy" and ugly, but that's the way you have to do it using SIP...

And, even if you DO wait for the 200, which Eric said may not even come, there is still a chance it will reach you before the last bit of the "media".

And, also if you use MESSAGE for IM there is a risk that there is a request on the line when you send BYE, and free your session level resources, so I don't think this is a MSRP-only problem.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 1. heinäkuuta 2004 20:37
> To: Eric Burger
> Cc: Christer Holmberg (JO/LMF); [email-masked]';
> [email-masked]'
> Subject: Re: [Simple] MSRP: Ending a session
> 
> 
> 
> 
> Eric Burger wrote:
> > I agree with Christer.  If you really want this behavior, 
> extend SIP.  I
> > don't want this behavior codified.  In the real world, the 
> media resources
> > are long gone by the time the BYE hits.
> > 
> > I really, really don't want to write-in an enormous 
> denial-of-service
> > opening by requiring the resources to stay around for 200 
> OK's that will
> > never come.
> 
> I've lost the beginning of this thread, so I don't have a record of 
> exactly what was proposed. So I will shoot from the hip.
> 
> I certainly don't want to *require* resources to be held 
> after BYE. It 
> would be especially stupid to do that when the UA will have nothing 
> better to do with incoming media than drop it in the bit bucket.
> 
> OTOH, I think it at least ought to be permissible for a UA to 
> try to get 
> the last bit of media that might trickle in after the session 
> is closed, 
> and to process it if that has meaning for the device.
> 
> There clearly is a problem with the chapter 15.1.1 of 3261 in 
> this regard:
> 
> "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."
> 
> Its reasonable to require that media not be sent. But at least in the 
> case of connection oriented media, it makes sense to permit any media 
> remaining in the connection to be processed. (Its a little 
> dicier with 
> non-connection-oriented media because input to the same port 
> may not be 
> from the same source.) Details about the interpretation of 
> this may need 
> to be media specific.
> 
> In the absence of this, when using MSRP, if I want to ensure 
> that all my 
> messages have been processed before ending the session I will have to 
> send a last message with a requested positive acknowlegment before 
> ending the session. (I guess this could be an empty message if I have 
> nothing left to send when I want to end the session.)
> 
> There may be a more interesting case to consider than the BYE of a 
> simple call. Consider a case when A & B are directly connected, but 
> there is a need to move to a mixer to establish a conference. In this 
> case lets assume for simplicity that both A and B receive an 
> INVITE/Replaces from the new focus, offering a new MSRP session. We 
> presumably want the switch to be graceful with no messages 
> lost. How do 
> A and B manage the use of their old and new MSRP connections, and the 
> termination of their old call in order to achieve this?
> 
> I believe both A and B will want to stop sending and suck the old 
> connection dry, before beginning to use the new connection. This will 
> require closing the old stream for output but continuing to read till 
> eof. Upon eof, switchover to the new stream can occur. But 
> somebody has 
> to send a BYE on the old call too. And neither A nor B will 
> know what is 
> really going on. So neither knows the other has been told to stop 
> sending. To ensure they will stop receiving input, both A and B will 
> want to send a BYE. With current rules, they will have to 
> stop receiving 
> at that time, messing things up.
> 
> 	Paul
> 
> >>-----Original Message-----
> >>From: Christer Holmberg (JO/LMF) 
> >>[mailto:[email-masked]]
> >>Sent: Monday, June 07, 2004 2:24 PM
> >>To: 'Paul Kyzivat'
> >>Cc: [email-masked]'; [email-masked]'
> >>Subject: RE: [Simple] MSRP: Ending a session
> >>
> >>
> >>
> >>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,
> >>>>
> >>>>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
> >>
> > 
> > 
> 

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