Subject: [Sipping] "Services"

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 22 Mar 2006 10:16:52 -0500

The discussion of event throttling suggests this to me:

As far as I can make out, there is a significant practical difference
from "IETF SIP" environments and IMS/3GPP environments.  In IETF
environments, an AOR routes to (usually) one UA, which is an application
that runs on one host.  So if another UA wishes to make a request of the
AOR, the request is routed to that application, which decides what (if
anything) it can do to fulfill the request.  In this situation, request
processing is largely end-to-end, because there is no useful processing
that intermediate systems can perform -- the UA application knows better
than any intermediate system what can be done.

In IMS/3GPP environments, the facilities presented by an AOR are the
union of the facilities provided by a group of largely independent
applications that run on a group of servers.  In practice, a large group
of AORs is managed by a "service provider", and each application
implements a certain facility for all the AORs in a group.  In addition,
each application is from a different vendor, so the applications do not
coordinate with each other very well.

In that environment, the primary problem is how to route a request --
which application server should service a request?  This must be
determined by a front-end proxy.  In practice, the service providers
seem to tag requests into a small number of industry-standard "service"
categories, and each application server is sold as implementing some set
of "services".  So the front-end proxy can sort requests by the
"service" tag.

>From an IETF point of view, it is counter to the end-to-end philosophy
to construct a fixed and small set of subsets of SIP, and require each
request to fit entirely within one subset.  But how would we solve the
request-routing problem?  Though a request bears many markers for what
the UA requires, we haven't really thought through the problem of making
it really clear what facilities a request requires for handling it.
(E.g., an INVITE need not carry SDP, so a service provider doesn't know
whether to send it to a voice carrier system or a ToIP system.)

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: Wed, 22 Mar 2006 10:59:29 -0500

I had some side discussions on this subject. One idea that came up was 
to employ the "service URN" (being defined in ecrit for identification 
of emergency services) in potentially novel ways.

When the service is the intended target of a request, then the service 
urn can be employed directly.

When the service is expected to be performed by an intermediary along 
the path to the target, a service URN could be included in a Route 
header. This mitigates the MITM flavor of IMS services by having the UA 
explicitly enumerate the attacks it wishes to have applied.

This is not a well baked concept. Open issues include:

- how would the UA know in what order the services should be applied;

- this seems workable for services applied for originated requests.
   But it doesn't work well for services to be applied at the terminating
   end. Some other mechanism is needed for that.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 11:21:31 -0500

This seems like a case for caller preferences.

It might help to have some agreed-upon examples of such services, as was 
noted.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Mar 2006 11:43:59 -0500

I too think there may be a role for callerprefs here. But I am also 
concerned that the IMS model presents problems in the use of callerprefs:

- callerprefs is structured to choose among a set of alternatives to be 
the UAS of a request.

- the IMS model, before it ever gets around to the problem of choosing 
among alternative registered UAS candidates, makes a series of 
independent decisions about whether to apply a particular server to the 
request. If chosen, each such server may prove to be a "proxy" or a UA. 
It seems that there might be a desire to use callerprefs to make these 
decisions. It is far from clear whether this makes sense at all, or how 
it can be done so that it does make sense.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 22 Mar 2006 20:49:13 +0100

> - callerprefs is structured to choose among a set of alternatives to be 

True, callerprefs is designed to support the routing decision at the 
registrar of the target user, with as primary use case the ability to choose 
amongst a set of contacts.

So the question is: could this be generalized to
1 - routing decisions at intermediate nodes, possibly including both 
next-hop and additional nodes (i.e. adding multiple Route headers)
2 - non-routing decisions (e.g. policy decisions)

( perhaps all decisions could be considered as routing decisions, if the 
decision "not to route" is included. In that case 2 is covered)

