Subject: [SIP] value added services on SIP

From: "farhan" <[email-masked]>
Date: Sun, 27 Aug 2000 00:33:49 +0530

imho when we discuss sip extensions, it is the classical case of inheritance
vs. encapsulation. do we extend sip with more request types rather than
reuse the existing ones?

let me stick my neck out and say this ... protocols that were endlessly
extended have never succeeded. look at tcp/ip, how many different types of
headers does it have? (is it three or four?). how many types of requests
does HTTP have? do they have different requests for different types of
services and web-sites? Did we have to change the email protocol to create
the web based email? (SMTP remained SMTP all along, and will do so for a
long time to come).

I guess that when we talk of extending a protocol, we should first examine,
if it is not possible to implement the functionality within the existing
mechanisms.
I would like to see services being build on top of sip rather than within.
For instance, MESSAGE can be used (in comibination with authenication
schemes already in place) for online payments. A session of MESSAGE
exchanges should be terminable with a BYE.
If a MESSAGE no with body can be used to query presence, use it.

I guess that we are talking of a lot many things that one would like to see
being implemented and this list will never end. We need a protocol that is
small and flexible and not one which will spawn such a large variety of
variations that it willl become impossible to implement it all in a
reasonable space. (The voida stack requires 256 MB of memory to compile. I
will have to wait for that venture cap funding to arrive before I can afford
to compile it).

The issue of optimal implementation is not as important as simplicity. many
of the issues that we are engaging in may not be a very big deal in the
coming times.
for instance, authentication. the best authentication of an incoming call
is, ofcourse, the caller's voice recognition and not the digital id. (how
many digital ids will i feed into my
sip-mobile-phone-cum-palm-electric-shaver?)
i also believe that internet realtime sessions will evolve and spread just
like email did about 7-8 years ago. the calling costs will drop to zero. it
is only a bandwidth issue from here onwards. therefore, payments,
authentications will be as useful as they are for email users and email
service providers.

this brings me to a fairly controversial subject (of endless debate with my
colleagues in 'suits') that there will be as much money to be made in
internet telephony as there is in email. there will be money mostly ip
telephony hardware. not much in software.

- farhan

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 26 Aug 2000 15:24:46 -0400

> the web based email? (SMTP remained SMTP all along, and will do so for a

As a matter of fact, all of these protocols have seen a number of
extensions over the years. HTTP, for example, in WebDAV, SMTP in the
ESMTP verbs and TCP in various TCP option extensions. The mechanism
differs, but the idea is the same.

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

---

From: "James A. Donald" <[email-masked]>
Date: Sun, 27 Aug 2000 09:27:31 -0700

--
I am a confused newbie, and I want to understand the relationship between 
the contemplated SIP standard, and the contemplated IMPP standard.

IMPP seems to do the same thing as SIP.  If you want to send an instant 
message, make a phone call, send a video message, hold a video 
conversation, you log on to Microsoft's PP server using Microsoft's PP 
client and do it.

I get the impression that both standards are having some difficulty in 
becoming standard:

To me in my ignorance it seems that SIP has 101 contemplated extensions to 
do anything whatsoever in any way related to communication, whereas the 
IMPP standard appears to be entirely ignored by the people that are 
actually implementing IMPP.  SIP seems like the early Somalian peace 
conference, where they wound up agreeing to disagree, and IMPP seems like 
the later Somalian peace conference, where they agreed on a government for 
Somalia, but the government was unable to get into Somalia.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      89C+uX6ZM7sgIkui1t/fvXgy0lzC8YJMcGXu8e2v
      4S7OAPZWSe7WGITZiErwj5PcxLEne1MoGalEo8wAN

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 27 Aug 2000 11:53:12 -0500

>IMPP seems to do the same thing as SIP.
This is very true. On the SIP infrastructure (server and
gateways), no extra work is required to support IM. The
advantages of integration go however beyond using the common
communications infrastructure, new applications, instant
communications become possible.

Thanks, Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
USA

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of
>James A. Donald
>Sent: Sunday, August 27, 2000 11:28 AM
>To: [email-masked]
>Subject: [SIP] The big picture?
>
>
>     --

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Aug 2000 22:30:25 -0400

I agree with you 100% on this one. I have been preaching the above truth
for years now.

> do anything whatsoever in any way related to communication, 

No doubt there are a lot; we (and myself in particular) are actively
trying to curtail the amount of random extensions being proposed. But,
fact is that interactive communications is a hard problem, and theres
lots of stuff that needs to be done.

SIP itself is a standard (rfc2543), and the baseline spec is widely
implemented and supported by service providers and vendors.

> whereas the
> actually implementing IMPP.

Well, the problem is that there is no IMPP standard. Nearly every
service provider and IM and presence software manufacturer has said they
will support the IMPP working group's protocol when it materializes.
However, the lack of progress and consensus within this group have
caused many to go down other routes (IMUnified).

>  SIP seems like the early Somalian peace

Err, no. IMPP the working group has undoubtedly agreed to disagree (in
fact, this is formally codified in an Internet Draft). The SIP working
group generally agrees and there is consensus; there is just a ton of
stuff being proposed. Not sure what peace conference to equate that to.

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Aug 2000 22:39:06 -0400

> If a MESSAGE no with body can be used to query presence, use it.

You are confusing protocol syntax with semantics. You are arguing to
reuse syntax to express NEW semantics. MESSAGE right now doesn't make
online payments, nor does it query presence or turn on the toaster. You
have just as much work to do to get sip to do online payments if you use
a new method or "reuse" an old one.

-Jonathan R.

---

From: Stan Moyer <[email-masked]>
Date: Mon, 28 Aug 2000 15:32:36 -0400

Jonathan,

At 01:25 PM 8/28/2000 -0400, Jonathan Rosenberg wrote:
>Stan Moyer wrote:
> >
> > At 10:39 PM 8/27/2000 -0400, Jonathan Rosenberg wrote:
> > Do you mean protocol semantics or application semantics? Because I do
> > believe that the application semantics are different, but at the protocol
> > level there is essentially no difference in semantics of MESSAGE for
> > Instant Messaging or MESSAGE for online payments (or turning on a toaster)
> > -- you're just sending a "payment" message to an application instead of a
> > text message to a human user.
>
>As I have stated countless times now, I strongly disagree. I really
>didn't want to make this an open invitation to reopen this debate, but,
>since you insist...

At this point we should probably agree to disagree.

>Clearly, MESSAGE was a bad method name to use. MESSAGE does not mean
>message in the RPC sense. It does not mean "take this and pass it up to
>the application layer for processing". The protocol semantics of MESSAGE
>are very clear and very simple: render this content for the purposes of
>display to some user or their agent as part of a text based interactive
>conversation. That is simply not the same as make an online transaction.

We'll just have to disagree on this point (especially on the importance of 
a human user participating -- I believe most applications are "agents" for 
users).

