Subject: [Sipping] "Services"

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 23 Mar 2006 10:56:25 -0500

I think there is a real technical issue buried in this.

I see nothing contrary to the SIP philosophy in having a (service
provider's) proxy decide where to route a request based on the
facilities that the proposed operation will need.

The PSTN approach is to categorize requests into a small number of well-
defined "services", tag the requests accordingly, and route based on the
tag.  Given that there are a lot of systems that already depend on this
categorization, I see no reason not to tag requests to/from such systems
based on the PSTN service identifiers.

But as a broader solution, it has serious problems with extensibility.

It seems to me to be only slightly more complicated to have such a
"routing proxy" examine the SDP, the Allow-* headers, Supported,
Require, etc. and route a request based on the fit between the requested
facilities and the facilities provided by the various "application
servers".  This also allows some features that are desirable from a
technical and a business point of view -- a request that cannot be fully
satisfied can be routed to the "best fit" application server, new and
complex services can be deployed without having total agreement between
all service providers, a service provider can have two application
servers for one "service" (partitioning the requests based on *its*
policies), etc.

The technical issue is that it must be possible to categorize a proposed
dialog based on its initiating request, rather than using a
"negotiating" approach requiring exchanging several messages before the
real needs and capabilities of the requester are revealed.  (Unless we
create some way that the routing proxy can be the terminus of the dialog
for the "negotiation" transactions, and then seamlessly hand off the
role of terminus to the real terminating UA.)

Of course, such a "routing proxy" could be used to implement billing or
other policies that would duplicate some of the unfortunate aspects of
the PSTN infrastructure.  But a SIP service provider can do that
*already*; by considering this problem, we aren't making the situation
worse.

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Mar 2006 11:22:09 -0500

> facilities that the proposed operation will need.

I agree that this is a reasonable thing to do in some cases.

It is however restrictive in that it puts a damper on the kinds of 
things that can be done, because it requires all resources and services 
that will be required to be determined at call establishment time.

(One upon a time, before many of you were born, operating systems 
required that all the resources required to run a program be declared at 
program start time. That includes memory, files, amount of cpu time, 
peripherals, etc. It wasn't conducive to writing flexible and easy to 
use programs. We were all happy to see that day go.)

For instance, I might start by establishing an IM session with you. In 
the middle of the session we might decide it would be good to use PTT to 
help go faster. But oops - the PTT application required that it be 
inserted in the signaling path at session establishment time. Maybe this 
is inescapable due to current implementation constraints, but that 
doesn't mean we should adopt it as a design principle.

> based on the PSTN service identifiers.

I know of at least two organizations that are currently defining how to 
do PSTN services using SIP. They don't agree on the set of services to 
be included, the PSTN definitions of those services, or the sip 
implementations of those services. So inserting "PSTN service 
identifiers" into the requests is unlikely to facilitate 
interoperability. Full interop of every aspect of these services is 
likely to be unachievable. (It isn't achieved in the PSTN either.) But 
interoperability on the basics seems likely to be better if we ignore 
names and just try to get the primitives to interop.

> servers for one "service" (partitioning the requests based on *its*

Yup. That is what I am talking about.

> real needs and capabilities of the requester are revealed. 

I think the key here is to recognize that this is problematic, and to be 
avoided whenever possible, rather than being gratuitously used as a 
design principle.

	Paul

> (Unless we

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 23 Mar 2006 20:30:33 -0500

> names and just try to get the primitives to interop.

This seems to parallel what Jonathan was saying earlier (though I
haven't read the reference he points us to yet).  Andrew Allen (?) seems
to say as much, even while arguing for "service identifiers".  Even from
an "a priori" point of view, one would expect that a small enumeration
of services would not segment and cover an application space as broad as
SIP's without having interoperability problems, as well as being a
straitjacket.

Dale

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 23 Mar 2006 20:38:14 -0500

> use programs. We were all happy to see that day go.)

I still like CLIs.  I wonder if it's an infantile throwback to decks of
cards?  In any case you'll be pleased to know that someone has
implemented jclsh.

> doesn't mean we should adopt it as a design principle.

Let us try to turn the problem around -- Assuming that INVITEs are being
demultiplexed to various "application servers" based on the needed
capabilities, is there a nice SIP way for the demux proxy to transfer a
dialog from one application server to another when a re-INVITE comes
through?  Clearly, a full B2BUA can do it, but that's heavyweight.
Given that this sort of problem is the practical reality for a lot of
the telecom infrastructure, can we be clever and have SIP accommodate
this sort of architecture in a standard-compliant and fairly transparent
way?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Mar 2006 10:03:23 -0500

> this sort of architecture in a standard-compliant and fairly transparent

One way is to do an INVITE/Replaces to establish an entirely new 
session. Not entirely appealing, but possible.

The problem would be a lot simpler if the UAs were responsible for 
requesting the involvement of any servers that are needed.

	Paul