The desired "Service Identifier" could be seen as a convenient, explicit 
label for a set of features/capabilities which is implicitly and 
non-formally defined (non-formal in the sense: at least not in the form of 
callerprefs). Such explicit enumeration is on one hand undesirable, because 
the number of identifiers is exponential in the number of capabilities (of 
which there are quite a few in SIP). On the other hand, probably only a 
small subset of all combinations makes sense, and it can be convenient to 
have a short and easy way of refering to a set of capabilities, without 
having to list those capabilities explicitly. This works as long as all 
(potential) nodes on the path share the same definition of the capability 
set.

Option tags are not that different from such service identifiers: they too 
are a shorthand notation representing a complex whole of protocol behavior, 
agreed upon in standardization and put in an IANA registry. They are 
actually worse in terms of formalisms, as no formal definition of the 
complete behavior associated with each tag exists. And yet, new options tags 
are happily defined and applied each day, and things seem to interoperate 
(at least on a level that is sufficiently usable).

Concluding, I would say that a registry for service identifiers could be 
created. Interoperability concerns are the same as for option tags. In fact, 
interoperability could be significantly better than option tags if these 
service identifiers would be defined in terms of features a la caller 
preferences, such that we would have a formal notion of what each identifier 
means.

Who wants to take a first shot at the definition of "voip"?

Regards,

jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Mar 2006 18:28:56 -0500

Jeroen van Bemmel wrote:
>> - callerprefs is structured to choose among a set of alternatives to 
>> be the UAS of a request.
>>
> 
> registrar of the target user, with as primary use case the ability to 
> choose amongst a set of contacts.
> 

At best I think there are severe limitations on what can be done this 
way without compromising the basic role.

A fundamental problem is that if callerprefs is used to select whether 
to involve a particular AS, and doing so then prevents registered 
contacts from being considered by the matching algorithm, then it 
fundamentally breaks the algorithm.

It might work in some cases, when a server *is* the source of an 
essential capability, or is essential in providing a capability. But it 
breaks down pretty fast if the caller is trying to specify preferences 
rather than requirements. For instance, suppose I prefer a UA that 
supports regular full duplex voice, but am willing to accept PoC as a 
lower priority alternative. I can easily express this as callerprefs, 
and if PoC and voice are simply capabilities of the registered contacts 
all will be well. But if PoC requires the inclusion of a PoC server as 
well it no longer works, because the inclusion of the PoC server depends 
on which contact will be chosen.

> non-formally defined (non-formal in the sense: at least not in the form 
> of callerprefs). Such explicit enumeration is on one hand undesirable, 
> because the number of identifiers is exponential in the number of 
> capabilities (of which there are quite a few in SIP). On the other hand, 
> probably only a small subset of all combinations makes sense, and it can 
> be convenient to have a short and easy way of refering to a set of 
> capabilities, without having to list those capabilities explicitly. This 
> works as long as all (potential) nodes on the path share the same 
> definition of the capability set.

The last is a strong argument against this approach. You could use the 
service id as a "macro" that is literally expanded into the 
corresponding callerprefs. But then there is little reason to do it - 
the expansion might as well be done by the UAC. Then the service id 
becomes simply a convenient handle for *talking* about a combination of 
callerprefs.

> Option tags are not that different from such service identifiers: they 
> too are a shorthand notation representing a complex whole of protocol 
> behavior, agreed upon in standardization and put in an IANA registry. 
> They are actually worse in terms of formalisms, as no formal definition 
> of the complete behavior associated with each tag exists. And yet, new 
> options tags are happily defined and applied each day, and things seem 
> to interoperate (at least on a level that is sufficiently usable).

Up to a point I agree with you about option tags. However the UA has 
considerable control over their influence. Option tags in a Require 
affect only UAs, while Proxy-Require affects only proxies. This becomes 
a gray area when you introduce a b2bua - does it follow Require or 
Proxy-Require? This is perhaps one of the objectionable aspects of B2BUAs.

But, if 3gpp wants to use options as service ids, then guess it is free 
to submit standards track drafts to define them. (However I don't 
imagine that will be especially fruitful.)

> created. Interoperability concerns are the same as for option tags. In 
> fact, interoperability could be significantly better than option tags if 
> these service identifiers would be defined in terms of features a la 
> caller preferences, such that we would have a formal notion of what each 
> identifier means.
> 

