Subject: RE: [Sipping] Question regarding Redirect reason and SIP

From: "Mark Watson"<[email-masked]>
Date: Fri, 24 May 2002 10:38:02 +0100

Dean,

Apologies to everyone for the HTML messages - Setting Outlook to 'plain
text' does not actually stop this. I'm told setting message format to
UUENCODE does, so let me know if this message still offends (in the HTML
sense). (btw - don't blame me for choosing Outlook, I didn't).

On this issue, sure, approach (1) includes the Home Proxy requesting the
service on behalf of the user, but the service that is requested is still
decided in the user's home domain, and the service provision platform is
'dumb', just doing what it is told.

Just to be clear, I am NOT arging that this is a bad approach, or disputing
that it might be the best approach in a broad catagory of services. It DOES
enable the user and their Service Provider to develop innovative services by
building on a range of simple service building blocks and this is a massive
advantage over the PSTN model.

So, let's stop throwing round invective about 'service disablers' and
insults about lack of understanding.

Having said that, if I am a third-party service provider (i.e. I am not the
user's Home Proxy provider) and I want to offer value-add services to users,
then I can only use the information that SIP provides me to do this - that
is the constraint which limits the services I can provide. Unless you want
to limit innovation in this space, it makes sense for the protocol to
provide basic generic information about the handling of the call so far.

There are *already* services which could work this way with the information
already in the SIP protocol, so I cannot see why it should be a problem to
add other information, so long as it is not service-specific.

I really do not think it is acceptable to argue that the *only* place for
service intelligence is the user and Home Proxy and that third-party service
providers should be limited to 'doing what they are told' by these elements
- we are supposed to be developing an open system which will foster
innovation.

...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 23 May 2002 22:19
> To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Question regarding Redirect reason and SIP
> 
> 
> 
> Mark wrote:
> -----------
> I think we've discussed this at length on the list before. Do 
> we have to
> do it again ? 
> There are two broad approaches: 
> 1) User encodes service-specific information into Request-URI in order
> to request specific behaviour from a specific server (e.g. 
> the VM URI's
> that Dean gives below). The *user* is responsible for determining the
> specific behaviour that they want the service to provide.
> 2) User provides generic information in the SIP messaging, and routes
> the call to a more general service address. The *service* is 
> responsible
> for determining the specific behaviour based on the generic 
> information
> provided by the user.
> A key difference is the point at which the intelligence lies, user or
> service. This is the point at which innovation and development of the
> overall service can take place. If you want both client/proxy 
> providers
> and service engine providers to be able to innovate 
> independently, then
> you need to acknowledge both approaches and possibly mixtures.
> A key advantage of SIP is that it allows the former approach, so that
> users can build their own services out of simple building blocks. This
> does not mean that people building services should be limited 
> to *only*
> building small components - there is a market segment of users who do
> not want to 'build their own services' (or rely on client providers to
> do this).
> If you want to styme innovation on one side or the other, 
> then you could
> rule out one approach or the other. I don't think anyone presented a
> good argument to do this either way last time we discussed this.
> ...Mark 
> ------------
> 
> Mark, please set your emailer to do "plain text", not MHTML. I'm tired
> of having to reformat your stuff in order to argue with you, and I'm
> feeling mean today anyhow . . .
> 
> Apparently we must continue to debate this, as there seem to be some
> people who just don't get it.
> 
> 
> There are TWO different debates:
> 
> 1) Using forward knowledge or backward knowledge in service invocation
> 
> And 
> 
> 2) Theformat for encoding backward knowledge into SIP requests.
> 
> Even if you do #2, you can encode the backward knowledge (cause code)
> into a request parameter. This requires NO SIP EXTENSIONS, so if you
> REALLY WANT TO, you can SHOOT YOURSELF IN BOTH FEET WITHOUT OUR HELP.
> 
> 
> Furthermore, I think you mis-state approach #1. I might 
> reword this as:
> 
> "The home proxy (the proxy that is responsible for the
> address-of-record) selects a new Request-URI when it invokes 
> a service.
> We sometimes call this "retargetting" the request. For 
> example, when the
> home proxy invokes the service of forwarding a call to a registered
> contact, it rewrites the request URI with the value of the registered
> contact and forwards the request. When it chooses to invoke a service
> such as voice mail, it rewrites the request URI to one that 
> will produce
> the desired behavior from the voice mail system, such as a request URI
> for a "Busy, try back soon" or a "I've gone on vaction, don't 
> bother me"
> greeting. There is NO EXPLICIT LIMIT on the number of factors that can
> be considered in making a forwarding decision, and NO 
> EXPLICIT LIMIT on
> the sort of service that may be invoked as a result of that decision."
> 
> Note that this does not imply that it is only the USER who has this
> capability -- the service provider or systems integrator can 
> use it just
> as effectively.
> 
> The approach that you are suggesting EXPLICITLY LIMITS the range of
> expressivity to the set of cause codes defined in the 
> proposed "history"
> extension. This is not a service enabler, it is a service DISABLER
> driven by people who understand only the ISDN backward-knowledge model
> of service creation and has the side-effect of perpetuating 
> the crippled
> PSTN service model. Every time you want to do something different,
> you're going to have to go back to the well for a new 
> extension. If all
> you have in mind is replicating ISDN services, then you might be happy
> -- but I won't be. We're not here to build a mirror-image of ISDN over
> IP.
> 
> While there might be applications that can make reasonable use of a
> history mechanism, using such a mechanism to implement general purpose
> voice mail treatment selection is at best backward, retrograde, and
> childish, and is at worst a direct attempt to debase the SIP protocol
> definition in order to perpetuate the antiquated and 
> demonstrably flawed
> service model of the PSTN. 
> 
> In other words, I think it's a plain-and-simple BAD idea and will
> continue to "whack it" every time it pops up.
> 
> --
> 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

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 24 May 2002 14:27:32 -0500

