Subject: RE: [Sipping] Requirements for the identification of IMScommunicationservices.

From: "Brian Stucker" <[email-masked]>
Date: Fri, 24 Mar 2006 12:51:34 -0600

I took this not to mean a mutant telco protocol, but something more along the lines of the following:

- A device has knowledge of certain (potentially, but not exclusively) network based services that are available to it. How does it correctly format it's request such that the set of services that it is interested in having applied to the request are invoked in a generic (standards-based) manner?

Obviously a service URI is one way, and RFC-3841 is another, but they seem clunky and inefficient at best once you start combining the services you want applied to the call.

Essentially-- The device wants to order a set of services to be applied from the network via a network service factory. How does it format that request?

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, March 24, 2006 10:10 AM
To: Andrew Allen
Cc: sipping; Stephen Terrill (E2/EEM); Gonzalo Camarillo (JO/LMF); Rohan
Mahy
Subject: Re: [Sipping] Requirements for the identification of
IMScommunicationservices.

On Mar 22, 2006, at 5:22 PM, Andrew Allen wrote:

>  Firstly I am supportive of the basic requirement to provide a  
> straightforward means to easily identify that SIP requests are  
> related to a particular communication service.
>
>
>
> Of course it is possible to take a view that there is only a single  
> communication service enabled by SIP however in reality I think  
> both the average user and service providers have the need to group  
> and package features and capabilities together as “communication  
> services”
>
>
>
> My definition of a “communication service” is a somewhat arbitrary  
> bundle or package of capabilities that make some sense when grouped  
> together from either a user experience or a service provider  
> business perspective. Some service groupings are historical (such  
> as replicating the telephony supplementary services of GSM or a  
> 5ESS) others are based on a grouping of those capabilities  
> available in popular products (such as MSN messenger and  
> Netmeeting). Others may be “public services” such as Emergency  
> Services.

This offers a good chance to explain what I think people find  
troubling about your phrasing.

1) You make that assumption that "SIP requests are related to a  
particular communication service".

2) You describe POC, "ISDN simulation", and "emergency" as services.

What happens if you want to make a POC call (or an ISDN simulation  
call) to an "emergency" service?

if you can't mix and match services, you're not using SIP. You're  
using some mutant telco protocol that we've little interest in  
discussing here.

--
Dean

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Fri, 24 Mar 2006 15:22:21 -0500

On Fri, 2006-03-24 at 12:51 -0600, Brian Stucker wrote:
> - A device has knowledge of certain (potentially, but not exclusively)
> network based services that are available to it. How does it correctly
> format it's request such that the set of services that it is
> interested in having applied to the request are invoked in a generic
> (standards-based) manner?

Maybe I'm the only ignorant one here, but what is a "network based
service"?

Dale

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Mar 2006 15:31:13 -0600

Brian Stucker wrote:
> - A device has knowledge of certain (potentially, but not
> exclusively) network based services that are available to it. How
> does it correctly format it's request such that the set of services
> that it is interested in having applied to the request are invoked in
> a generic (standards-based) manner?
> 
> Obviously a service URI is one way, and RFC-3841 is another, but they
> seem clunky and inefficient at best once you start combining the
> services you want applied to the call.
> 
> Essentially-- The device wants to order a set of services to be
> applied from the network via a network service factory. How does it
> format that request?

Right -- the important thing is "a set of services". They must in 
general be combinable rather than exclusive, or we have a major mismatch 
in designs.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Mar 2006 15:38:27 -0600

> Maybe I'm the only ignorant one here, but what is a "network based

Telco speak for "function invoked by a proxy or other service-provider 
equipment" rather than "function performed in an end-user network node."

The fact that we differentiate between "service provider equipment" and 
"end user equipment" and that this presumably says something about the 
function being perfromed speaks volumes about the design philosophy.

"network based service" is a misnomer, as we all know that the only 
network-based services are packet forwarding, routing topology 
management, and just possibly (but not usually in IP) admissions control 
and congestion reporting.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Mar 2006 09:13:32 -0500

> - A device has knowledge of certain (potentially, but not exclusively) network based services that are available to it. How does it correctly format it's request such that the set of services that…

In the ietf sip/sipping community we have a limited notion of network 
based services:
- we have the retargetting services provided by the proxy/registrar.
   These can be influenced via callerprefs
- there are NAT and FW "services", and some ways to deal with them
   using STUN and TURN, and possibly other midcom work
- there is the relatively new identity work, with servers that
   provide identity assertions. So far, AFAIK the manner in which
   a UA ensures that one is in the path and doing the right thing
   is relatively unspecified
- there are a limited number of recognized B2BUA instances, such as
   MESSAGE exploders and conference foci. These are typically
   addressed directly.
- there is the notion of a presence server/compositor.
   So far, AFAIK, how things get routed to it is not standardized.
- there are no doubt others that I have forgotten.

I'm not aware of any general framework for all of this.

> Essentially-- The device wants to order a set of services to be applied from the network via a network service factory. How does it format that request?

I think a general mechanism for ordering services to be applied requires 
a framwork for how services are applied. IMS has such a framework, but 
ietf does not. I think it would be difficult to transplant the entire 
IMS framework into ietf, but *something* might be acceptable, expecially 
if it gives reasonable control to the UAs.

The part I find most difficult is applying services on the terminating 
end. I think we must be very careful about the caller naming services at 
the terminating end, because it implies too much required collusion 
between caller and callee - breaking interoperability. Very generalized 
services (e.g. screening) can be applied to all incoming calls. 
Specialized services that are only applied in certain cases are IMO 
better if first recognized by the UAS, or by recognizing a combination 
of intrinsic attributes of the incoming request, that will apply even in 
interop cases.

	Paul