I will leave this to you. Frankly, IMO none of the things I have heard 
mentioned as "services" meet my conception of things that ought to be 
mutually exclusive buckets, which is what seems to be expected of 
services. I believe almost everything can potentially be mixed together 
in a single sip session.

I want the option to do voice, video, and IM in a single session. And I 
want to be able to change the set of media within the session. I can 
also see combining video and IM with PoC. Or switching from PoC to full 
duplex voice within a session. I fear the focus on identifying services 
will lead to structuring implementations in a way that precludes these 
kinds of usage.

As another example, I see a session with an answering system as 
different from a session with a human. In some cases it is useful to be 
able to definitively require one or the other. But the choice is not 
often mutually exclusive. In many cases I will settle for either though 
preferring one. Anything that commits me to one or the other before, or 
even after, the session is established is a problem.

Fundamentally, I find the way IMS inserts servers into sessions is going 
to hamstring the creation of reasonable services. It would be far more 
flexible if the UE acted as the coordination point for any servers 
employed in a session.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 23 Mar 2006 08:37:26 +0100

Paul,

Perhaps it would help if we step away from the term "service", and stick 
with "tag" or "identifier". A token that can serve as input for 
demultiplexing requests. As the OMA PoC example shows, that's really what 
this is being used for.

Although it may be a bit early to discuss solutions, just to share my 
thoughts consider the following:

INVITE ...
Service-Id: http://www.ietf.org/services/voip

The URI would be dereferenced to provide some XML-based document that 
describes a set of caller preferences, and a 'display name' as a convenient 
tag for human discussion. In a way this is similar to XML namespace URIs, 
elements could cache the resulting mapping and translate from Service-Id 
into the set of capabilities that it represents. At the same time, proxies 
could treat this as an opaque identifier, and map it to some local policy. 
UAC / UAS can perform the lookup and verify if they support the listed 
capabilities.

You could also see this as a form of "indirect caller preferences" (like 
indirect content, but then also relevant for proxies). I think something 
like this is at least more desirable than a proliferation of obscure feature 
tags that are really hacks to demultiplex things.

Two service ids could resolve to the same set of capabilities, in that sense 
they need not be "mutually exclusive buckets". A proxy could still apply 
different policies, this is no different from the way things are now (when 
responsible for the domain). Expansion of this "macro" as you call it at the 
UAC would not provide the same functionality, since then the use as an 
opaque identifier is lost. A single identifier also provides for ease of 
processing, it can e.g. serve as a key into a table of policies.

Require vs Proxy-Require restrict the set of elements that the option is 
required from. However, they don't give a UAC any control over policy 
decisions taken at proxies or UAS, they only say "please reject if you don't 
understand this".

As for the mixing of various services, mid-session changes and the way the 
system setup might restrict this: I see your point, but at the same time all 
of the above would still allow for implementations that are structured in a 
way that does allow these combinations. If there is sufficient demand, I'm 
sure someone will provide it (IMS-based or otherwise)

Regards,

Jeroen

