Subject: Re: [SIP] SIP feature services

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 03:43:31 -0400

Hong Chen wrote:
> 
> Dear All:
> 
>     I would like to initial discussion on what the best
> systematic/consistent way to invoke network feature services by SIP
> signaling without
>     losing SIP advantages.

You mean what protocol would one use to talk to an application server
that provides SIP features? Thats easy - SIP.

-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

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

---

From: Hong Chen <[email-masked]>
Date: Fri, 01 Sep 2000 11:30:17 -0500

> that provides SIP features? Thats easy - SIP.

    I might ask some dump questions.

    My question is how to use SIP to request AS feature services
systematically and consistently, meaning:
        - Is there a systematic / consistent sip mechanism being used to
invoke AS for different feature services?
        - Is this mechanism well accepted for the interoperability
purpose?
        - Do we need to keep originating sip session same as the feature
service sip session?
        - Do we need to create feature call flows based on this well
accepted mechanism?
        - Can we keep the consistency between the different feature call
flows?

    For example, if we set service "feature-i" in Request-URI of INVITE
request to invoke an AS,
        - Where should "feature-i" be put in Request-URI?
                    "feature-i"@example or
user@example;"service"="feature-i"?
        - How do users know the name of "feature-i" and "service"?
        - Is there such pname "service" defined for such purpose?
        - Are there pvalue like "feature-i" defined and well accepted?

    By the way, can any one help to give a whole picture about XML and
SIP for feature services?

Hong C

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Sep 2000 20:21:32 +0200

> invoke AS for different feature services?

Yes, plain old SIP.

>         - Is this mechanism well accepted for the interoperability

Getting there.

>         - Do we need to keep originating sip session same as the feature

There is no separate "feature service SIP session". There is call setup
and subsequent end-to-end signaling, during which proxies and other
network elements are free to do whatever it takes to decide how to
handle requests that come their way.  No separate protocol is needed to
invoke service logic.

>         - Do we need to create feature call flows based on this well

I don't think so. It's all standard SIP; well, give or take the odd
extension, such as REFER and session timers. 

>         - Where should "feature-i" be put in Request-URI?

Request URIs won't (usually) contain info that identifies services to be
invoked. Maybe you subscribe to feature-i at some proxy -- it is then up
to that proxy to figure out to apply feature-i to your calls.

--
Anders Kristensen

---

From: Hong Chen <[email-masked]>
Date: Fri, 01 Sep 2000 13:53:46 -0500

Anders Kristensen wrote:

> >     I might ask some dumb questions.
> >

Yes, some services can be subscribed by users and can be trigged inside SIP
proxy.
But the issues are:
    - Do we need to define the trig points (for both originating and
terminating trigs) and their conditions in Proxy?
        This could be a design and implementation issue.
    - Further more, it may not possible to define and implement trigs for some
feature services.
        How can we handle these services by SIP?
    - How can we use SIP to implement user based and/or call based feature
services?

    Thanks,

Hong

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 03 Sep 2000 00:42:41 -0400

> terminating trigs) and their conditions in Proxy?

A trigger point is simply some kind of system event that is useful for
the purposes of doing something service related. SIP as a protocol
defines various state machines and messages, any of which might serve as
a useful trigger for doing something. I see no need for any additional
standardization.

>         How can we handle these services by SIP?

I cannot answer that without some examples or a more precise definition.

>     - How can we use SIP to implement user based and/or call based feature

Has that not been the discussion of this thread to date? As Anders has
pointed out, the services are encapsulated within the logic of proxies
and other SIP devices along the session establishment path. 

-Jonathan R.

---

From: Hong Chen <[email-masked]>
Date: Tue, 05 Sep 2000 11:48:01 -0500

> a useful trigger for doing something. I see no need for any additional

I agree that additional standardization may not be necessary, but  a standard call
model
for sip proxy may help for the feature developments and interpretability.

> >     - Further more, it may not be possible to define and implement trigs for
> some
> > feature services.

EX.. of features which need network controls and hard to define trigs in sip proxy.
(1) Call Park (Park a call and then pick the call later somewhere else).
(2) Call Pick Up (Answer a call which is ringing somewhere else in a call pick up
group).
(3) Adhoc conference using centralized conference bridge.
 and more.

Thanks,

---

From: Hong Chen <[email-masked]>
Date: Tue, 05 Sep 2000 12:32:39 -0500

Henning Schulzrinne wrote:

> Attempts at a call model have been made by various people. See the draft
> archives. Whether they are useful is another question.
>
> >
> These services were discussed extensively on this list a number of weeks
> ago (see the list archives), with different solutions proposed, since it
> doesn't make sense to translate the behavior exactly from PSTN to IP.
> Conferencing is also addressed in the SIP FAQ and requires no SIP proxy.
>

(1) It may not make sense to translate the behavior exactly from PSTN to IP, but people
are still looking for
those traditional services.

(2) The key point here is:
        There may be hundred suggested different ways for some service by SIP signaling.
        The question is which is the best systematic mechanism we should follow and we
can also easily
        use this same systematic mechanism for any new feature service later.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 05 Sep 2000 12:55:29 -0400

---

From: "Rajeev Gupta" <[email-masked]>
Date: Wed, 6 Sep 2000 13:03:07 -0700

How do you indicate the occurence of a mid-call trigger (such as for call
waiting) from a SIP proxy (which could be running in a softswitch) to an
application server (which contains logic on how to handle the feature for
this specific subscriber, and may be running on another SCP-like node)? This
is a transaction-type messaging between SIP proxy and application server,
which is not necessarily in the context of a SIP session setup between the
two.

Rajeev Gupta
empowerTel Networks
475 Sycamore Drive, Milpitas, CA 95035
Phone: +1 408 519 7136
Fax: +1 408 519 7420
mailto:[email-masked]
http://www.empowertel.com

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Hong Chen
Sent: Tuesday, September 05, 2000 9:48 AM
To: Jonathan Rosenberg
Cc: Anders Kristensen; [email-masked]
Subject: Re: [SIP] SIP feature services

> a useful trigger for doing something. I see no need for any additional

I agree that additional standardization may not be necessary, but  a
standard call
model
for sip proxy may help for the feature developments and interpretability.

> I cannot answer that without some examples or a more precise definition.

EX.. of features which need network controls and hard to define trigs in sip
proxy.
(1) Call Park (Park a call and then pick the call later somewhere else).
(2) Call Pick Up (Answer a call which is ringing somewhere else in a call
pick up
group).
(3) Adhoc conference using centralized conference bridge.
 and more.

Thanks,

---

From: Hong Chen <[email-masked]>
Date: Fri, 08 Sep 2000 10:10:56 -0500

> which is not necessarily in the context of a SIP session setup between the

I think the type of services above can be served in SIP proxy / AS by well
defined triggers.
The feature services I would like to discuss here are those services that need
network side control and
it is very hard to define triggers in SIP proxy for them.

Thanks,

Henry