Subject: RE: [Simple] IM transport

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 3 Oct 2001 20:04:30 -0400

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Wednesday, October 03, 2001 7:42 PM
> To: 'Petri K. Koskelainen'; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] IM transport
> 
> Some time ago Jonathan sent out a list of requirements for 
> this transport
> protocol:
> 
> http://mailman.dynamicsoft.com/pipermail/simple/2001-August/00
> 0583.html
> 
> I would suggest that we revisit these criteria to make sure 
> this is what
> we're looking for (I recall that conferencing was added as a 
> requirement to
> this list) and then attempt to find a protocol that satisfies these
> requirements.

I agree. It will really help, I think.

Some more to add based on list discussions:

* must support transport intermediaries for firewall traversal
* must support multiplexed transport of messages over shared connections
between intermediaries
* must provide an identification of the originator
* e2e acknowledgement of message receipt (question: do we really need this?
CPIM requires it, but its really meant for the paging model, not the session
model)

> Initially I see no reason why all of the apparatus of SIP 
> headers, much of
> which is used for message routing, should be necessary in the 
> transport
> protocol. If we really need SIP proxies to route IMs, we 
> should be sending
> them in paging mode. The point of having an alternative to 
> paging mode was,
> as I understood it, precisely to enjoy the benefits of -not- 
> sending IMs
> through proxy servers.

Well, thats one benefit. THe primary benefit is that wrapping things in
INVITE/BYE provides the ability to use other SIP mechanisms for IM - things
like refer, conferencing, etc.

Its also worth considering which SIP features "get in the way" of what we
want to do for IM transport. Assume we go with the idea of sending the IMs
as MESSAGEs within the call leg, with some kind of SDP indicator of doing
this. What limitations are introduced?

One clear one is throughput. non-INVITE requests are limited to one per RTT
at best, since you can't initiate a second non-INVITE transaction within a
call leg while one is in progress. Large IM will also affect call setup
times of other things going through the proxies. Proxies are likely to
record-route INVITE not just for firewall traversal, but for features. These
proxies wouldn't normally want to see an IM. THe result is increased latency
for IMs, and increased load on proxies.

-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: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Oct 2001 22:47:06 -0400

Paint me confused. I thought the point was that this was a session, but
over "plain" TCP and possibly in the future SCTP, not routed through SIP
proxies. Thus, it's SIP MESSAGE, but all the normal SIP routing headers
are ignored, if present (if we choose that format).

What you're saying below sounds like it's using the normal SIP message
forwarding.

> as MESSAGEs within the call leg, with some kind of SDP indicator of doing
              ^^^^^^^^^^^^^^^^^^^
                 this is where my confusion comes in

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Oct 2001 09:08:12 -0400

Jonathan Rosenberg wrote:
[snip] 
> CPIM requires it, but its really meant for the paging model, not the session

I think the last is needed, at least optionally. Especially consider a
case of an IM conference. It may be important to know when everyone in
the conference has received your message. This could be especially true
if you are sending something other than text messages (e.g. graphics).

Consider a conference involving both voice and IM media, where the IM is
used to deliver slides and the voice channel is used to discuss them.
You might like to know that a slide has been received by all parties
before beginning to talk about it.

e2e acknowledgement can provide this if the conference server manages
the acknowledgements properly. This could be a policy in the server. A
different (store and forward) policy would ack before distributing when
e2e is not important.

	Paul