> At best I think there are severe limitations on what can be done this way 
> without compromising the basic role.
>
> A fundamental problem is that if callerprefs is used to select whether to 
> involve a particular AS, and doing so then prevents registered contacts 
> from being considered by the matching algorithm, then it fundamentally 
> breaks the algorithm.
>
> It might work in some cases, when a server *is* the source of an essential 
> capability, or is essential in providing a capability. But it breaks down 
> pretty fast if the caller is trying to specify preferences rather than 
> requirements. For instance, suppose I prefer a UA that supports regular 
> full duplex voice, but am willing to accept PoC as a lower priority 
> alternative. I can easily express this as callerprefs, and if PoC and 
> voice are simply capabilities of the registered contacts all will be well. 
> But if PoC requires the inclusion of a PoC server as well it no longer 
> works, because the inclusion of the PoC server depends on which contact 
> will be chosen.
>
> service id as a "macro" that is literally expanded into the corresponding 
> callerprefs. But then there is little reason to do it - the expansion 
> might as well be done by the UAC. Then the service id becomes simply a 
> convenient handle for *talking* about a combination of callerprefs.
>
>> options tags are happily defined and applied each day, and things seem to 
>> interoperate (at least on a level that is sufficiently usable).
>
> considerable control over their influence. Option tags in a Require affect 
> only UAs, while Proxy-Require affects only proxies. This becomes a gray 
> area when you introduce a b2bua - does it follow Require or Proxy-Require? 
> This is perhaps one of the objectionable aspects of B2BUAs.
>
> But, if 3gpp wants to use options as service ids, then guess it is free to 
> submit standards track drafts to define them. (However I don't imagine 
> that will be especially fruitful.)
>
> services. I believe almost everything can potentially be mixed together in 
> a single sip session.
>
> want to be able to change the set of media within the session. I can also 
> see combining video and IM with PoC. Or switching from PoC to full duplex 
> voice within a session. I fear the focus on identifying services will lead 
> to structuring implementations in a way that precludes these kinds of 
> usage.
>
> As another example, I see a session with an answering system as different 
> from a session with a human. In some cases it is useful to be able to 
> definitively require one or the other. But the choice is not often 
> mutually exclusive. In many cases I will settle for either though

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Mar 2006 10:25:02 -0500

Jeroen van Bemmel wrote:
> demultiplexing requests. As the OMA PoC example shows, that's really 
> what this is being used for.
> 
> describes a set of caller preferences, and a 'display name' as a 
> convenient tag for human discussion. In a way this is similar to XML 
> namespace URIs, elements could cache the resulting mapping and translate 
> from Service-Id into the set of capabilities that it represents. At the 
> same time, proxies could treat this as an opaque identifier, and map it 
> to some local policy. UAC / UAS can perform the lookup and verify if 
> they support the listed capabilities.

I find little good and a lot of bad in this. The little bit of good is 
that messages are smaller. The bad is that things only work if the 
caller and the callee agree on the set of services to be used. I don't 
imagine a single standard for this. More likely OMA would have one set 
of definitions, Microsoft would have its own set, AOL its own set, etc. 
Then you have to guess what the callee supports in order to call them, 
and you need an interface on your device to perform that selection. It 
could get like the browsers that have to lie about what kind of browser 
they are in order to interoperate.

Why not just put all the capabilities and preferences into the requests, 
and have each element that cares match for the ones it considers essential?

> like this is at least more desirable than a proliferation of obscure 
> feature tags that are really hacks to demultiplex things.

I disagree. For example, suppose I have five feature tags of interest, 
and five possible values for each. That is fairly concisely represented.

Now consider defining a named service that corresponds to one particlar 
value of each of the five features. That is 3125 different "services". 
Of course no one naming authority is likely to define them all. But 
neither is it clear that two different organizations would define the 
same subset. Even if they do define the same subset, they will be using 
different names for the same thing.

What you end up with is a tower of Babel.

> Two service ids could resolve to the same set of capabilities, in that 
> sense they need not be "mutually exclusive buckets". A proxy could still 
> apply different policies, this is no different from the way things are 
> now (when responsible for the domain). Expansion of this "macro" as you 
> call it at the UAC would not provide the same functionality, since then 
> the use as an opaque identifier is lost. A single identifier also 
> provides for ease of processing, it can e.g. serve as a key into a table 
> of policies.

And then the policies don't work for a caller that making an identical 
offer but doesn't know to specify the service.

This might be less of a problem if confined to the UAC and proxies 
representing it when originating requests. At least they can have a 
service agreement and understand what is expected. But it is very 
problematic when the caller expects the calle to understand.

> decisions taken at proxies or UAS, they only say "please reject if you 
> don't understand this".
> 
> As for the mixing of various services, mid-session changes and the way 
> the system setup might restrict this: I see your point, but at the same 
> time all of the above would still allow for implementations that are 
> structured in a way that does allow these combinations. If there is 
> sufficient demand, I'm sure someone will provide it (IMS-based or 
> otherwise)

