Subject: RE: [Sipping] "Services"

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 23 Mar 2006 10:07:05 -0500

I have been somewhat following this discussion.  The comment below seems
to suggest that this is really about whether you want to indicate things
atomically or us a tag for a particular permutation aggregation of
atomic capabilities.

In the end something needs to dereference these aggregates.

Doesn't this ultimately result in two lists of things:

Require: mandatory things for which the call should fail if any one is
missing

Desired: optional things for which the call should succeed if any is
missing 

Why add the step of aggregating then disaggregating?  To save header
space?  
Surely, a filter could determine that if A, B, and C are required, send
to App Server X.

Still trying to glean the crucial point here,
Mike

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 2:37 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: Sipping; Henning Schulzrinne
> Subject: Re: [Sipping] "Services"
> 
> 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
> 
> 
> >
> >
> > Jeroen van Bemmel wrote:
> >>> 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.
> >>>
> >>
> >> 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)
> >
> > 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.
> >
> >> ( 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.
> >
> > 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.)
> >
> >> 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"?
> >
> > 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
> >
> >> Regards,
> >>
> >> jeroen
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 23 Mar 2006 19:19:38 +0100

Mike,

Fair questions. My point is this: 3GPP wants to define service identifiers. 
Now the IETF can do two things: persist in saying that explicit enumeration 
is bad (and risk proliferation of diverging private non-interoperable 
extensions), or try to come up with a way/mechanism to satisfy the request 
without compromising on the "True philosophy of SIP(tm)"

My proposal below was to define a service identifier as a URL that resolves 
to a set of caller preferences. That way you have something that can be used 
as an identifier, while providing a clear and simple mapping to existing SIP 
semantics. Transforming a request containing such an identifier into a SIP 
request (as it is currently defined) is straightforward (get the preferences 
and put them in an Accept-Contact), ignoring the identifier is equivalent to 
ignoring caller preferences

So the point of aggregating is to come up with a service identifier as 
desired. Indeed a proxy could take on this role of aggregator and insert an 
identifier into requests that match a defined set of preferences, using a 
label (URL) of its choosing. The resulting smaller message size and perhaps 
easier processing is a side benefit

Regards,

Jeroen

----- Original Message ----- 
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 
<[email-masked]>
Cc: "Sipping" <[email-masked]>; "Henning Schulzrinne" 
<[email-masked]>
Sent: Thursday, March 23, 2006 4:07 PM
Subject: RE: [Sipping] "Services"

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Mar 2006 14:32:28 -0500

Jeroen,

So far what we have is a copy of a list of IMS requirements written in 
"IMS-speak". These days I feel like I have a toe in the IMS pond, but 
I'm not a swimmer there. To me the list of requirements and definitions 
is partially but not fully intelligible.

If the intent is to define Service-Identifier (rather than 
P-Service-Identifier) then I think we need a draft that defines Service 
and the requirements for Service-Identifier in IETF-speak rather than 
IMS-speak. I expect that will require either a demonstration that the 
meaning of "Service" is the same as what we have adopted in presence, or 
else a change to some other term.

If we can get that, then it can either be expanded into a doc containing 
both requirements and mechanism, or else work can begin on a separate 
mechanism document.

As I have explained, I have reservations about your approach. But they 
don't mean much in this rambling conversation. In the context of a draft 
comments become much more meaningful.

	Paul

Jeroen van Bemmel wrote:
> Mike,
> 
> Fair questions. My point is this: 3GPP wants to define service 
> identifiers. Now the IETF can do two things: persist in saying that 
> explicit enumeration is bad (and risk proliferation of diverging private 
> non-interoperable extensions), or try to come up with a way/mechanism to 
> satisfy the request without compromising on the "True philosophy of 
> SIP(tm)"
> 
> My proposal below was to define a service identifier as a URL that 
> resolves to a set of caller preferences. That way you have something 
> that can be used as an identifier, while providing a clear and simple 
> mapping to existing SIP semantics. Transforming a request containing 
> such an identifier into a SIP request (as it is currently defined) is 
> straightforward (get the preferences and put them in an Accept-Contact), 
> ignoring the identifier is equivalent to ignoring caller preferences
> 
> desired. Indeed a proxy could take on this role of aggregator and insert 
> an identifier into requests that match a defined set of preferences, 
> using a label (URL) of its choosing. The resulting smaller message size 
> and perhaps easier processing is a side benefit
> 
> Regards,
> 
> Jeroen
> 
> ----- Original Message ----- From: "Michael Hammer (mhammer)" 
> <[email-masked]>