Subject: [Sipping] Clearing the pipeline in re service identification

From: [email-masked]
Date: Mon, 19 Mar 2007 22:43:12 -0500

I've finally caught up on the thread about service identification.
There's a lot of different points.  I've tried to put my observations
into logical order.  Thanks to all of you from whom I've stolen my
opinions!

* "Service identification" as an architectural decision

The difficult point of "service identification" is not exactly how to
indicate it, but whether or not it should be embraced as an
*architectural* decision.  Discussing the latter point leads into
philosophical swamps, but the life and death of technologies hinges on
correct architectural decisions, because bad ones can leave a
technology irremediably crippled.

To put it as sharply as possible, in hopes that everyone will
understand the fundamental point of debate:

    Agree or disagree:
    The *concept* of a "service" considered harmful.

In this case, the bell-heads like service identification and the
net-heads don't.  What leaves me ignorant is that I haven't seen the
case *for* service identification put in a clear and structured way.
The bell-heads tend to assume from the beginning that service
identification is necessary and don't start their arguments from close
enough to first principles to get the net-heads engaged.  I wind up
siding with the net-heads because I'm don't understand the presented
argument that service identification is desirable.

* service "context"

I'm not grasping what people mean by the "context" of a call.  A call
attempt, ipso facto, describes the intent of the caller sufficiently
to allow completion of all appropriate contacts.  If the call attempt
does not, then the protocol for making the call attempt is deficient
and needs to be appropriately extended.

Of course, a service identifier *is* such an extension.  But then, it
has to be *thought about* as an extension, *treated* as an extension,
*standardized* as an extension, and *designed* as a high-quality
extension -- especially with regard to backward-compatibility.
Otherwise, you're just adding a bad extension to your protocol without
calling it an extension.

If people are allowed to make up service identifiers and yet the
service identifier is vital to completing the call, you've just
de-standardized the protocol

* Requirements and use cases

Every protocol feature needs to be justified, ultimately in order to
provide some value to the users.  There have been several uses for
service identification presented, but all of them seem to be better
served by a mechanism already present in SIP.  For example:

- Chess

If one is running a application in the UA that the user thinks of as
distinct from "the telephone", we can always give it a different URI.
URI parameters are quite good for this:

	To: <sip:[email-masked];app=chess>

If someone wants to play chess with me, I tell him my chess URI.

Where this breaks down is if lots of people run very compatible chess
applications in their UAs, and they want to play chess with a wide
variety of people on an ad-hoc basis.  At that point, the user
community would benefit from standardization, either official or
de-facto.  But I see that as no easier or more difficult than
standardizing a service identifier.  Indeed, the URI-parameter *is* a
service identifier, semantically speaking.  But it has more range for
extension.  E.g., "sip:[email-masked];app=chess2" is the URI of my
*other* chess application.

- Recording service

If one wishes to record an outgoing call, the UA can accomplish this
in a couple of ways.  One is to place the call, and then execute a an
operation much like a consultative transfer to splice the recording
server into the call.  The other is to place the call "through" the
recording server:

	To: <sip:recorder.example.com;dest=worley%40example.com>

We can add that if the UA and the next-hop server are within the same
community, the UA can signal the same *operation* through any other
agreed-upon means (even a service-identifier!).

If one wishes to record an incoming call, the called UA can accomplish
this through similar operations.  E.g., blind-transferring or
redirecting the incoming call to

	To: <sip:recorder.example.com;dest=worleys-mother%40example.com>

Again, if the called UA and the upstream proxies have an agreement,
this routing through the recording server can be done by an upstream
proxy or pre-activated through private means.

A tremendous advantage of this approach is that it's always defined
*on whose behalf the recording is being done*, and all the complexity
is controlled by the responsible UA.  The truly over-the-wire protocol
is innocent of the fact that a recording server is in place.  And so
the recording service *has no protocol impact at all*.

Indeed, if we refer to a crucial sentence of
draft-rosenberg-sipping-service-identification-01:

   The essential problem is that there are cases where a session cannot
   take place correctly unless the terminating party implements a
   certain piece of service logic.

We see that call-recording *isn't really a service in this sense*,
because it doesn't require agreement between the UAs.

- PoC or other truly incompatible things

If we take as given that PoC is truly incompatible with non-PoC SIP,
then there's nothing to be done but define a Require token, that
specifies that the SIP caller is going to be using the PoC extensions
and the SIP callee had better be able to use them too.

