Subject: [SIP] syntax & edges vs. centers

From: "farhan" <[email-masked]>
Date: Tue, 29 Aug 2000 19:12:01 +0530

i have lost an earlier draft of my posting. maybe it never got posted.
anyway, here it goes again:

dr. rosenberg wrote -

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

this is absolutely the way to go. one method ought to do just one thing
completely. i am completely convinced that each method ought to do just one
thing. we cannot have another ioctl() horror on the sip stack.

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

If SUBSCRIBE, NOTIFY, MESSAGE, BYE are all the same, evidently their
interpretation is completely between the user agents themselves. In that
sense they are a recommendation of how SIP can be applied to add more
functionality. Much like SIP is encapsulated in UDP, we are encapsulating
more methods within the SIP architecture. To that extent, the interpretation
of SUBSCRIBE, NOTIFY, MESSAGE, etc. is  the problem of the recepient of the
requests.

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

one simple way to upgrade an ip phone is by rom replacement. online
upgrading has its own interesting possiblities. someone with a rogue
bluetooth on his palm can just walk around an office and download a trick
stack into all the ipphones (maybe this is just science fiction). But the
very interesting possiblities that it _does_ open up is that if we can
incorporate downloading of  'siplets' to SIP devices that run like applets
in secure sandboxes, we can come up with some pretty interesting
applications.

i imagine that such ip phones will also need a mechanism to download and
invoke method handlers. possibly a siplet specification in the body of the r
equest? if so, do we give provisional responses until the download is
complete ? what are the security managment issues involved with siplets?
this is an exciting possiblity. shall we try implementing something like on
a desktop UA that can download the request handlers.

the other approach will be to dish out everything from some sort of a
telephony application server that manages a number of sip phones (a proxy).
the added services are all build on the proxy server side. this keeps the
UAs themselves fixed and small. this is an approach that we took when we
designed hotfoon.com.

hotfoon.com - dumb VoiP terminals

hotfoon.com used a very simplistic protocol that transfered what ever a user
type to the server (raw) and whatever the server dished out directly to a
display window on the UA. Apart from the text messaging, just a single
call-setup/cleardown message pair was used to implement the session
initiation protocol. All the logic, including the call state was maintained
on the server side. the huge advantage was that it required virtually no
upgrades at all (the client is just a 48kb download including gsm codec). we
added features as the users demanded them. Someone asked for queues and we
implemented them, some asked for chat, we gave it to them. The idea was that
a simple VoiP client could be scaled up with innumerable features without
having to upgrade the clients themselves. Like all simplistic
implementations, it suffered on account of scalability (the servers were
stateful and had to deal with a lot  of concurrency issues). Nevertheless,
it still does handle hundreds of active users.

The idea explored in hotfoon.com was to implement dumb voip terminals,
wherein the intelligence was centralised (as different from sip where the
intelligence is towards the edge) in moderately powered telephony
application servers. it is still an interesting thing to toy around with.

- farhan

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

---

From: "Michael O'Doherty" <[email-masked]>
Date: Tue, 29 Aug 2000 16:13:03 +0100

Farhan,

I think that much of the type of functionality you are suggesting for
'siplets' might actually be provided by the SIP Servlet API:

http://www-uk.hpl.hp.com/people/ak/sip/servlet/

Although the name might suggest that these apply only to SIP Servers, in
fact they are applicable to any SIP client and so can be used to install and
upgrade SIP clients in terminals just as you have mentioned.  See :

http://search.ietf.org/internet-drafts/draft-odoherty-sip-servlet-delivery-0
0.txt 

Cheers,

Mick.

-----Original Message-----
From: farhan [mailto:[email-masked]]
Sent: 29 August 2000 14:42
To: sip
Subject: [SIP] syntax & edges vs. centers

dr. rosenberg wrote -

- farhan