I'm not so optimistic.

	Paul

>> essential capability, or is essential in providing a capability. But 
>> it breaks down pretty fast if the caller is trying to specify 
>> preferences rather than requirements. For instance, suppose I prefer a 
>> UA that supports regular full duplex voice, but am willing to accept 
>> PoC as a lower priority alternative. I can easily express this as 
>> callerprefs, and if PoC and voice are simply capabilities of the 
>> registered contacts all will be well. But if PoC requires the 
>> inclusion of a PoC server as well it no longer works, because the 
>> inclusion of the PoC server depends on which contact will be chosen.
>>
>>> ( perhaps all decisions could be considered as routing decisions, if 
>>> the decision "not to route" is included. In that case 2 is covered)
>>
>>
>>
>>
>>> The desired "Service Identifier" could be seen as a convenient, 
>>> explicit label for a set of features/capabilities which is implicitly 
>>> and non-formally defined (non-formal in the sense: at least not in 
>>> the form of callerprefs). Such explicit enumeration is on one hand 
>>> undesirable, because the number of identifiers is exponential in the 
>>> number of capabilities (of which there are quite a few in SIP). On 
>>> the other hand, probably only a small subset of all combinations 
>>> makes sense, and it can be convenient to have a short and easy way of 
>>> refering to a set of capabilities, without having to list those 
>>> capabilities explicitly. This works as long as all (potential) nodes 
>>> on the path share the same definition of the capability set.
>>
>>
>> becomes simply a convenient handle for *talking* about a combination 
>> of callerprefs.
>>
>>> Option tags are not that different from such service identifiers: 
>>> they too are a shorthand notation representing a complex whole of 
>>> protocol behavior, agreed upon in standardization and put in an IANA 
>>> registry. They are actually worse in terms of formalisms, as no 
>>> formal definition of the complete behavior associated with each tag 
>>> exists. And yet, new options tags are happily defined and applied 
>>> each day, and things seem to interoperate (at least on a level that 
>>> is sufficiently usable).
>>
>>
>> affect only UAs, while Proxy-Require affects only proxies. This 
>> becomes a gray area when you introduce a b2bua - does it follow 
>> Require or Proxy-Require? This is perhaps one of the objectionable 
>> aspects of B2BUAs.
>>
>> But, if 3gpp wants to use options as service ids, then guess it is 
>> free to submit standards track drafts to define them. (However I don't 
>>> Concluding, I would say that a registry for service identifiers could 
>>> be created. Interoperability concerns are the same as for option 
>>> tags. In fact, interoperability could be significantly better than 
>>> option tags if these service identifiers would be defined in terms of 
>>> features a la caller preferences, such that we would have a formal 
>>> notion of what each identifier means.
>>>
>> services. I believe almost everything can potentially be mixed 
>> together in a single sip session.
>>
>> I want the option to do voice, video, and IM in a single session. And 
>> I want to be able to change the set of media within the session. I can 
>> also see combining video and IM with PoC. Or switching from PoC to 
>> full duplex voice within a session. I fear the focus on identifying 
>> services will lead to structuring implementations in a way that 
>> precludes these kinds of usage.
>>
>> different from a session with a human. In some cases it is useful to 
>> be able to definitively require one or the other. But the choice is 
>> not often mutually exclusive. In many cases I will settle for either 
>> though preferring one. Anything that commits me to one or the other 
>> before, or even after, the session is established is a problem.
>>
>> Fundamentally, I find the way IMS inserts servers into sessions is 
>> going to hamstring the creation of reasonable services. It would be 
>> far more flexible if the UE acted as the coordination point for any 
>> servers employed in a session.
>>
>> Paul
>>
>>> Regards,
>>>
>>> jeroen 
> 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Mar 2006 10:01:35 -0600

> than any intermediate system what can be done.

This begs the question of whether "forking" and other retargeting  
(forward to VM on no-answer) are useful processing executed in the  
proxy serving the AOR. I'm beginning to think not, but I'm sure many  
people think otherwise.

--
Dean