Exactly how the UA implements PoC is the UA's problem.  In theory, the
UA can implement PoC itself.  In practice, it may want to displace
some of the processing to the next-hop router, meaning the "service
provider", the firm that operates the last-mile network.  See the
previous bullet for how to do things like that.

But as you can see from this example, extensions that demand this sort
of treatment are a Bad Idea, because they make it hard to
interoperate, so we expect that very few of these will be defined.  We
could use service URNs as Require tokens, or any other extensible set.
Do we really plan on having enough of these that we need to have a
hierarchical organization to the token namespace?

- Multiple services

How does one designate recording a PoC call?

If we require the UA to control service handling, or determine service
handling by existing features of SIP messages, we avoid a
combinatorial explosion of defined service identifiers to describe the
various combinations of "services" that might be desired..

* Advisory service identification

One amusing effect of SIP's thorough care with upward-compatibility is
that it is incredibly easy for a vendor, service provider, or cabal of
plotters to create a set of service identifiers that will be used
correctly by everybody in the path of communication that understands
the particular set of service identifiers.  This is because there are
so many places in SIP where agents are required to ignore a datum that
they do not understand.  In particular:

- URI parameters
- Headers

And there are other items that agents are required to reject if they
do not understand them:

- INVITE bodies
- methods
- media stream types
- event types

Within this context, as long as "services" can fall back to some
reasonably standard way of communicating, anybody can define their own
spectrum of service identifiers and know that it will interoperate (at
least minimally) with the entire Internet.

* Using service URNs as routes

The only bit of draft-rosenberg-sipping-service-identification-01 that
strikes me as controversial is using a service URN in a Route header
to request that the next-hop proxy send the request to an appropriate
application server.  This mechanism requires that the next-hop proxy
understand the "service URN Route extension", because otherwise the
request cannot reach its ultimate destination.  In fact, we could add
the demand that the request contains "Proxy-Require:
service-urn-route", as that would cause no further requests to fail.
That observation starts to indicate what the problem is.

What the service URN as a Route header is to do is to ask the next-hop
proxy to choose a suitable application server -- It's a placeholder
for a route-param (the usual value in a route header).

Why not have the UA use a proper route-param instead?  There are two
cases:

The UA is in tight coordination with the next-hop proxy, in which case
they can use whatever mechanisms they mutually agree upon.  Instead of
this odd Route header, why not have the UA receive the correct
route-param in configuration information from the next-hop proxy?

The UA is *not* in tight coordination with the next-hop proxy, in
which case service-URN Route header will likely fail (because the
next-hop proxy doesn't support the extension or service), and the UA
needs to be configured (by some other means) with a proper route-param
for the application server by other means.

The only advantage of the service URN Route scheme is if we can take
as given that all UAs that implement the service are always willing to
delegate to the next-hop proxy the choice of application server.  I
don't see this as a plausible scenario.

* Lots of services?

As I read further into the thread, I see Jonathan's warning that
service URNs should be defined very sparingly is replaced by proposals
that people be able to mint them on demand.  Hmmmm, doesn't that just
mean infinite balkanization?

Well, no, because people who talk about lots of services also talk
about partial-matches between services:

>> If
>>    URN:service.comm.telephony.multimedia
>> Is present in a request but only
>>    URN:service.comm.telephony.basic
>> is supported then that can be considered a good match.

At that point, one wonders if it would also match "URN:service.comm"?
Service identifiers would degenerate into hints rather than mandatory
features.

* Compatibility with 3GPP

It's true that there will be a few billion 3GPP phones sold in the
next few years.  It's also true that almost all of those phones will
be discarded within 10 years after that.  The IETF has a long history
designing protocols that prevail in the "marketplace" of real usage.
(Remember OSI?  IETF 1, US government 0.)  This is primarily because
the IETF *designs better protocols*.  There's no reason to believe
that adopting something *just because some manufacturers want to do it
that way* will lead to success.

* Gonzalo's issues

    1) Non-backwards compatible services (e.g., PoC). Unless user agents
    understand the special logic that relates to the service, they will not
    be able to do the right thing. It has been proposed to use the Require
    header field to identify these services.

If understanding the service logic is truly mandatory, Require seems
to be indicated.  (We can also use the Require as the method of
detecting that the service logic is needed for an incoming call.)

And as Paul and others have said "That will have the effect of
discouraging too many of these, and encouraging the finding backward
compatible ways of accomplishing the same thing."

    2) Enhanced experience. Some services are backwards compatible. That is,
    even if the other endpoint does not understand the service, a session
    can be established. However, if the other end understands the service,
    users get, somehow, an enhanced experience.

    An example of this type of service could be a multimedia telephony
    service, which might include things such as mandatory support for
    certain supplementary services.

    It has been proposed to use feature tags and caller preferences for this
    type of service. I would like to see discussions on whether or not this
    way of using caller preferences is appropriate.

