Subject: Re: Capability-based routing in SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jan 1999 01:27:32 -0500

Dean Willis wrote:

> I could perhaps work around this problem by defining a different
> username for each device, associating capabilities with usernames in my
> ULS configuration, but this seems rather a complex kludge.
> 
> To summarize the issues:
> 
> 1) Capability-based routing seems to require parsing the SDP to decide
> what the session type is. This is problematic for fast setups.

Not really. Parsing SDP is pretty fast when you don't need everything;
just quickly read through the lines until you find the m= lines, and
look for fax, audio, video, or whatever.

> Am I missing something obvious here, or do we really need a richer
> capability description and handling mechanism to handle these scenarios?

This is an excellent point, Dean. The right way to handle this becomes
clearer when you extend the requirements a bit more. What you are asking
for is that a user should be able to direct the call routing of a proxy.
In this case, its based on the SDP in the INVITE. More generally, it
might be based on time of day, caller, subject, method, etc. SO, how do
we devise a means for allowing a user to instruct a SIP server on call
routing? The answer is the call processing language in iptel! It is for
exactly this purpose. I think what you have come up with is another
requirement as input for the language:

<switch index="media">
  <case value="fax">
    <proxy dest="sip:[email-masked]"/>
  </case>

  <case value="video">
    <proxy dest="sip:[email-masked]"/>
  </case>

</switch>

You would then upload the CPL to the server in the REGISTER message.

Conceivably, a REGISTER message could contain SDP, in which case the
registrar would interpret it as a capabilities description for call
routing. Its messy, but it works and this is what pint is doing. It
quickly breaks down when you want to add other routing logic, in which
case the CPL is clearly a better choice.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Jan 1999 11:13:39 -0600

Jonathan Rosenberg wrote
> > capability description and handling mechanism to handle
. . .
> requirement as input for the language (CPL):
>
> <switch index="media">
>   <case value="fax">

A very thought provoking suggestion, Jonathan.

Adding the media type to the CPL certainly enables user-controlled media
routing and sounds like a reasonable way to handle it. Of course, my
server developer friends here don't like the idea of having to interpret
code to route a call -- they think in fairly large scales -- but the
basic idea is sound. They have decided that parsing the SDP is probably
required and are willing to think about it.

However, uploading the CPL in the REGISTER doesn't sound reasonable --
that would seem to require every dynamic device to know enough of the
state of other dynamic devices to be able to construct a full CPL. This
is clearly intractable in larger scenarios.

We rather envision the ULS call routing setup being managed from a user
interface -- Web and/or IVR, and letting SIP endpoints have a more
"incremental" impact on routing.

It might be more effective to have the CPL (or other mechanism) direct
the sessions to a "class" of endpoints based on capability, perhaps with
some sort of priority weighting within the class (q?). Then an endpoint
would simply need to include enough information in a REGISTER that the
ULS could add the endpoint to the correct class with an appropriate
priority. One could build the class as a priority-ordered list of URIs,
which would be useful for both sequential redirects and forking proxies.

I believe one could implement the scenarios I had in mind with this sort
of arrangement.

The trick, though, becomes defining the set of classes, and specifying
the REGISTER mechanism for class membership. I think I wish I could do
it all in the Contact header of the REGISTER. Perhaps there is some meat
to Dan Wing's suggestion that the CONNEG WG's work will help here --
guess I need to go read it ;-).

On a related note -- I'm thinking that some of this behaviour collides
with the current draft (sec 4.2.6), which states that the REGISTERS's
URI is compared to existing registrations, and replaces equivalent
current registrations subject to values of q and ttl. Oddly enough, the
behavior for a REGISTER of equivalent URI with matching q and ttl seems
undefined. The real problem here is that a registration for class FAX
would collide with (and replace) a registration for class VOICE if the q
and ttls matched . . .

--
Dean

---------

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Jan 1999 20:20:44 -0500

Jonathan Rosenberg wrote:

> You would then upload the CPL to the server in the REGISTER message.

Or it would be generated automatically by the cgi script or servlet
running on the customer configuration web server. It remains to be
discussed whether CPL scripts can be generated incrementally, so that
one could just upload a "media subroutine".

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Jan 1999 02:08:16 -0500

> required and are willing to think about it.

You don't neccesarily need to interpret the code to route the call.
Thats an implementation decision. An optimizied implementation might
"compile" it in some fashion or otherwise store it locally in a more
optimized form. There are ways to even push the CPL processing into
separate boxes from the SIP processing and proxying box. iptel is not
going to standardize such interfaces right now, but its not such a
stretch to see how SIP CGI or even an IN call-model/INAP solution could
work there.

> is clearly intractable in larger scenarios.

