Subject: Re: [SIP] a proposal for a way to compromise? (really, not a joke)

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 10:31:19 +0200

Scott,

I'm very relieved that other folks with a SIP background are thinking about
the sort of combination you suggest.

After lunch with the BEEP chair, I drew the following conclusions.  Please
note that these are my personal opinions, and not necessarily those of my
employer, etc.

- Both IMPS and IMXP satisfy the base requirements for IM and P
- SIP is superior for handling *mobile* presence
- The SIP MESSAGE method is simple and apropos for messages that fit in one
datagram
- BXXP is much better for bigger messages (GIF/JPEG, powerpoint, shared
browsing...)
- SIP could easily setup BXXP sessions

thanks,
-rohan

At 08:39 PM 8/2/00 , Scott Petrack wrote:
>
>[The following is written in haste, because I discovered I have to take an
>early plane out of the IETF. I'm really sorry to miss the BOF tonight, but
>I'll certainly answer email questions:]
>
>I tried hard to do what Dave Crocker suggested, and thought about what the
>'other side' is really after, and the fact is that once I put myself in
>this frame of mind, I came pretty quickly to a few ideas that point to a
>compromise. I know that this is considered impossible, and that many
>people are just waiting for the two weeks to pass so that the group can
>split in two, but I hope you'll give the following ideas a decent
>look-over. I'll state up front that I am guilty of two things: I am from
>the SIP side of the house, and I have not been as active on the list as I
>should have been. But I spoke to a few people yesterday, and I believe
>that the following is new input. If not, I apologize.
>
>First, Dave Crocker's exercise: what does each side bring to the table,
>beyond "take my protocol, please...."
>
>The really essential service that SIP offers is 'session initiation'. It
>was absoutely designed from the beginning as a way to HAND OFF to another
>protocol. SIP is only one piece in a puzzle that includes SDP (for
>describing voice/video sessions) and RTP (for transmitting realtime data).
>The original intent was that SIP would hand off to the actual media
>transport session as soon as possible
>(an RTP session in the case of realtime voice/video). In fact, basic SIP
>(without extensions) does a relatively poor job of managing or modifying
>sessions that already exist. 
>
>The key thing to remember from all this is that SIP is 
>crafted to allow the sort of "finding"/"signaling" and "hand off to
>another protocol". It is designed to do this under some very important and
>difficult conditions -- mainly when people and terminals are moving
>around, and when it's not clear at the beginning the people want to IM.
>What SIP is less designed to do is to pass around crazy types of
>text and non-text instant messages (although of course SIP can do
>*anything* ;-)) that have nothing to do with a later hand-off to a
>multimedia session.
>
>Now, on the other hand, my understanding is that the "messaging" people
>feel that the key elements of MIME and SMTP push are very important to
>them. In fact, my understanding is that the 'mobility rendez-vous parts'
>of IMXP are less established and tested yet than various nooks and
>crannies of the problems of getting a message reliably and quickly from A
>to B.
>
>I for one think it very reasonable to suppose that people who have been
>thinking about how to do messaging for many years are very good at their
>craft, and have thought a lot about the nooks and crannies of the
>different horrors that might occur when trying to transport "instantly"
>different types of "messages". Maybe they've even thought more than the
>SIP people have about this ;-). I'm particularly thinking about what will
>happen when the message is large (a big image or large HTML message, etc.)
>
>So my proposal for compromise is the following:
>
>use SIP for rendezvous and distributing presence -- find the other
>person/people, help decide that the *way* they want to communicate is via
>IM, and then HAND OFF to an IM protocol, one that is designed to be
>extensible to all kinds of instant messaging (large gifs, powerpoint
>presentations, shared browsing, whatever, etc.).
>
>If IMXP is a better "IM transfer protocol", then it's very
>reasonable to leave it to do just that, and have a user signal that
>he wants to IM you by having the SIP hand off to IM. 
>
>I'm hoping (probably in vain) that what really offends the SIP people is
>doing finding/rendezvous in some other protocol than SIP, and that what
>really offends messaging people is using SIP to transfer messages.
>
>To be honest, this already happens in one very special kind of instant
>messaging -- people who are into telephone devices for the deaf (TDD) have
>defined an RTP format for realtime delivery of text. If you've ever seen a
>device like this, it is the original "instant messaging device". It
>enables people who could not otherwise use a phone to communicate over the
>phone. And in the SIP version of this service, SIP is used to 'set
>up' the call, but soon enough the call is handed off to RTP, using the
>special RTP format for these kinds of text messages. NO NO NO -- I'm not
>suggesting that we do instant messaging this way. I'm suggesting that this
>model -- where SIP rendez-vous and hands off to a different protocol -- is
>the core SIP model, and already is used for a very special kind of
>"instant messaging". SIP really does this "find/rendezvous/hand-off"
>piece very well, and it would be silly to reinvent it.
>
>At this point, I think that it's worth saying that the accusations about
>"SIP taking over the user" are really not true. There are many many things
>that one might want to do with a user which have nothing to do with
>communicating with her/him. I might want to configure the user's computer
>(if I'm the sysadmin), I might want to send mail to his telephone,
>whatever. SIP has indeed been designed for the
>particular issue of "I've got a user name, and I want to do realtime
>communication with him". SIP is not intended to 'own the user'. *That* is
>a directory problem, and SIP is NOT a directory service, nor was it ever
>intended to be one.
>
>As a final comment (I'm sure I'm gonna regret saying this), it does look
>as if IMXP is a less mature protocol, in the good old IETF sense of
>multiple interoperable implementations. (remember "running code". That was
>supposed to carry some weight). So for the really stupid requirement to
>send a short piece of text from one host to another, the MESSAGE method 
>works just fine. This could be used as a stop gap while the more elaborate
>IMXP details are being worked out. There are many details still to be
>worked out in the SIP proposals for rendezvous and presence. But they
>really are details, and I'll bet that this work could be completed
>quickly, to be followed by completing the work on finishing details of
>IMXP for instant message delivery.
>
>Scott
>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 03 Aug 2000 12:25:44 -0500

As mentioned by Marshall Rose, there are several protocols that
may work equally well...

From the perspective of a network service provider, it may be
advantageous to have the smallest number of protocols on the
network to deliver services. Each new protocol means extra
resources to develop and maintain OSS, skill sets etc. From this
point of view, having SIP do many things is an advantage IMHO.

Also, as mentioned in the meeting, service providers are part of
the food chain.

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Rohan Mahy
>Sent: Thursday, August 03, 2000 3:31 AM
>To: Scott Petrack; [email-masked]; SIP reflector
>Cc: [email-masked]
>Subject: Re: [SIP] a proposal for a way to compromise?
>(really, not a
>joke)
>
>
>Scott,
>

---

From: Greg Hudson <[email-masked]>
Date: Thu, 03 Aug 2000 13:54:41 -0400

> advantageous to have the smallest number of protocols on the network
> to deliver services. Each new protocol means extra resources to
> develop and maintain OSS, skill sets etc. From this point of view,
> having SIP do many things is an advantage IMHO.

I hate playing market analyst, but:

From the perspective of a network service provider, it may be
advantageous to have the smallest number of *implementations* to
deliver services.  If I need one SIP product from company X which
provides IMPP services and another SIP product from company Y which
provides multimedia session management services, that will require
extra resources.  Similarly, if I have a single product which
implements both SIP's multimedia session management and some
hypothetical separate IMPP protocol, that won't require extra
resources.  (Well, not any more than a single product which implements
both features of SIP.)

Don't confuse protocols with implementations.  Whether the traffic for
applications A and B are framed the same way and/or go over the same
port is basically irrelevant to service providers.

Also, from the perspective of a network service provider, lumping
multiple applications into the same protocol makes it harder to
filter the protocols separately.

---

From: Keith Moore <[email-masked]>
Date: Thu, 03 Aug 2000 15:30:56 -0400

> point of view, having SIP do many things is an advantage IMHO.

the complexity is in the number of services, more than the
number of protocols. overloading several services on top of 
a single protocol doesn't solve the problem.  it might even
make things more confusing.

also, if the different uses of SIP don't have the same usage
patterns, it doesn't necessarily make sense to overload multiple
functions on a SIP server.  you want to provision machines 
differently depending on the usage patterns of the protocols
they support.

none of the above argues for different presentation layers
(though there are other arguments for not reusing this aspect
of SIP), but it does argue for not bundling multiple functions
within a SIP protocol.

Keith

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 03 Aug 2000 20:12:07 -0500

This discussion has covered several aspects:

1. End user: Integrated IP communications with SIP
  - Telephony, multimedia, data conferencing,
  - Presence
  - Instant messaging with text, voice
  - Games, etc.
Stan writes on companion list what I believe is also pertinent:
>If a different
>protocol is required to send a text page that is an additional
requirement
>on the device. While it's not difficult to have a PC (or even a
PDA)
>support multiple protocols, we're looking at low-cost consumer
devices
>where very extra bit of RAM is going to increase the cost to
the consumer.

