Subject: [Simple] MESSAGE sessions - over TCP

From: "Petri K. Koskelainen" <[email-masked]>
Date: Tue, 25 Sep 2001 11:39:16 -0400 (EDT)

There hasn't been any conclusion or rough consensus relating to 
the SIP MESSAGE session model.

It seems that there are two main proposals:

1: Implicit MESSAGE session (no INVITE, just MESSAGEs).

2: Use of INVITE to establish a SIP session and then using
some protocol X to carry the messages. The X protocol
may be SIP MESSAGE, BEEP-based, some new protocol etc.
IESG has ruled out SIP MESSAGE mainly because of three reasons:
- large message overhead in SIP headers 
- lack of congestion control (in UDP only)
- size limitation (in UDP only)
However, SIP MESSAGE over TCP should be ok. Message overhead is an 
issue only in wireless environment, but SIP compression (even UDPcomp) 
eliminates the overhead. 
TCP has also other advantages (like the use of TLS).
 
I really think that something should be decided asap. Option 2 with SIP 
MESSAGE over TCP seems to be ok. It does not have to be the one-and-only
format for next 100 years. If someone really wants it, he can specify 
BEEP-based or whatever additional formats inside a SIP 
session - just like it is possible to create new RTP formats. 
However, SIP session model and MESSAGE over TCP is sufficient for 
many applications and therefore it would be really useful 
to continue at least with that (and have something to use asap).

Since other formats inside a session may be defined later, the real
question is whether the INVITE established session is needed or not.
I think yes. This is similar to audio/video sessions, and it allows e.g.
the use of record-route, mobility etc.

--
Petri

---

From: [email-masked]
Date: Wed, 26 Sep 2001 15:35:33 +0200

Agree with both (MESSAGE over signalling channel and a asap resolution).

avshalom
Sametime/Lotus/IBM

                    "Robert Osborne"                                                                                            
                    <[email-masked]        To:     "Petri K. Koskelainen" <[email-masked]>,                  
                    .com>                             <[email-masked]>                                          
                    Sent by:                          cc:                                                                       
                    [email-masked]        Subject:     RE: [Simple] MESSAGE sessions - over TCP                     
                    icsoft.com                                                                                                  

                    25/09/2001 20:02                                                                                            

Hi,

there is also a third option, which is a combination of the other
two.

3) Use of INVITE to establish an IM session, and then using MESSAGE
over the signalling channel to send the IMs.

This is my preferred option, as it gives all the control and flexibility
of the INVITE, plus the ability to traverse firewalls in a manner that
can be controlled by the administrator.

I agree with you that there should be resolution on this matter as soon
as is possible.

Rob O

>-----Original Message-----
>From: Petri K. Koskelainen [mailto:[email-masked]]
>Sent: Tuesday, September 25, 2001 8:39 AM
>To: [email-masked]
>Subject: [Simple] MESSAGE sessions - over TCP
>
>
>
>_______________________________________________
>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: "Sriram Parameswar" <[email-masked]>
Date: Wed, 26 Sep 2001 12:29:49 -0500

Comment in-line; pardon the plug!

Sriram

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 10:52 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: [rohc] RE: [Simple] MESSAGE sessions - over TCP

At 5:35 pm +0300 26/9/01, [email-masked] wrote:
>If we have SIP MESSAGEs over TCP directly between UAs, is SIP compression
>applicable? Usually the compression is meant to be used between a UA and
the
>(outbound) proxy, but is there anything hindering the End-to-End case? I
>suppose the UAs would have to agree to use compression in SDP as part of
the
>transport description?
>
>Is this part of the signaling compression requirements?
>
>Rgs,
>	Markus
>
Hi there,
   my understanding was that: Initially, the end systems agree "out of band"
(e.g the SUAS listens on a particular port for compressed messages).
This should work for TCP or UDP.

Don't believe that anyone has seriously suggested yet another addition to
SDP to indicate compressed SIP should be used (i.e. to negotiate).
The goal is to compress even the initial SIP message; this would not be
possible if negotiation were carried in SDP (carried inside a SIP message
:).

<<Sriram>> 
Please see
http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiate-00.txt
<</Sriram>>
BR,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Fri, 28 Sep 2001 11:41:06 +0200

