Subject: RE: [Simple] IM: A session or not

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Apr 2001 11:18:06 -0400

This discussion seems to have stalled.

We have not yet clearly identified what
problem we want to solve.

We _have_ defined two types of messaging
to discuss - "page", and "chat".

I believe we have a good solution for "page".

Do we want to provide a standard mechanism
to signal a "chat"?

  If we do, we have some non-trivial techincal
  decisions to drill down on.

  If we don't, we will have applications appear
  (we have already seen them) that will define
  their own mechanisms for doing so.

The opinions I have heard to date indicate this
is a problem we must solve. If anyone has substantive
technical dissent, put it forward asap.

Given that we address providing the mechanism, I've
seen several proposals:

  1) Standardize what some implementers have already
     done - allowing a MESSAGE to infer a session into
     existance (i.e. a "chat" is a sequence of MESSAGES,
     sharing the same call-leg identifiers). This has
     numerous problems, mostly focused around state
     management (When do sessions go away, how does
     routing apply to them?). This approach does not
     seem to have any champions.

  2) Create a session for the chat.

     a) Using INVITE/BYE, signalling a MESSAGE based chat
        with the SDP, including enough information to indicate
          1)  The sequence of messages to follow a different path
              than the INVITE and BYE. 
          2)  The sequence of messages follows the same path as
              the INVITE and BYE.
        One problem to address will be how endpoints working with
        routing elements can indicate that INVITE to voice sessions
        should go to one endpoint (a phone maybe) while INVITEs to
        chat should go somewhere else.

     b) Using something other than INVITE/BYE to bound MESSAGE based
        chat.

Have I missed anything? 

RjS

---

From: "Roland Auckenthaler" <[email-masked]>
Date: Wed, 25 Apr 2001 08:50:48 +0100

>      b) Using something other than INVITE/BYE to bound MESSAGE based

I'm quite new to the topic of SIP and also this mailing list but in my
opinion another solution for a "chat"-based session could use a similar
setup to presence, i.e. SUBSCRIBE/NOTIFY. A "chat-room" can be entered using
a SUBSCRIBE. This is notified by the server. Then further messaging to and
from the server is done using MESSAGE. Subsequent NOTIFY requests could then
allow to signal state changes in the chat room, such as leaving or entering
of new users.

Roland