>Let me put it this way - do you argue we should ditch INVITE? Isn't that
>just a message to the other side with some content that describes a
>session? Are you proposing we deprecate INVITE and use MESSAGE for that
>too?

No I'm not!!

> >
> > Also, I think it is less work to re-use an old method than to create a new
> > one.
>
>Oh?
>
> > If you re-use an existing method you can use existing SIP Proxies and
> > UA stacks you only need to modify the application(s) to handle different
> > payload types.
>
>Wrong.
>
>Proxies are supposed to forward method independent. Ours does. Any proxy
>that doesn't is defective and you should send it back.

Then I think we'll be sending a lot back :-)

>As for UA stacks, they should also have a means to support unknown
>methods. Ours does; you can register handlers for any method name. Same
>reason a stack should support unknown body types. Why is it more likely
>one is supported as opposed to the other?

I agree that they should have means for supporting unknown methods, but I 
don't think I can count on all implementations being as good as yours.

In the context of SIP for Appliances I would enjoy setting up a meeting 
with you and other interested parties to discuss the best way to use SIP 
(e.g., new methods or re-use of existing methods -- though I know your 
position on that, but I'm sure there are other issues).

-Stan

---

From: Stan Moyer <[email-masked]>
Date: Mon, 28 Aug 2000 11:55:18 -0400

Also, I think it is less work to re-use an old method than to create a new 
one. If you re-use an existing method you can use existing SIP Proxies and 
UA stacks you only need to modify the application(s) to handle different 
payload types.

Stan Moyer
Director, Internet Services Infrastructure Research
<[email-masked]>; Telcordia Technologies,
MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438
voice: +1 973 829 4923; fax: +1 973 829 5889
http://www.argreenhouse.com/bios/stanm/

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 28 Aug 2000 13:25:55 -0400

Oh?

Wrong.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 29 Aug 2000 03:49:28 -0400

> UA stacks you only need to modify the application(s) to handle different

This is not exactly true. Any new method is completely transparent to
proxies; proxies don't need to "support" MESSAGE, INFO or
YOUR-PERSONAL-METHOD. Good UA libraries should allow sending new
non-INVITE methods - after all, beyond the method name, they are all the
same in terms of lower-level support such as reliability or associating
requests and responses.