2. Architecture: See the seven I-Ds submitted

3. Operational: My previous comments

4. Vendors: Several SIP implementations for the above.

What is the problem you are trying to solve?

Patrick wrote:

>I, as AD, have asked the IMPP wg to go through this process
step by step
>without excluding step (c), and I would like everyone in the
group to

Fully agree. Some of the steps seem to have already been walked,
but it will be useful for the whole group to go over all the
steps again together. Would be great to get to an agreement.

Henry

>[mailto:[email-masked]]On Behalf Of Greg Hudson
>Sent: Thursday, August 03, 2000 12:55 PM
>To: Henry Sinnreich
>Cc: [email-masked]; SIP reflector

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 02:30:48 -0400

> filter the protocols separately.

So let me be specific about this sharing of resources that I have been
advocating:

1. SIP proxies are, at the core, routing engines. They route independent
of method (MESSAGE or INVITE or SUBSCRIBE). Service providers deploy
them in numbers to get scalable session establishment amongst their
users. These proxies would be able to be reused completely, and with no
additional management cost. What is used to get an INVITE from user 1 to
user 2 gets an IM from user 1 to user 2. 

2. SIP networks have repositories of data (I don't want to say
databases, since the precise implementations vary - some use real
databases, some disk, some memory) which represent the presence status
of users connected to the network. Right now, these data repositories
are used primarily for the routing functions I mentioned in point 1
above. It is this exact same data which you need for SUBSCRIBE/NOTIFY.
The exact same. So, my deployed data repositories, and all the tools I
already have to manage looking at it, adding users, etc. are all going
to work for provision of presence services. 