I think that this all thread started from the following IESG requirement
that was sent by Jon Paterson at 20 August 2001:

<<<
The IESG has some concerns that this mechanism constitutes the use of SIP
as
a transport protocol. In other words, once the session has been established
between the two endpoints by the INVITE, if the MESSAGEs can only go
directly end-to-end, then their headers and related protocol apparatus are
entirely superfluous and may do more harm than good. We saw during the
meeting last week that there were definitely some pitfalls to allowing
methods other than MESSAGE across the IM stream (as well as questions about
overlapping transactions, redirection, forking, and so forth), and it isn't
clear that the overhead is justified if MESSAGE is just an envelope for its
encapsulated MIME payload. The IESG was particularly concerned, in addition
to the protocol overhead, with congestion characteristics of the messaging
session and with the precedent that could be set by using SIP in this
fashion.

I am not sure if this means that if we define a session and the messages
will not have superfluous headers
then it will be OK with the IESG. I certainly hope so.

avshalom
Sametime/IBM/Lotus

                    Jonathan Rosenberg                                                                                          
                    <[email-masked]>         To:     "'Petri K. Koskelainen'" <[email-masked]>,                
                    Sent by:                          [email-masked]                                                         
                    [email-masked]        cc:     [email-masked]                                    
                    icsoft.com                        Subject:     RE: [Simple] MESSAGE sessions - over TCP                     

                    26/09/2001 22:30                                                                                            

> Sent: Wednesday, September 26, 2001 1:21 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Simple] MESSAGE sessions - over TCP
>
> Is there a consensus that INVITE-established IM messaging
> session idea is ok ? (in addition to one shot MESSAGEs)
>
>
> If we can agree on that, then we can continue with other
> problems, like:
> - messaging protocol/format inside a session (e.g. SIP
> MESSAGE over TCP)
> - direct end-to-end vs. via signaling proxies vs. via IM servers
> - compression (hopefully this does not have to be discussed here)
>
> There should be a resolution on this asap.

Yes, part of the reason we are circling around is that we have not been
able
to break the problem into pieces. Clearly the first is the question Petri
has asked - can we agree that a session model for messaging (session model
being to wrap it in INVITE/BYE, and the messages are viewed as a media
stream.) THis says nothing about how they are transported, and wouldn't
rule
out sending them over the signaling channel.

I strongly support this need for a session model. I think most have
expressed support for it, with a few notable exceptions (Dean, I think).

I think its time for the chairs to make a ruling on consensus on whether to
pursue a session model as defined above.

We would still retain the paging model of course,

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 28 Sep 2001 08:25:44 -0400

> > session idea is ok ? (in addition to one shot MESSAGEs)

I agree with it.  I'd like to hear from anyone who doesn't
agree with it before we have more discussion on what
form the INVITE-established IM Messaging takes (both what
the format of the messages are and the transport that they
run on).  The question on the table is only whether we
believe we require sessions of messages initiated by
INVITE.  I think that implies an SDP expressed description
of the format and transport of the session.

If we get a consensus on the need, THEN we can start talking
about format and transport.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 28, 2001 5:41 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]; 'Petri K. Koskelainen';
> [email-masked]; [email-masked]
> Subject: RE: [Simple] MESSAGE sessions - over TCP
> 
> 
> 
>                     <[email-masked]>         To:     
> "'Petri K. Koskelainen'" <[email-masked]>,                
>                     Sent by:                          
> [email-masked]                                             
>             
> Subject:     RE: [Simple] MESSAGE sessions - over TCP         
>             
>                                                               
>                                                                   
>                                                               
>                                                                   
>                     26/09/2001 22:30                          
>                                                                   
>                                                               
>                                                                   
>                                                               
>                                                                   
> 
> 
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Fri, 28 Sep 2001 14:49:26 +0200

> > > session idea is ok ? (in addition to one shot MESSAGEs)

I think that INVITE-established IM sessions are essential. Especially when
dealing with multi-party chat. Also in one to one, establishing a session
may yield certain benefits as deciding on the encryption to be usedand and
other properties of the session.

