Subject: [Fwd: Re: Re: [Simple] Implicit MESSAGE sessions revisited]]

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Sep 2001 11:19:54 -0400

Dean,

Can you please elaborate? (Your brief assertion isn't very convincing.)
 > One can manipulate the participants in a messaging relationship
independently of INVITE/BYE semantics.

Sure you can. But you need to use media specific means to do so. If
multiple media are being used together, then you need to manipulate them
separately, and using different techniques. If the point is to transfer
a multimedia call, then that is a very unfriendly way to do it.

> One can also refer to a call from within a message, without the
message being part of that call.

How? Unless you propose to stardardize a way, it becomes impossible to
have common tools understand the association between the two.

I get the impression that you really believe that IM is so different
that there is no reason to imagine it being used in conjunction with
other media. If so, then there is also no reason for SIMPLE - you might
as well go with BEEP.

    Paul

-------- Original Message --------
   Subject: Re: Re: [Simple] Implicit MESSAGE sessions revisited]
      Date: Tue, 18 Sep 2001 09:50:15 -0500
      From: "Dean Willis" <[email-masked]>
        To: "Paul Kyzivat" <[email-masked]>,"simple"
            <[email-masked]>
References: <[email-masked]>

  One can manipulate the participants in a messaging relationship
independently of INVITE/BYE semantics. One can also refer to a call from
within a message, without the message being part of that call. The ONLY
justfication for INVITE/BYE bounding a MESSAGE sequence that I've
recognized (or at least am willing to admit) to-date is path
optimization with record-route/route. --
Dean

     ----- Original Message -----
     From: Paul Kyzivat
     To: simple
     Sent: Monday, September 17, 2001 12:33 PM
     Subject: [Fwd: Re: [Simple] Implicit MESSAGE sessions
     revisited]
      Dean,

     So, you don't you don't see the advantage of using INVITE to
     set up an IM 'session' (indicating this in the SDP)? Why not?
     Without this, you lose the ability to:
     - associate the IM session with other related media sessions
     that should be used together;
     - transfer the IM session to another endpoint while retaining
     its identity as a session;
     - transfer a grouping of media sessions as a unit if IM is
     involved.

     I agree that the ability to do this is independent of how the
     session content is transported. It is certainly *possible* to
     introduce a session via SDP, but have that session multiplexed
     on a common transport by the application level. I believe
     there are a number of problems with that, but it is certainly
     an appropriate subject for discussion.

     But first it is important to agree that it must be possible to
     negotiate these sessions by the exchange of SDP. I know there
     are people other than myself who believe this is essential. I
     don't have a good sense of how many disagree. This is an
     essential point to resolve.

         Paul Kyzivat
         Cisco Systems

     Dean Willis wrote:
     >
     > No, we're clearly thinking something different here. I'm
     proposing providing
     > the concept of a "session" as a sequence of messages, with
     that sequence
     > association being indicated at the application rather than
     transport layer.
     >
     > For example, the message body itself might contain a session
     identifier and
     > a sequence number.
     >
     > This would allow the receiving client to render messages
     into appropriate
     > windows in an appropriate order, as appropriate to the
     implementation,
     > without the transport layer being aware of that behavior.
     >
     > --
     > Dean
     >
     > ----- Original Message -----
     > From: "Henning G. Schulzrinne" <[email-masked]>
     > To: "Dean Willis" <[email-masked]>
     > Cc: <[email-masked]>
     > Sent: Saturday, September 15, 2001 9:34 AM
     > Subject: Re: [Simple] Implicit MESSAGE sessions revisited
     >
     [snip]
     > > Just for clarification:
     > >
     > > Are you assuming that TCP (or, presumably, SCTP) is used?
     Are you
     > > assuming that the TCP connection is kept open implicitly?
     > >
     > > (To avoid artificial disagreement: I would agree that a
     regular SIP
     > > session over TCP would address most of the requirements,
     but just saying
     > > "paging" isn't quite enough.)
     [snip]

     -------- Original Message --------

        Subject: Re: [Simple] Implicit MESSAGE sessions revisited
           Date: Mon, 17 Sep 2001 11:32:14 -0500
           From: "Dean Willis" <[email-masked]>
             To: "Mark Watson" <[email-masked]>,"Patil Basavaraj
                 \(NET/Dallas\)" <[email-masked]>,"'ext Ben Campbell'"
                 <[email-masked]>
             CC: "simple" <[email-masked]>
     References: <[email-masked]>

     Both, actually. I believe the issues are independent. --
     Dean

          ----- Original Message -----
          From: Mark Watson
          To: 'Dean Willis' ; Patil Basavaraj (NET/Dallas) ;
          'ext Ben Campbell'
          Cc: simple
          Sent: Monday, September 17, 2001 9:39 AM
          Subject: RE: [Simple] Implicit MESSAGE sessions
          revisited
           Dean,

          Do you mean that you don't see the advantage of
          using INVITE to set up an IM 'session' (indicating
          this in the SDP), or just that once such a session
          is set up, there is no need for the 'media' to use
          any different protocol than that used for 'paging' ?

          I think there are a lot of reasons why IM 'sessions'
          set up using INVITE just like any other SIP session,
          make sense. I don't care much yet what the transport
          protocol then is for the IMs in the session.

          Sorry if this is covering old ground.

          ...Mark