This approach makes sense to me -- it gives the caller a way to
express that it would prefer one UA over another, based on its
understanding of a certain special processing mode..

    3) SIP-established sessions as a transport for proprietary information.
    Some applications use SIP to establish generic media streams in order to
    exchange application-specific information on top of them. For example, a
    network game may use SIP to establish a TCP stream between two endpoints
    and then send the position of its players (or whatever information the
    game needs to transfer) over that TCP stream. Another game may establish
    a similar TCP stream, but transfer different information in a different
    format over it. The same example would be valid if both applications
    used MSRP streams instead of TCP streams.

    I would like to see discussions on how we want to identify those two
    applications (i.e., both games in the example above). Do we want to use
    the same mechanism as in 1)?

I would think a better solution is a different body type, e.g.,
"application/x-<your trademark here>-tcp-setup".  After all, the body
*isn't* SDP.  And the body type allows the UAs (and proxies acting on
their behalf) to unambiguously identify the type of communication.

    4) Network support and interactions with caller preferences. It has been
    discussed that services in the three categories above sometimes require
    network support. Therefore, an entity in the network may need to be able
    to identify the service a given SIP request relates to. Note that
    network support may be required in the originating and terminating
    networks, and that different mechanisms may be used to implement network
    support in an originating network or in a terminating network.

    I would like to see discussions on possible interactions between
    services that require network support and caller preferences. What
    happens if a UA sends an INVITE that uses caller preferences to indicate
    that the user would prefer to use multimedia telephony but that would be
    OK using PoC should multimedia telephony not be available. Are both, the
    multimedia telephony and the PoC application servers, included in the
    signaling path, just in case?

Philosophically, everything gets sent to the UA and the UA decides
what it wants to do with it.  In practice, the UA may offload some of
the work "toward the network" -- the UA and its next-hop proxy
conspire to *appear* to be a proper RFC 3261 proxy and UA, but in
reality, the proxy does some of the things that the UA appears to be
doing.

In regard to complex preferences, the UA would theoretically decide
which servers it wants to thread into the call.  In practice, the
proxy makes the decision for the UA, based on its knowledge of what
the UA wants done.

In your example, what would the ideal UA want to do when it receives a
call admitting both PoC and "multimedia telephony"?  The proxy, acting
on the UA's behalf, must do that.

* Service identification and QoS

Yes, we need a real way to specify QoS in SIP.  But all service
identification schemes I've seen seem to be too coarse-grained to
specify QoS adequately.  For that matter, I've never seen a good
method to specify QoS anywhere.  But as someone told me once, the real
solution is to add QoS specifications to SDP, because there is no
reason to assume that all the media streams want the same QoS
treatment..

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: Dean Willis <[email-masked]>
Date: Tue, 20 Mar 2007 10:23:36 +0100

> That observation starts to indicate what the problem is.

Can't use the proxy-require, else ALL proxies in the loop would be  
required to understand the extension.

What we have here is an e2m use case.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Mar 2007 05:39:09 -0400

I don't see the issue with this. If I just use a URN as a URI in a Route 
header, either it will succeed or it will fail. If I put it in as a 
strict route then the proxy I forward it to will be the one that must do 
it or fail. If I put it in as a loose route then it is only necessary 
that it *eventually* get to a proxy that can figure it out.

	Paul

---

From: [email-masked]
Date: Wed, 21 Mar 2007 21:21:18 -0500

> required to understand the extension.

Ah, yes, my mistake.  It's as if there's a Proxy-Require up to the
point that some proxy can understand and remove the Route with the
service URN.  After that, there are no proxy requirements.

   From: Paul Kyzivat <[email-masked]>

Yeah, but that assumes that every proxy before that has *some* strategy
for dealing with the service URN, presumably by forwarding it "toward
the center", hoping that a studlier proxy will be able to understand
the request.

But it's fairly safe to assume that in practice, unless a proxy was
explicitly coded to implement the service-URN-Route, it will discover
that it can't understand the Route and will reject (or just drop) the
request.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Mar 2007 05:05:46 -0400

> that it can't understand the Route and will reject (or just drop) the

Sure it can fail. But it doesn't need a Proxy-Require to make it fail. 
Presumably you wouldn't include such a route into your request unless 
you had reason to suspect it would work. If you need this to make some 
service work, and it fails, then you just can't use that service.

	Paul