Subject: [SIP] SIP] SIP feature services

From: "farhan" <[email-masked]>
Date: Sat, 2 Sep 2000 14:16:17 +0530

i guess this is a reprise of what i was trying to figure out somewhile ago
on this list ...

if an application server is capable of offering a service, it is agreed that
the proxies need have no understanding of the service beyong plain message
forwarding. accepted.

should a client UA be aware and have specially programmed features to make
use of the service being offered by a server? the answer SHOULD be No.
Ideally a service should be accesible from any SIP UA that has a few basic
capabilities built-in.

take your POTS phone for instance. the phone instrument is not aware of the
fact that  I am dialing the changed number service, listening to the
instructions, punching in the old number and hearing the changed number
being read out. this is all being done without the phone instrument being
aware of the application level interactivity.

i would expect the same sort of genralised interactivity to be possible
within the SIP framwork. i will therfore argue for a method that prompts and
accepts text input from the user (through the user agent) and another method
that will diplay simple text messages. This is  what MESSAGE does already
and we may possibly need something like a PROMPT method (displaying a prompt
and getting a user response). A poor man's equivalent of sip forms (aka HTML
forms).

Just like there are a lot of people building great applications over SMS
service, I expect that we will also build some great apps riding over
MESSAGE/PROMPT (or whatever the scheme is).

As Dr. Rosenberg pointed out on this list a couple of days ago, MESSAGE is
not restricted to just plain text. I can send URLs that point to HTML forms,
media streams (even another sip url!!!, hehe okay okay we are not
redirecting anything here...) and the works.

the interactivity paradigm using messages is dialog based (I dont mean the
dialog windows, but textual dialogs). People who have played MUD in their
younger days (or dotage) will remember what it was like.

- farhan

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 02 Sep 2000 21:57:46 -0400

> Ideally a service should be accesible from any SIP UA that has a few basic

I agree that many services should not require service specific
capabilities in the client. But, there are a few caveats:

1. certain services require explicit invocation, as opposed to being
invoked as side effects of other, normal processing. Classic example is
call hold. We need clients to explicitly have support for this (and
indeed its specified in sip).

2. you can also build services into phones if you like; the SIP
architecture is very good in this regard, in that certain services can
equally well live in either place.

> and getting a user response). A poor man's equivalent of sip forms (aka HTML

I agree that prompting for data is critical, but we already have a
fantastic way of doing it, through http/html forms. I see little need to
replicate this with a SIP specific version.

messaging (that is, displaying of content), can be done in many ways,
many of which don't even require the MESSAGE method.

-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: Hong Chen <[email-masked]>
Date: Tue, 05 Sep 2000 12:17:10 -0500

> the proxies need have no understanding of the service beyong plain message

True. But the forwarding trig condition and forward destination need to be
defined somewhere and sometime in the call.

> Ideally a service should be accesible from any SIP UA that has a few basic

With intelligent SIP phone, feature services should be distributed to both edge
intelligent devices and core AS.
The issue is how to invoke some core AS for some feature services and also it is
hard to define the trigs for these services.

> aware of the application level interactivity.

The key point here is feature service invocation, not the feature service
interaction.
Yes, "you are dialing changed number service" which invokes the change number
service by dialing a specific number!!!