avshalom
Sametime/Lotus/IBM

                    "Rosen, Brian"                                                                                   
                    <Brian.Rosen@ma        To:     "[email-masked]'" <[email-masked]>                     
                    rconi.com>             cc:     Jonathan Rosenberg <[email-masked]>, [email-masked],  
                                           "'Petri K. Koskelainen'" <[email-masked]>,                        
                    28/09/2001             [email-masked], [email-masked]      
                    14:25                  Subject:     RE: [Simple] MESSAGE sessions - over TCP                     

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 28 Sep 2001 10:59:05 -0400

The reason you want to have sessions, with a transport with flow controls,
is to support large server based systems.  If you were very successful, your
proxy servers may be asked to handle millions of messages.  You want flow
controls for this folks.  It may not matter to the individual endpoints, but
it matters a lot to any aggregation resources.
 
Brian

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Friday, September 28, 2001 10:53 AM
To: [email-masked]'; Rosen, Brian
Cc: [email-masked]; Jonathan Rosenberg; 'Petri K. Koskelainen';

>dealing with multi-party chat. 

I keep hearing statements like this, but it seems 
that multi-party chat is actually easier to implement 
using a paging model and a implicit session concept. 

If you want a chat session, what is wrong with the 
RTP text stuff (ignoring the unicode/MIME issues) 

I am personally in favor of INVITE-established IM 
messaging as well, but I think its principal 
purpose is efficiency. 

Sean Olson 
Ericsson Inc.

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 28 Sep 2001 11:14:41 -0500

>
>If you have just one message to send, you don't have to 
>establish a session. Just send a MESSAGE. 
>No need for INVITE then.
>
>In general, IM session is just another media stream just like 
>audio or video stream.
>Often it is established at the same time than the
>audio and video streams (one m line for each media stream).
>This is the ideal situation since it allows all the
>control and flexibility of INVITE for IM session 
>(e.g. mobility, record-route, multi-party IM..).
>

mobility???

>Still, one-shot MESSAGEs can be sent if someone does
>not want to use the session model.
>

Exactly. You can achieve the same effect of an IM session with a set
of one-shot MESSAGE exchanges between the two end-points. So what is
the gain in doing an INVITE before exchanging a number of MESSAGEs. 

>session idea is ok ? (in addition to one shot MESSAGEs)

Not (yet) entirely convinced on the need for IM sessions. Hopefully
there are others who think IM sessions are really a critical feature
for IM and voice their opinions. 

>
>If we can agree on that, then we can continue with other problems,
like:
>- messaging protocol/format inside a session (e.g. SIP MESSAGE over
TCP)
>There should be a resolution on this asap.

-Basavaraj

---

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 28 Sep 2001 11:39:32 -0500

Just a thought in-line. 

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

>not want to use the session model.

[bpatil]Exactly. You can achieve the same effect of an IM session with a set
of one-shot MESSAGE exchanges between the two end-points. So what is
the gain in doing an INVITE before exchanging a number of MESSAGEs. 

[Sriram] At the UA it is easier to tie multiple different converstations
together if it has been set up using an INVITE. For example all messages in
a session show up in one window while all one-shot messages show up in a
pop up box (yes... I know this is an implementation issue, still there is
merit in looking at it). Other methods suggested on the list of using
one-shot
messages and tie them together into a session are hacks IMHO.

>session idea is ok ? (in addition to one shot MESSAGEs)

[bpatil]Not (yet) entirely convinced on the need for IM sessions. Hopefully
there are others who think IM sessions are really a critical feature
for IM and voice their opinions. 

[Sriram] Another example is when Messaging is added to an existing session,
it would be simpler to re-invite and add on another media. An example of
the applicability would be - call to a help-center to set up a 
product (foo); they open a messaging window in the context of the 
existing session and send you line-by-line written instructions.

I would think there is a fair bit of consensus.

---

From: "Liu Zhigang.C (NRC/Dallas)" <[email-masked]>
Date: Fri, 28 Sep 2001 18:56:33 -0500

> Whether to apply compression or not should be 
> decided by the application e.g. SIP. SigComp is just the tool 
> that the application will use for compression. 

Of course. That is what I meant by "user" and "service 
provider" (and the line between them) in my email.

> Basically, there are two issues:
> 1) Whether compression is to be applied or not,
> 2) How to negotiate the SigComp parameters (If any needs to 
> be negotiated). What we should do is to first define what 
> parameters that we see a need to negotiate. Then we could 
> start thinking of how to do the negotiation. And also if the 
> parameters need to be negotiated or if they can be signaled 
> "in band". 