I have been thinking about this also, in fact, and came to the same
conclusion. The fundamental problem is that the SIP REGISTER message, as
currently specified, is a *terminal* registration function (i.e., it
specifies call routing state for just a terminal), while the CPL
specifies a *user* registration function, potentially encapsulating many
terminals. I came up with several scenarios where the wrong thing
happens, forgetting even the scaling and communications issues:

I'm at home, and upload a CPL in a REGISTER that says to try me at home
then work. I then go to work, and leave the PC at home on. At work, I
send a CPL which says try me at work then home. Now, since REGISTER's
are retransmitted periodically (before they expire), the call routing
logic will oscillate between home-then-work and work-then-home as my
home and work PC's both continue to refresh the registration.

This begs an important question - should a CPL be "soft-state" and
eventually expire? A SIP REGISTER certainly should; a terminal may be
turned off and thus no longer be available. But, the CPL isn't really
representing a terminal, they are my preferences. The expiration of
these preferences doesn't really seem tied to terminal on/off status.
They may expire since the service provider may want to flush out really
old stuff. But, the timescales here seem very different - weeks probably
for a CPL timeout, if it times out at all.

> "incremental" impact on routing.

As Henning pointed out, the web/IVR could then generate the CPL and then
send it. The advantage of using the CPL in the back-end is that it
provides a consistent interface for the call routing logic. Whether the
logic is generated by a web form, IVR system, or written by a user, its
all the same. It also supports cross-vendor compatibility for these
services.

> which would be useful for both sequential redirects and forking proxies.

I think what you mean is something like this:

<condition day="monday">

   <match>
      <proxy dest=phone>
   </match>

   <nomatch>
      <proxy dest=home-pc>
   </nomatch>

</condition>

Then, a SIP REGISTER from my home PC would effectively bind the "class"
home to the URL in the COntact of the register. Is that what you mean?

> guess I need to go read it ;-).

Hmm. Your suggestion is a neat idea, but it changes the way REGISTER
works. I don't think you need to do it quite this way. How about this:

1. The CPL is like it is now, and forwards to URI's (like
sip:[email-masked]). 
2. When a server decides to forward a call to sip:[email-masked],
it can either (1) attempt to look up the domain name and locate a server
there, or (2) try to translate sip:[email-masked] using
information learned from REGISTER's or any other locator service (really
REGISTER is a way of building up a location service DB). THe CPL could
specify which.

I think this solves your problem. An example will help. My CPL is:

<condition day="monday">
  <match>
    <proxy dest="sip:[email-masked] uls="register">
  </match>

  <nomatch>
    <proxy dest="sip:[email-masked]">
  </nomatch>
</condition>

This could be uploaded in a REGISTER, but the semantics of it (in terms
of updating Contact headers, etc) would be different due to the presence
of the body.

What this says is that when its Monday, I proxy the call to
sip:[email-masked], but before I do, I try to translate this
URL using the REGISTER locator service. Now, I'll need to configure my
PC at home to send a SIP REGISTER message that looks like:

REGISTER sip:bell-labs.com SIP/2.0
To: sip:[email-masked]
From: sip:[email-masked]
Contact: sip:[email-masked]

So, the REGISTER message binds the URL sip:[email-masked] to
the current address of my home PC. Basically, instead of defining new
classes, we use different SIP addresses as different classes.

No solution is perfect; this one might be harder to configure and be
less intuitive. Also, it sort of distorts the meaning of the SIP URI in
a way that makes me a bit queasy (home.bell-labs.com is a completely
invalid domain name and only exists as an intermediate address) But, it
maintains the current REGISTER semantics since they are what they are. 

I'm open to other suggestions, of course. These issues are critical for
the CPL framework document, since that will need to discuss
transport/interaction issues and its interaction with signaling
protocols like SIP and H.323.
 
> would collide with (and replace) a registration for class VOICE if the q

You won't have this problem with my solution above since the URL's look
different.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 08 Jan 1999 18:07:39 -0500

This raises, I believe, a possible requirement/feature for the CPL:

It should be possible to proxy calls based on the current list of
registrations matching a certain feature. The call control spec, for
example, defines the 'class' and 'media' tags for describing SIP
locations. Thus, a request like

'proxy class=business'

would proxy an incoming call to all registrations that are registered
under that class. Same for the media type; this would avoid parsing the
SDP and be more uniform. Note that the feature negotiation work (see
recent IETF last call) may be applicable here, as the simple model above
can't really express things like:

'proxy to all my registrations that are of class business and support
video or audio'

Note that this is different from conditioning actions on the call
itself, as currently described.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
---------
This message came from the IETF IPTEL Working Group Mailing List.