3. People are building SIP devices like phones and PDAs of all different
sorts. These devices will be able to be communicated with through their
usage of REGISTER, which is used to upload their presence (location and
availability) into the data repositories in point 2. Now, by using this
mechanism as the one used for presence publication, all of these devices
now become things I can also subscribe to. The devices don't need to be
specially enabled for presence. Don't you think it would be cool if it
were possible to subscribe to someones cell phone and find out if its
off or on?

Will there be additional management costs for deploying presence?
Surely. You will need additional infrastructure for managing the
subscription lists and the notifications. However, the additional costs
are much, much less than they would be if I needed to duplicate the
stuff I am mentioning above.

Let us not bypass the benefits afforded to users of the system. I think
it is fair to say users will want to have services that integrate
presence with voice, video, and other communications. Thats happening
today. By using the same infrastructure for the two, some neat services
become possible:

1. I get a new sip phone, plug it in. Now, people can subscribe to that
and know when I am talking on the phone. 

2. I indicate that I don't want to receive calls from Bob after 5pm. I
subscribe to a service which "reflects" these preferences into IM and
presence too. This way, I don't get IMs from Bob after 5pm, nor will I
honor his subscriptions.

Can these kinds of things be done without SIP for presence? Sure. But
with much more complexity. Take service 2. I would implement this in SIP
by an access control mechanism in my proxy server that, when it receives
a request from Bob, rejects it if its after 5pm. Now, this
implementation will, for free, reject INVITE, SUBSCRIBE, and MESSAGE
with equal ease and little extra work. Thus, providing an integrated
communications filtering service is easy. In fact, its *extra* work to
make the service different depending on the communications type (not
much extra, of course). 

In IETF (the iptel working group) we have also developed this thing
called CPL (Call Processing Language), which is a simple XML scripting
language for expressing preferences for sip call routing. Its "uploaded"
into proxy servers, and right now its logic executes when an INVITE
arrives, controlling how the session initiation is processed. It can
express things like service 2 above, plus other things like forwarding
preferences. I can route calls based on time of day, caller, subject,
priority, etc. Don't you think it would be nice if I, the user, could
have as an option this CPL apply to both calls, IMs, and presence
messages? Is it not reasonable to say that I want high prioirty IMs and
high priroty calls to go to my cell phone? Very, very easy when the same
infrastructure is used. Just make sure your CPL executes on not only
INVITE, but also MESSAGE and SUBSCRIBE. Thats it. 

If IM and presence are in a totally separate system, I need to worry
about how these kinds of things are programmed in both; propagated to
both, and kept consistent. What server is handling the IMs? How do you
present a unified interface to the user that can provide both? What if
they don't have the same control interfaces for programming these kinds
of services? This is very hard. The result - increased cost to the
service provider, increased time to deliver, resulting in a poorer user
experience.

So, from the grounds of service provider benefits *and* user experience
(the latter being something we all agreed was very important), how can
you argue that such convergence is bad and the wrong direction????

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com