Subject: RE: [Simple] MSRP - Ending a Session

From: [email-masked]
Date: Tue, 1 Jul 2003 14:08:46 +0300

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, June 30, 2003 10:44 PM
> To: Ben Campbell; Robert Sparks; Jonathan Rosenberg
> Cc: [email-masked]
> Subject: [Simple] MSRP - Ending a Session
> 
> 
> (We had this discussion a long time ago, but I think it is worth 
> revisiting in the context of MSRP as it currently stands.)
> 
> I think we can and should specify behavior that results in a graceful 
> close of an MSRP session, where messages are not lost. Now 
> that we have 
> dedicated tcp connections for each session this is easier 
> than it once 
> was. Here is what I have in mind:
> 
> - an endpoint SHOULD NOT signal its intent to end the session 
> while it 
> has any unconfirmed SEND messages outstanding.
> 
> - if an endpoint receives a request to end the session while it has 
> unconfirmed SEND messages outstanding, it SHOULD refuse the 
> request to 
> end the session.
> 
> A request to end a session via reINVITE can be refused by responding 
> with an error. (The code 491 is close to the right response, 
> but I don't 
> know if it is permitted to use it in this situation.) The 
> advantage of 
> this approach is that it doesn't cost any extra in normal cases where 
> there is no race condition.

So, when there is a race condition (SEND and reINVITE cross)

A              B
----------------

SEND (MRSP)
------>
       reINVITE (SIP)
     <---------- 

2 scenarios for B:
- It will eventually receive the SEND before it receives the error response to the reINVITE. In this case it should respond to SEND and then wait for the error response for the reINVITE before it issues it again (or should it re-issue the reINVITE before it receives a response to the first one?)

- It will receive the SEND after it receives the error response to the reINVITE. In this case it should respond to SEND and then  re-issue the reINVITE. The question is, how long to wait for the SEND to arrive?

Regards,
Hisham

> 
> Some requests to end a session (such as BYE) can't meaningfully be 
> refused. In those cases the session may not terminate gracefully.
> 
> I see conflicts over the ending of a session quite frequently 
> with IM. I 
> say something that I think terminates the conversation and 
> shut down the 
> window, only to have the other party respond. Typically (at 
> least with 
> Sametime) the window is recovered and the session resumes. I think we 
> would be ill advised to do something less acceptable.
> 
> Of course all the above needs to be SHOULD strength, because UAs must 
> have the option of quitting whenenver they feel they must.
> 
> 	Paul
> 
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Jul 2003 09:37:51 -0400

Hisham - comment at end.

	Paul

[email-masked] wrote:
> - It will eventually receive the SEND before it receives the
> error response to the reINVITE. In this case it should respond
 > to SEND and then wait for the error response for the reINVITE
 > before it issues it again (or should it re-issue the reINVITE
 > before it receives a response to the first one?)

There may be no error in this case, depending on timing at A.

B should respond to the SEND, and continue to await a response to the 
reINVITE.

> 
> - It will receive the SEND after it receives the error response
 > to the reINVITE. In this case it should respond to SEND and then
 > re-issue the reINVITE. The question is, how long to wait for the
 > SEND to arrive?

That is TBD. Do you have any good ideas? In some sense it doesn't 
matter, except as a tradeoff between efficiency and promptness of 
shutting down the session. If B tries again too soon, the error will 
simply be repeated.

 From a practical perspective, it will often probably be sufficient for 
B to check if anything (e.g. a partial message) has been received on the 
media stream, and if so keep waiting. When it eventually receives a full 
message, respond to it. Then if there is more in the pipe, repeat. If 
there is nothing in the pipe then retry the reINVITE, possibly after a 
brief delay.

The ugly case here is where the SEND from a is that fabled 5GB file.

Another option is for B to reconsider its attempt to shut down the 
session. It could simply decide that A still wants to talk, and so 
continue. But this is an application decision, not protocol.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Jul 2003 09:37:51 -0400

Hisham - comment at end.

	Paul

	Paul