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

From: "Brian Stucker" <[email-masked]>
Date: Mon, 27 Mar 2006 10:55:32 -0600

Thanks Paul,

I don't think that being able to invoke a service on another box breaks the general notion of how IETF views network based services. I believe that it's very possible to allow the UA to apply a "treatment" to the call (ie ask for a media server to be inserted to record the call to an email, or invoke a voicemail function) without requiring something in the middle to be around like a BBUA.

I also agree that we don't want too much collusion between the originator and the terminator although I seem to recall Dean dissenting on this view as part of the PRACK digression into cryptographic transparency of middleboxes.

Regards,
Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 27, 2006 8:14 AM
To: Stucker, Brian [RICH1:B620:EXCH]
Cc: Dean Willis; Andrew Allen; Stephen Terrill (E2/EEM); sipping;
Gonzalo Camarillo (JO/LMF); Rohan Mahy
Subject: Re: [Sipping] Requirements for the identification of
IMScommunicationservices.

Brian Stucker wrote:
> 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?

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.

> 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?

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

> 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
> 

_______________________________________________
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: Mon, 27 Mar 2006 12:11:32 -0500

> I don't think that being able to invoke a service on another box breaks the general notion of how IETF views network based services. I believe that it's very possible to allow the UA to apply a "tr…

Certainly there are ways to accomplish these ends that don't bother me. 
The most straightforward is when the UA orchestrates the service itself. 
For instance the UA can obtain the media server (via sip or otherwise) 
and arrange the call signaling so that the media server is in the media 
path. For instance in that case if it becomes involved in a multimedia 
call but has no multimedia mediaserver, it can obtain independent media 
servers for each medium, and coordinate their concurrent use in the call.

This gets a lot harder when big-brother is doing all this for you, and 
all you can do is put some hints in the sip message that might affect 
how big brother routes your sip message. In that case you may have no 
option to involve a distinct media server for each medium.

	Paul

---

From: <[email-masked]>
Date: Mon, 27 Mar 2006 11:14:45 -0600

Brian Stucker wrote:

>we don't want too much collusion between the originator and the terminator

Do you mean the users who are paying for the service?

If yes, than it a crisp summary of the whole philosophy of the IMS.

Thanks, Henry

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Monday, March 27, 2006 10:56 AM
To: Paul Kyzivat
Cc: Rohan Mahy; Stephen Terrill (E2/EEM); Gonzalo Camarillo (JO/LMF); Dean
Willis; Andrew Allen; sipping
Subject: RE: [Sipping] Requirements for the identificationof
IMScommunicationservices.

Thanks Paul,

I don't think that being able to invoke a service on another box breaks the
general notion of how IETF views network based services. I believe that it's
very possible to allow the UA to apply a "treatment" to the call (ie ask for
a media server to be inserted to record the call to an email, or invoke a
voicemail function) without requiring something in the middle to be around
like a BBUA.

I also agree that we don't want too much collusion between the originator
and the terminator although I seem to recall Dean dissenting on this view as
part of the PRACK digression into cryptographic transparency of middleboxes.

Regards,
Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, March 27, 2006 8:14 AM
To: Stucker, Brian [RICH1:B620:EXCH]
Cc: Dean Willis; Andrew Allen; Stephen Terrill (E2/EEM); sipping;

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?

	Paul

>>and package features and capabilities together as "communication  
>>services"
>>
>>
>>
>>My definition of a "communication service" is a somewhat arbitrary  
>>Netmeeting). Others may be "public services" such as Emergency  
>>Services.
> 
>