Subject: RE: [Simple] Message session & associated dialog

From: [email-masked]
Date: Tue, 16 Jul 2002 07:47:33 +0300

Hi All,

I don't understand why you would need to have a dialog for the one-shot message. I think it has been already explained in both sip-message and message-session why such a thing is not a good idea. However, if something more concrete than the "imaginary" dialog is needed, then MESSAGE as media in an INVITEd session is the way to do it. This is what I thought Jonathan was also referring to in his mail, i.e., what Call-ID is used in MESSAGEs within the session media and so on.

Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it?

Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept or reject a "medialess" INVITE?

Cheers,
Aki 

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, July 15, 2002 4:27 PM
> To: Jonathan Rosenberg
> Cc: Peter Päppinghaus; [email-masked]
> Subject: Re: [Simple] Message session & associated dialog
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > > draft-rosenberg-simple-message-session-00 is silent about 
> construction
> > > of Call-ID and From and To header tags in the MESSAGE 
> requests sent
> > > within a message session.
> > 
> > Well, the draft was just a proposal.
> > 
> > I guess the messages would all use the same dialog ID, with 
> increasing
> > CSeq within the dialog. Different dialog ID than the INVITE 
> one, of course.
> 
> It makes sense that all the messages share a dialog. The 
> question is: what causes this dialog to be established?
> 
> There are currently two ways of establishing a dialog:
> 
> - the 2xx reply to an INVITE can establish one
> 
> - the 2xx reply to a SUBSCRIBE can establish one
> 
> In the case we are discussing, MESSAGE requests are the only 
> thing being sent along the path where we want a dialog. But 
> we don't want the response to every MESSAGE request
> to establish a dialog. Some possibilities:
> 
> - send a medialess INVITE to establish a dialog, and then 
> send the MESSAGEs within that dialog.
> 
> - permit the recipient of a MESSAGE to decide contextually 
> whether to establish a dialog. (Would require some rules to 
> prevent doing so when all the flow control
> constraints haven't been met.)
> 
> Sending another INVITE is straightforward, but seems a bit 
> circuitous and wasteful of round trips. But using the MESSAGE 
> to do this may lead to a blurring of the
> distinction between page and session mode messaging.
> 
> 	Paul
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Jul 2002 15:23:17 -0400

[email-masked] wrote:
> 
> Hi All,
> 
> I don't understand why you would need to have a dialog for the one-shot message.

As far as I am concerned, none of this discussion has anything to do with one-shot (page mode) messages. It would indeed be a bad idea to require a dialog for page-mode
messages.

> Having MESSAGE set up a dialog (for example) may sound reasonable, but when would such a dialog end? Would I have to remember this dialog indefinitely, just in case someone replies to it?

Agree there are a multitude of problems with this.

> Using a "dummy" INVITE is also problematic. Not only does it blur the paging mode and the session mode, but also, what happens if the other end rejects? How would a user determine whether to accept…

It does raise some issues. I think they are resolvable, but it isn't clear that they are worth resolving.

I am becoming convinced that the best solution is to say that the message "session" consists of page-mode messages over the negotiated route, without any common dialog,
common callid, etc. Any message ordering that is required can be handled in the message body using CPIM.

	Paul