Subject: RE: [Simple] IM over the signaling connection

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 00:56:13 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 12:11 AM
> To: Peterson, Jon
> Cc: [email-masked]'; Ben Campbell; 
> [email-masked]
> Subject: Re: [Simple] IM over the signaling connection
> 
> 
> > Frankly, it has never really been clear to my why, if 
> network conditions
> > adverse to the creation of a chat session exist, an IM 
> client can't just
> > default to the paging method. If the performance 
> requirements of the network
> > make paging infeasible, then something like a stun server could be
> > introduced with minimal, if any, impacts to the 
> construction of SIMPLE
> > messages. Either way, I haven't yet understood the 
> justification for some
> > sort of hybrid chat-of-MESSAGEs-through-proxies session.
> > 
> 
> If you mean chat-of-MESSAGE-through-SIP-proxies, I agree.

Its worth noting, at least, that chat-of-MESSAGE-through-SIP-proxies is what
has been proposed by numerous people on the list.

> If there's a
> problem getting direct connectivity, this is a problem for 
> all TCP (and
> presumably even more so, UDP-based media). One of the strengths of the
> SIP model is the idea that I can transition from a pure 
> MESSAGE chat to
> something else, e.g., adding voice. It is very confusing if MESSAGE
> works, but then there's no way to set up additional media, some of the
> time.

I agree. We are working through mechanisms to get RTP to work through these
elements, and they inevitably require some kind of forwarding intermediary
for media. So, we would need the same for IM as well. If, based on your
proposal, we use MESSAGE as the transport of IM, when an intermediary is
needed, how is that not a proxy? In that case, once you have decided to use
IM as transport, have you not then decided to do
chat-of-MESSAGE-through-SIP-proxies?

> The argument for using a SIP MESSAGE format in a session (NOT 
> routed via
> proxies) is at least two-fold:
> 
> - any implementation already has the SIP parser (and maybe the
> compression engine, if needed);

I don't think this is a very strong argument. IM needs so few headers that
the parsing is not a major issue. Also, do note that a CPIM message can be
parsed by a SIP parser, as its a valid sip-frag. This was quite on purpose.

> 
> - bridging between page mode and session-mode is very easy (e.g., at a
> conference server), without loss of information.  

If you are doing conferencing, I'm not sure you want page mode at all. There
are things that are quite hard to do (like adding a participant) without a
session model. I don't want to reinvent all that stuff for paging mode.
Doing a "mailing list" kind of function does make sense for paging mode, but
thats hardly a conferencing server.

> If you ignore political correctness, what is the advantage of 
> using the
> CPIM format? Is it only the extra header overhead and how big,
> percentage-wise, would this be? Maybe we should draw up the 
> minimum SIP
> MESSAGE format and the corresponding CPIM version to get a better feel
> for the trade-offs.

IMHO, the benefit of not using SIP as a transport is that these transport
intermediaries can do pure bit level forwarding across connections (stated
more simply, tranport intermediaries can actually operate at the transport
layer). I don't want these intermediaries to even look inside the packet.
The main proponents of the SIP MESSAGE for IM transport argue for it because
they can easily use existing proxies as these intermediaries. These elements
would then need to look at SIP components for forwarding logic. I think
there is a huge difference in ultimate performance between these two cases. 

Whether the headers within this transport are cpim or something new, I
really don't have a strong feeling on that.

-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: Ben Campbell <[email-masked]>
Date: Fri, 05 Oct 2001 08:42:39 -0500

Jonathan Rosenberg wrote:

[snip]

> 
> I don't think this is a very strong argument. IM needs so few headers
> that the parsing is not a major issue. Also, do note that a CPIM message
> can be parsed by a SIP parser, as its a valid sip-frag. This was quite
> on purpose.

Also consider that an IM endpoint _must_ already have a CPIM parser, 
since message/cpim is a required-to-implement feature.

[snip]