Subject: RE: [Sipping] Comment on request history discussion

From: "Mark Watson"<[email-masked]>
Date: Tue, 19 Mar 2002 17:08:20 -0000

Ben Campbell wrote:
> 
> I certainly hope that if I bye SIP routing services from a service 
> provider, they give me the ability to bye voice mail from a separate 
> provider. I also hope they do not give me a single place to enter the 
> address of my voice mail server, but rather ask me "What should we do 
> with a busy condition? What about a no answer condition." They don't 
> even _know_ its a voice mail system--it could be an 
> announcement server 
> that says "Ben is busy, call back later."
> 
>

But you are just 'hoping' that your SIP provider will give you separate
places to enter the address of your VM server for every scenario that you
consider to be different - or rather for every scenario that the VM service
provider is capable of considering as different.

So, you are limiting the voicemail service which can be provided based on
how flexible the SIP provider can be in the construction of the URI.

On the other hand, if the SIP provider just supports a generic capability,
then the voicemail service provider is free to innovate and devise new
exciting services for you.

Voicemail is just an example.

The RFC3087 approach allows a SIP service provider to give their customers
clever and flexible ways of routing calls to a dumb service. The service
delivers exactly what is asked for in the URI.

The generic capability approach allows the service to contain the
intelligence, allowing the provider of the actual service to innovate and
develop clever and flexible services without placing requirements on the SIP
service provider, other than support of the basic generic capability.

I think we need both models to support a range of service provider types and
business models.

I would imagine that in practice the RFC3087 model will prevail at the start
for pure SIP voicemail servers, then as more SIP providers support the
generic capabilities the voicemail providers will overtake the SIP service
providers in terms of the features of their service.

Regards...Mark

---

From: Ben Campbell <[email-masked]>
Date: Tue, 19 Mar 2002 11:31:57 -0600

Mark Watson wrote:
> places to enter the address of your VM server for every scenario that 
> you consider to be different - or rather for every scenario that the VM 
> service provider is capable of considering as different.
> 
> So, you are limiting the voicemail service which can be provided based 
> on how flexible the SIP provider can be in the construction of the URI.
> 
> On the other hand, if the SIP provider just supports a generic 
> capability, then the voicemail service provider is free to innovate and 
> devise new exciting services for you.

I think that is where the philosopies separate. As a customer, I want to 
be able to devise my _own_ innovative services based on building blocks 
I get from a number of different service providers. In the case of a 
voice mail system, too much intelligence in the service endpoint 
_prevents_ me from doing that.

If we model the service as a series of logical "locations", and design 
our routing layer to allow maximum flexibility in the selection of those 
locations, the we can build systems where either I _or_ the service 
providers can design interesting services. These locations may or may 
not be collocated. This seems to be, almost by definition, the most 
fexible approach.

> The RFC3087 approach allows a SIP service provider to give their 
> customers clever and flexible ways of routing calls to a dumb service. 
> The service delivers exactly what is asked for in the URI.
> 
> intelligence, allowing the provider of the actual service to innovate 
> and develop clever and flexible services without placing requirements on 
> the SIP service provider, other than support of the basic generic 
> capability.
> 
> I think we need both models to support a range of service provider types 
> and business models.
> 
> I would imagine that in practice the RFC3087 model will prevail at the 
> start for pure SIP voicemail servers, then as more SIP providers support 
> the generic capabilities the voicemail providers will overtake the SIP 
> service providers in terms of the features of their service.
> 
> Regards...Mark
> 

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 19 Mar 2002 15:24:31 -0600

> the SIP service provider, other than support of the basic generic

This is a false dichotomy and a gross mis-characterization of RFC3087.

The argument I think you are trying to have is about service
decomposition and 3087 is agnostic on that point. In particular,
following the usage in 3087 has absolutely nothing to do with whether
you are talking to a "smart" or a "dumb" service. What it does talk
about is who owns the name (at least the form of the R-URI) when that
service is assembled, whether that administration and execution of that
service are separated or not. There are _other_ arguments we can have
about the impacts of that name ownership on provisioning, but the
argument this thread is currently engaged in is not one of them. 

Now, 3087 does also talk about coding "what I want done" into the RURI.
The simplistic examples in the draft seem to have led some people to
thinking you would only ever encode base primatives. If an element's
policy is "I want to run composite service foo on sip:A" and 
composite service foo provide no external stimulus hooks for activating
the components of the service, then passing sip:A to the composite
service and other data buried hither and yon (inband or out) does not
violate the spirit of 3087. The URI encodes what I want done to the
level the service provides an ability to express it.

So, lets return to the service decomposition argument. The motivations
driving this discussion as I understand them are

1) Some want to be able to build a composite service that does all kinds
of interesting stuff based on information in a SIP request other than
what's in the RURI. There is concern there that the SIP request isn't
providing enough information to do that, and a claim that the work that
it would take to put that in the RURI is prohibitively complicated.

2) Some want to be able to decompose that same composite service into
functional elements, some which provide decision logic, others which do
the legwork (possibly nesting these). There is concern there that the
ability to develop/deploy distributed services will be hindered by the
additional mechanisms being asked for by those in 1.

There are valid calls for being able to do both kinds of things and it
would shock me if everyone here didn't agree we should be able to do
both _AS LONG AS_ the mechanisms created to enable one does not prevent
reasonable development of the other.

The recent decoupling of the history requirements goes a long way
towards making sure we can find the right way to carry good information
without promoting a particular service architecture over another and
urge folks to focus on ensuring this property.

RjS

---

From: "Eric Burger" <[email-masked]>
Date: Tue, 19 Mar 2002 16:51:33 -0500

Beating the supine equine, this is what MSURI is about...

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Tuesday, March 19, 2002 4:25 PM
To: Mark Watson
Cc: 'Ben Campbell'; Mary Barnes; [email-masked]'; Sipping
Subject: RE: [Sipping] Comment on request history discussion

[snip]

[snip]