Mark wrote:
> Apologies to everyone for the HTML messages - Setting Outlook 
> to 'plain text' does not actually stop this. I'm told setting 
> message format to UUENCODE does, so let me know if this 
> message still offends (in the HTML sense). (btw - don't blame 
> me for choosing Outlook, I didn't).

Most excellent formatting! I'm actually using Outlook myself at the
moment.

> On this issue, sure, approach (1) includes the Home Proxy 
> requesting the service on behalf of the user, but the service 
> that is requested is still decided in the user's home domain, 
> and the service provision platform is 'dumb', just doing what 
> it is told.
> 
> Just to be clear, I am NOT arging that this is a bad 
> approach, or disputing that it might be the best approach in 
> a broad catagory of services. It DOES enable the user and 
> their Service Provider to develop innovative services by 
> building on a range of simple service building blocks and 
> this is a massive advantage over the PSTN model.
> 
> So, let's stop throwing round invective about 'service 
> disablers' and insults about lack of understanding.

That's my "diversion header" rant -- see the previous response to Cullen
for more detail.

> 
> Having said that, if I am a third-party service provider 
> (i.e. I am not the user's Home Proxy provider) and I want to 
> offer value-add services to users, then I can only use the 
> information that SIP provides me to do this - that is the 
> constraint which limits the services I can provide. Unless 
> you want to limit innovation in this space, it makes sense 
> for the protocol to provide basic generic information about 
> the handling of the call so far.

Within reason, information about the handling f the call so far might be
reasonable. But even a thrid-arty service provider can add request-URI
parameters or retarget a call.
 
> There are *already* services which could work this way with 
> the information already in the SIP protocol, so I cannot see 
> why it should be a problem to add other information, so long 
> as it is not service-specific.

That's the trick.

> I really do not think it is acceptable to argue that the 
> *only* place for service intelligence is the user and Home 
> Proxy and that third-party service providers should be 
> limited to 'doing what they are told' by these elements
> - we are supposed to be developing an open system which will 
> foster innovation.

I certainly wouldn't suggest this. Third-party nodes have every right to
re-route, re-interpret, re-parameterize, and so on any request
transiting them.

The "diversion header" model inverts this completely -- at its most
extreme the third-party element AND the home proxy can do nothing but
insert cause codes, and it is left to the destination UA (a voice mail
system) to provide the application logic suggested by the cause codes.
This is bogus.

--
Dean