Subject: [SIP] syntax .. a clarification

From: "farhan" <[email-masked]>
Date: Tue, 29 Aug 2000 00:55:42 +0530

rosenberg wrote -

>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?

we cannot trash the INVITE method because the INVITE is a three way
handshake (much like the TCP) that is essential for a complete, reliable
session intiation as opposed to MESSAGE which doesnt require any further
handshake from the other side. Nor can we trash BYE and CANCEL. They all
have different effects on the sip stack's state itself. While MESSAGE,
NOTIFY, SUBSCRIBE, etc. have essential the same effect.

>Proxies are supposed to forward method independent. Ours does. Any proxy
>that doesn't is defective and you should send it back.

A proxy has to be aware of the nature of the method. An INVITE will fork, an
ACK will not. A single NOTIFY to a proxy can be forwarded to multiple
SUBSCRIBErs, an MESSAGE is unicasted. Thus, each method needs its own
special processing (if the proxy is anything over a trivial implementation).

maybe i haven't been able to articulate myself well enough, what i am saying
it that we should try building over and outside the sip stack instead of
building it within.

i am essentially asking for a freeze on the number of request methods. this
is important to keep the stack size down and managable. the example of using
MESSAGE to querying for presence wasn't correct. Let me give a better
example:

"A service on the net wherein you can make a sip call, enter your PIN and
listen to any updates on your stock portfolio on your computer."

This can be accomplished using Authorisation schemes to login to the stock
quotes server (because the UAS will challenge the UAC), then the UAS sends a
MESSAGE to UAC asking for the PIN. On receiving the PIN, in another message,
the UAS starts streaming the stock market commentary to the UAC.

What I am arguing is that the sipstack itself does not need to be aware of
the nature of service it is being used for. It is easy to build this service
such that it doesn't need a specialised UAC either. That is extremely
important. If you look at the issue from an end-user perspective, a single
universal client should be able to handle all types of realtime session
services through a simple common protocol. I can't imagine that being
anything other than SIP.

When we do speak of a general purpose user agent, then it should have a well
defined number of methods that can handle a large amount innovative services
developed over the SIP stack. If we insist that different users download a
whole lot of different versions of SIP UACs for different applications, it
will be like having a different web browser for every site.

Thus, I am arguing that a web browser is not aware of how google.com works.
similarly, a SIP UAC need not be bothered about what the UAS is all about.

Although it is not directly related to SIP in itself, there is an  issue of
the presentation layer too: It is an important goal that through a generic
UAC much like the email UAC, we are able to initiate any multimedia session
that the user is capable of handling (has the codecs, bandwidth and
processing power). For this, it is essential that a UAC understands and
implements the SIP protocol largley and not minimally.

the application level intelligence for SIP sessions should be handled
between the user agents themselves.

on a personal note, I am trying to develop very small footprint SIP stacks.
It is also important for developers like me and biggs that the sip stack be
prevented from growing so big that we will realistically miss out on large
chunks of functionality. the large size of vovida stack is an indicator of
the way implementations are going.
By keeping the SIP stack small, I am not saying that we will put it on pin
heads! we will be able to spread it to more desktops faster (I can send you
a small sip client in email!) or make it downloadable on the web within
seconds. These are important goals for fast, viral spread of SIP. They also
need a small, compact and functionaly complete SIP stack that doesn't have
to be upgraded (I can't change my ipphones as often as I can change my
browsers). SIP stack is going to a lot of inaccessible places that may not
be upgradable. SIP stack is also going to places that need exteremly
reliable performance (like wireless ip telephony base stations) - it will be
very expensive to re-implement and test and re-deploy newer and ever
expanding versions of SIP.

- farhan
hotfoon.com

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 29 Aug 2000 00:11:31 -0400

> NOTIFY, SUBSCRIBE, etc. have essential the same effect.

Well, that depends on what you wish to call "the stack". According to
the IM and presence drafts, a very specific set of processing is defined
for SUBSCRIBE and I promise you it is not the same as the processing of
MESSAGE. Are these above the baseline rfc2543 processing definitions?
Yes. But, that does not mean they should all be funneled in one method.

Lets put it in software terms. Lets say I have an API to some library,
and this library has callbacks. We have two events, foo and bar, which
pass some data. You could define the API in two ways:

public interface callback {
  public void foo(int data);
  public void bar(int data);
}

OR

public interface callback {
  public void event(int data, boolean isFoo);
}

now, you need the SAME AMOUNT OF CODE either way to demuliplex; the
question is: where is the right place for it? Should we combine logic
with data, or keep them separate? Good programming style, IMHO, would
argue for keeping them separate and defining functions that are explicit
in what they do. This speaks to the first interface above, not the
second, which quickly becomes a programming nightmare as the set of
events increases.

The parallel in SIP is obvious; method is a method in the programming
sense of the word - it defines a very concrete operation to be performed
on the server (not the stack); all the data in the message merely
qualifies that operation, it does not define it.

> special processing (if the proxy is anything over a trivial implementation).

You are incorrect. INVITE has a well-defined semantic, as do ACK and
CANCEL. Everything else (in terms of proxy processing) is the same as
OPTIONS. That includes BYE, SUBSCRIBE, NOTIFY, etc. 

> it that we should try building over and outside the sip stack instead of

We should build well defined but general purpose operations into SIP
(like REFER) which can be used to build many services. No disagreement
there. But that is NOT the same thing as simply reusing a method instead
of defining a new, when the semantics are not the same. It is hard to
write code for SIP if the basic processing of a method depends on
umpteen different headers and bodies.

> the UAS starts streaming the stock market commentary to the UAC.

Slightly better is that the MESSAGE contains an http url for a form for
entering the PIN. Doing so is a perfectly good thing to do.

> services through a simple common protocol. I can't imagine that being

I'm not disagreing with this. I'm disagreeing with assuming that by
placing a completely new function within an existing method, that
*shazam* - its for free!

> will be like having a different web browser for every site.

I agree here too.

> browsers). 

Why? I actually know of phones that can fetch a new image when one is
available without any human interaction at all. I'm not arguing that as
an excuse for a fat stack, mind you, but I don't see why upgrading an ip
phone is different than a browser. Probably easier since the IP phone is
way thinner than a browser.

-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