Subject: RE: [SIP] SIP feature services

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Sep 2000 01:58:53 -0400

> -----Original Message-----
> From: Hong Chen [mailto:[email-masked]]
> Sent: Monday, September 18, 2000 5:22 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; 'Anders Kristensen';
> [email-masked]'
> Subject: Re: [SIP] SIP feature services
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> 
> > This question only makes sense in the context of directly 
> applying the
> > IN model for SIP applications. I think SIP and its 
> operation is sufficiently
> > different that this really doesn't make sense.
> >
> > In the SIP model, the AS is simply another SIP entity. This 
> means that it
> > gets
> > the initial INVITE, along with any other signaling in the 
> call (if it
> > record-routes).
> 
> Exact issue here, since the AS SIP address should be set in 
> the SIP URI of
> initial INVITE.
> Questions raised here are:
> who(UAC or SIP proxy) should set the AS SIP URI in INVITE 
> request ? and
> How to find the SIP address for an AS serving the feature?

First off, its not strictly necessary to actually set the request URI to
have a host part that points to the AS. A proxy or UA can send a request
with any request URI to the AS, and then it would perform its feature
processing. This is analagous in http where you can send a request to an
http proxy even though the request URI points to some other host. 

In fact, modifying the request URI is probably bad, since it likely contains
some useful information for feature processing.

As to whom should send a request to the AS - that depends on the
architecture of your network. How to find its address is a hard problem.
Right now, static configuration of rules and conditions is the only way.
Ideally, I'd like to have some way for application servers to propagate
information on their application invocation conditions to upstream proxies
or UAs. This way, I need only drop an application into an AS, and it would
take care of propagating the routing information so that it gets properly
invoked.

This kind of propagation is what I have referred to as "service routing". It
can be viewed as a multi-dimensional routing problem. The reason its
multi-dimensional is that the criteria for application invocation can be
quite varied. Its not just "request URI = foo"; it can be based on the From
field (for outgoing features, in general), To field, Request URI, and
components there in. For example, a departmental outgoing call screening
application might execute whenever a call with a From field domain of
cs.columbia.edu is found. 

Service execution might also depend on a subscriber list. For example, a
call forward no answer service might execute if the called party subscribes
to the service. In this case, the criteria for application invocation
depends on matching the user@host portion of the request URI against a
potentially long list of subscribers.

Not all of the criteria for service invocation need be propagated; perhaps
only the general criteria are propagated, and then the specifics are
verified at the AS itself. In fact, the verification might itself be part of
the application. For example, lets say columbia.edu has an call forward
service enabled for certain students in its CS department, depending on
their GPA (above 3.5, and they get the service). In this case, the
application might propagate the rule "INVITE request with request URI domain
cs.columbia.edu will trigger execution of CFNA at AS 3.4.5.6 port 5060".
When the call arrives at the AS, it will need to run and check the GPA of
the called party against the university database. If their GPA is too low,
the call is simply proxied without doing anything special.

-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: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Hong Chen <[email-masked]>
Date: Tue, 19 Sep 2000 11:43:42 -0500

> the call is simply proxied without doing anything special.

Thanks for response in such details!

First, I would like to generalize service routing criteria here and bring up
issue with it:
        Service routing criteria are combination of
        (1) SIP message contents.
            - Method of Request.
            - Request URI.
            - SIP message headers (especially TO, FROM and STATE headers).
        (2) Subscriber's profiles.
        (3) Time and / or date of the request.
        (4) Address of proxy or UA processing the request.
        (5) ...

        Issue: If there are more than one ASes satisfying the above combined
service routing criteria,
                  which AS should  be selected by the proxy or the UA to route
the request to?

        We may have several different solutions and please let me know which is
the proper SIP mechanism.
        (1)  SIP mechanism.
              Use "url-parameters" of SIP URL in the request URI to solve the
unique service routing problem and
              use "STATE" header to pass end point call state. Like:

                    INVITE sip:[email-masked];service=feature-i SIP/2.0
                    Via: SIP/2.0/UDP callerHost.com:5060
                    From: Alice<sip:[email-masked]>
                    To: Bob<sip:[email-masked]>
                    State:callerHost;state=initialCall

                Is it a proper SIP mechanism? If not, please explain why.

        (2) AS interactions.
              AS will interact to each other to solve the unique service
problem.
              We need to find a proper protocol for the purpose.

        (3) Do not need to do it at all!

Second, I like the idea of dynamic "service routing". But what protocol in your
mind could help us to do so, SIP or others?
              Plus we need to solve the conflicting problems introduced by more
than one ASes propagating
              conflict service routing criteria.