Subject: [SIP] Re: SIP feature services

From: "farhan" <[email-masked]>
Date: Sun, 3 Sep 2000 09:55:05 +0530

the only problem with using http/html forms for prompting and display is
that we will be making sip dependent upon another 'bag' - an html browser is
a pretty huge thing. it will also be difficult to implement one in all its
glory on the phone devices (witness the buzz/noise being made for WAP).
there are both sides to this issue.

1. it is a lazy sip programmers ideal solution to hand over
display/prompting to http. It is pretty flexible too. Integrating the
existing browsers like Internet Explorer into a UA is a child's play (you
just drop in an activex webbrowser control onto your UA's interface). It can
be trivially done in about 10 lines of code, calling the Navigate method of
webbrowser interface is all you have to do.  On the other hand, combining
javascript, dhtml, et all, it will be a total redefintion of all that
telephony is about and the way it integrates with web experience.

2. it will be a pretty drab alternative to use simple text to prompt users.
This maybe all that is required in 90% of the cases. We have used it very
effectively in our hotfoon.com experiment (this was before i became a sip
convert). Hotfoon, when started is just a dumb terminal that displays lines
of streaming text and accepts text inputs from a single edit box. The idea
was to have a user interface that can be used anywhere from Windows to Linux
to Palm to a small LCD display on a mobile phone.

The issue is therefore, do we make web browsing a complusory facility to be
available alongside a sip UA? Allowing it so will in make sip-ping a top
class experience. It will integrate web browsing, emailing and everthing
else into a unified experience.
example:
1. you need to talk to a sales person, you click on the sip url of the
browser and the sip ua starts up.
2. In order to connect you to the right person, the sip ua launches another
web browser window and display a form asking you for preferred language you
select Hindi.
3. the sip proxy redirects you now to a sip based call-center in bombay. the
phone rings in bombay it is 2 am. no one picks it up.
4. You time-out, the sip app server/proxy in turn suggests that you send
them a voice mail, simultaneously the voice mailer starts (your sip UA
spawned the browser with a voice mail request). Your recorded enquiry is now
dropped into your email UA.
An incredibly useful and 'silent' experience (the end-user is unaware of the
technicalities, she is just filling html forms and clicking on the chosen
alternatives).

All this said, I will still want a simpler alternative of plain text
prompting/display for the sake of those devices that cannot afford a web
browser.
1. sip is completely implementable with just a UDP stack (and a little bit
of ICMP thrown in). It will be nice to keep it that way. implementing UDP on
embedded systems is pretty easy. getting TCP going is resource intensive.
for http UDP is a must.
2. most of the time, the dialog between the user and the telephony service
provider is in short simple messages like "Do u want to leave a message?" or
"Welcome to Acme service center. Enter you model number:". These should be
possible without the need for a browser.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 04 Sep 2000 23:31:39 -0400

> there are both sides to this issue.

No one said an HTML renderer was needed. Nothing is wrong with
text/plain or application/wxml. Thats what our MIME headers are for:

INVITE sip:user@host SIP/2.0
Accept: text/plain, application/sdp

> display/prompting to http. 

Lazy is not the right word here. We have an extensive system for
transferrance of content, both simple and rich. I don't want to reinvent
that based on a notion of "greater simplicity through reinventing the
wheel". You can do a minimal http client stack very easily.

> available alongside a sip UA?

Compulsory? No. Thats the beauty here - we can figure out what type of
content the caller can support. With the Caller preferences extension to
SIP, we can even figure out what URL schemes they can be redirected to.
This allows applications to be built that deliver the rich content to
full blown PC phones, and do more limited stuff to more limited devices.

-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