Subject: [Simple] Consensus on INVITE-established IM

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 3 Oct 2001 14:05:45 -0400 (EDT)

Great that we finally have a consensus on that.
Now to the IM transport issue..

There are several possible transports for IM sessions.
IM transport has to be defined in SDP (probably in m line).

I'd like to continue at least with SIP MESSAGE (over TCP).
The message format is ready, parsers are widely
available and interop tested. Also, any new format
would be very similar to SIP MESSAGE format anyway
(To, From, Content-Type etc are needed in any case).
This is also something which can hopefully be finalized asap
without waiting 2 years and re-inventing SIP MESSAGE with
slightly different syntax.

SIP MESSAGE session draft is already work-in-progress.
Wouldn't it make sense to finalize it with TCP-only statement ?

It seems that there already is a wide support for using
MESSAGE as an IM transport. Do we have a consensus on that?

It is probably good idea to have consensus on that first.
If there is a consensus on that, then it is time to discuss
the details, e.g:
- associating MESSAGE with later session or not 
- direct e2e vs. via proxies etc
- compression signaling
etc

--
Petri

From: "Peterson, Jon"  <[email-masked]>        
To:     "[email-masked]'"                      
Subject:     [Simple] Consensus on INVITE-established IM        

It sounds like pretty much no one out there is vehemently opposed to the
concept of INVITE-established IM sessions (independent of what, exactly, the
transport for these IM will be), and that a rough consensus supports this
protocol concept. If there is in fact any new argument to be made for
excluding this concept, this would be a good time for someone to raise it.

Jon Peterson
NeuStar, Inc
SIMPLE co-chair

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 03 Oct 2001 15:05:15 -0400

> (To, From, Content-Type etc are needed in any case).

Umm, no. If the IM session has already been negotiated through an INVITE
there's no need to resend From and To in each MESSAGE. Seems to me that
only the ability to transport MIME bodies is really needed -- basically
MIME with the Content-* headers.

Anders

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 03 Oct 2001 15:11:13 -0400

> MIME with the Content-* headers.

That is true only if the TCP connection serves exactly one IM session.
That may or may not be true.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 3 Oct 2001 15:13:22 -0400 (EDT)

> MIME with the Content-* headers.

Actually, I think they are useful in many cases.
For example, multi-party chat in which you have a session
with the group server does not identify the sender of
the message. You may want to know whether Bob or Tim sent 
the message instead of knowing that it was sent by ServerXYZ.

--
Petri

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 03 Oct 2001 15:37:58 -0400

Fair enough. Yours and Hennings points are well taken. Still, adding
sender identification is a far cry from full fledged SIP. Presumably
there's no need to send responses, to add Vias, to have CSeqs, to do
routing, loop detection, retransmissions etc. etc.  If all that stuff
goes we're arguably not even talking about SIP any longer.

Anders

"Petri K. Koskelainen" wrote:
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Petri K. Koskelainen" <[email-masked]>
Date: Wed, 3 Oct 2001 15:46:07 -0400 (EDT)

> goes we're arguably not even talking about SIP any longer.

Hmm, we need responses (with the server) and retransmissions.
Having reliable TCP does not mean that we can forget application
level responses.
Also, MESSAGEs may traverse proxies so you probably
need Vias etc.

Basically, it is still a standard SIP transaction
even if it has been established with INVITE.

--
Petri

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 03 Oct 2001 15:51:09 -0400

> goes we're arguably not even talking about SIP any longer.

As long as it's a valid SIP message, even a subset, you can re-use
existing parsers and existing specifications. This also makes message
relaying from UDP (paging mode) to TCP much easier. 

Thus, while I wouldn't want to require that the MESSAGE-on-TCP has full
SIP headers, it should be permissible to stick a full page-mode MESSAGE
into TCP without the receiver losing its lunch.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Ben Campbell <[email-masked]>
Date: Wed, 03 Oct 2001 15:49:41 -0500

Right. And there is a lot of other stuff in a SIP message that are not 
needed in an IM session negotiated with an INVITE.

We had previous discussion of using message/cpim directly. Since the 
message/cpim format allows for metadata that includes to and from 
information, it seems to fit.

Additionally, it provides for end-to-end signatures and encryption, 
which could be very nice to have.

So, as a concrete counter-proposal to MESSAGE over TCP, I propose CPIM 
over TCP (or TLS, SCTP, etc.)

Is there any strong reason why it can't work (and MESSAGE can)?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Oct 2001 18:46:34 -0400

Some questions about using SIP as a transport for MESSAGE sessions...

Does this mean establishing or reusing a sip tcp connection to an
address specified in SDP, using a port that is potentially shared with
other message sessions and other sip signaling, or to a port dedicated
to this message session?

Dedicating a port must be wrong - it eliminates many of the potential
advantages of the approach, such as firewall penetration. So I presume
it must be a shared server, probably running on a well known port,
serving possibly several message streams, and probably standard sip
signalling as well.

If so, how can individual sessions be distinguished at the server? I
think the answer is that they must be assigned sip addresses with unique
user parts. So, if my normal sip address is
sip:[email-masked], then perhaps my message sessions will be
addressed to sip:[email-masked]. There need not be any
standard way to do this - it is up to the UA to figure out when
processing the invitation - but something of this sort seems
appropriate.

Next, if one of the goals is to do the media point-to-point in order to
avoid swamping proxies with media traffic, how do we ensure that this
happens? Suppose a UA normally uses an outbound proxy - must it bypass
this and establish a sip tcp connection directly to the other endpoint?

What about firewall problems? In which direction is the tcp connection
established? Do we follow the comedia draft? (It has expired, so it will
need to be revived, and extended to support sip as a transport.)

So many problems, so little time! :-)

	Paul Kyzivat
	Cisco Systems