Agree. While 1) is the agreement between the two users (e.g.
two SIP modules), 2) should be negotiated in a user independent
way between the peer SigComp modules which know the dirty
details. And of course, 2) is triggered by 1).

BR,
Zhigang

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 1 Oct 2001 17:27:46 -0400

> From: Liu Zhigang.C (NRC/Dallas) [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 4:21 PM
> To: [email-masked]; 'ext Lawrence Conroy'; Isomaki Markus
> (NRC/Helsinki); [email-masked]; [email-masked]
> Subject: RE: [rohc] RE: [Simple] MESSAGE sessions - over TCP
> 
> > However, there might be a need to negotiate other parameters, 
> > e.g. The usage of a Codebook/Byte-buffer, buffer memory etc., 
> > But, we have to think of the complexity issue with too many 
> > parameters to set/negotiate, and also if SigComp itself 
> > should do this kind of negotiation or if some other protocol 
> > should do this, e.g. according to 
> > http://search.ietf.org/internet-drafts/draft-spbs-sip-negotiat
> > e-00.txt . My belief is that SigComp should not have its own 
> > negotiation procedure.
> 
> Sorry, I haven't had time to read through the sip-negotiate draft. 
> I agree with you that we should keep the number of parameters to 
> minimal. However, I feel that the parameters you just mentioned
> are closer to SigComp than to SIP. They are really tied to the
> algorithms/procedures of SigComp. In my view, the negotiation 
> should be either defined with SigComp in one document or in 
> a separate document (brother/sister of SigComp). But in either 
> case, we should draw a line between SIP (the "user" of SigComp) 
> and SigComp (the service provider). The interface between
> the two is the negotiation protocol. 

I agree. Most of the parameters that need to be negotiated are SigComp and
belong in that protocol. The only thing SIP needs to "negotiate" is whether
this is used at all. That is easily done using SRV, or more generally, using
the whole set of SIP techniques for determining what transport protocol to
use (its quite like negotiating TLS usage, which is a shim ontop of TCP.
Sigcomp is a shim ontop of UDP).

-Jonathan R.

---

---

From: [email-masked]
Date: Wed, 3 Oct 2001 10:35:26 +0200

This suggested combined page-session mode comes to overcome the limitation 
of either mode.
page-mode messaging is a burden on the SIP proxy network, as it requires 
all messages to go through the proxies, while p2p session-mode requires 
much higher first-message sending time, and indeed many times the session 
is one-message only.
This combined mode tries to get these two modes into one. namely, start in 
page-mode, and transition to session mode.
Still, if the end user actively want to initiate a session (that is, 
selects "chat with..." menu option instead of "send a message to..." 
option), then the session-mode can be initiated. But I find most chat 
sessions start with a single page-mode message, which is often left as a 
single-message-session.

----------------------------------------------------------------
Dror Tirosh <[email-masked]>
VocalTec Communications, Ltd
--------------------------------------------------------------

Paul Kyzivat <[email-masked]>
01/10/2001 15:17

        To:     [email-masked]
        cc:     Jonathan Rosenberg <[email-masked]>, "'Petri K. Koskelainen'" 
<[email-masked]>, [email-masked]
        Subject:        Re: [Simple] MESSAGE sessions - over TCP

[email-masked] wrote:
>
> I think message chats should be wrapped by an INVITE/BYE, as a chat
> session is indeed a session.
> However, unlike other media types, a chat starts with a single
                                            ^^^^^^
                                            may start

> message, and it seems to me a burden (for the SIP network) to require
> that a single message be sent using an INVITE wrapper.
> The actual session will be initiated by the callee of this initial
> message (so he can send the reply within the session)The only protocol
> change required is a way to associate the original message (which was
> sent before the SIP session was created) with that session.

What you suggest is one usage model, where the sender of the first
message doesn't anticipate a conversation, but the recipient decides a
session is required. But it certainly isn't the only usage model - it
quite possible that the need for a session is anticipated from the
beginning.

Certainly both of these scenarios can be supported. Yours is simply a
combination of paging mode usage plus session mode usage. It does get a
bit complicated if you wish to tie the session to the initial page, but
I don't know if that is really required.

        Paul Kyzivat
        Cisco Systems