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

From: [email-masked]
Date: Mon, 22 Jul 2002 13:34:30 +0300

Forget for a second that instant message inside a session use sip. To instantiate a session for any type of media, it being voice, video, white board, etc, we use INVITE. Now think of IM as another media, INVITE would be used for that too.

It just happens that the protocol used to carry the instant messages in this case is SIP, just like RTP is used to carry audio. They are not related to signalling.

Continuing to compare RTP and SIP as the media carrying protocol. The port identified in SDP is the one that is used to group the packets, so it being RTP or SIP is irrelevant. If, during signalling in the INVITE, you indicate that audio packets are received on port 45123 and IM packets are received on port 45130, then there is no need to create a dialog to group the packets. You can  just use the port.

To sequencing, CSeq is enough in this case since IMs are grouped together because they are received on the same port (you can replace 'port' with 'socket' if you wish.

Regards,
Hisham

> -----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
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Jul 2002 15:00:01 -0500

> From: Sean Olson [mailto:[email-masked]]
> 
> Hmmm. Tag will work in this case (within a dialog),
> but the tag doesn't really differentiate a source
> outside of a dialog. 

  "When a tag is generated by a UA for insertion into a request or
   response, it MUST be globally unique and cryptographically random
   with at least 32 bits of randomness." [RFC3261]

Working through the math, this gives about a 0.00000000069849%
chance of collision between two sources, and 0.00000001280569% 
chance of any collision amongst 10 sources.

Heck, even with 1000 contributors, your chances of collision
are still around 0.0001%.

I suspect these numbers are good enough for demultiplexing
sources in an IM session -- especially when you consider that the
consequences of failure are close to negligible.

If anyone considers this unacceptable, perhaps we can suggest a
syntax of "tag=32-bits-of-randomness!host.domain" for session-mode
messages.

/a

P.S. Can you tell that I've been working with birthday-paradox
     problems recently?
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Jul 2002 17:36:19 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> 
> Adam Roach wrote:
> > 
> > > From: Paul Kyzivat [mailto:[email-masked]]
> > >
> > > I don't think it is safe to assume that the From will be
> > > unique from source to source.
> > 
> > Isn't this the exact reason the "tag" parameter was introduced?
> > 
> > /a
> 
> I don't think so. For purposes of sip signalling, the 
> MESSAGEs in a message session aren't part of the dialog of 
> the INVITE that established the session. They aren't part
> of any dialog. So either each MESSAGE gets a new tag in its 
> From header, or else it gets no tag at all.

You're right. Since there is no dialog, they won't match.
Mea culpa.

So, I'd agree, then, that we need something equivalent to
SSRC for session-mode messages.

/a