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

From: "Mark Watson"<[email-masked]>
Date: Thu, 23 May 2002 10:33:39 +0100

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

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 22 May 2002 19:52
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Question regarding Redirect reason and SIP
> 
> 
> Jason asked:
> ----
> Are there any generally accepted methods (SIPPING Work) regarding the
> passing of redirect reason information in SIP headers?  This 
> is specific
> to a voicemail scenario where the called party is on the internet and
> the call is forwarded to an internet call waiting service thus the
> service needs to known the reason for the forward.
> ----
> 
> People keep trying to come up with this approach because it's the
> obvious transformation from ISDN. 
> 
> Fortunately, SIP is significantly more expressive than ISDN, 
> so there's
> been a big push back against this rather naive approach.
> 
> 
> There are really two alternatives:
> 
> 
> 1) Use a generic URI for "the user" and encode a new header for every
> possible treatment that you might want to give the call. This requires
> writing lots of new standardized extension specifications.
> 
> 2) Have the URI include enough information so that the application can
> decide appropriate treatment. See RFC 3087. This doesn't 
> require writing
> lots of new standardized extension specifications.
> 
> If one uses alternative 2, there are two reasonable approaches:
> 
> 2A) Encode the functionality in the "user" part of the URI:
> 	sip:[email-masked]
>       sip:[email-masked]
> 
> 2B) encode the functionality in a URI parameter
>       sip:[email-masked];why=hewasbusy
>       
> Then there's a separate question as to whether either sort of encoding
> needs to be "standardized".
> 
> The good news is that the functionality is independent of the format,
> and the world continues to work well in a mixed-use model. All that is
> required is that the forwarding entity "know" what URL to retarget too
> for each of the condition cases that it wishes to distinguish. Whether
> this knowledge is provisioned or algorithmically generated is 
> a problem
> of local scope only.
> 
> --
> 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: Thu, 23 May 2002 16:19:17 -0500

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 23 May 2002 23:15:59 -0700

Dean, I disagree with your analysis of debate #1.

Oddly, I think we are both trying to meet the same goal of allowing proxies
to change where the call is going for reasons we never imagined and having
voice mail systems that can act in way never imaginable and making all this
stuff interoperate. In short we both agree, whatever it is you can do on a
ISDN voice mail system, it is way short of what one should be able to do
with SIP.

Part of the issue depends on where you expect some creative application to
happen. If you expect it to be in the proxy, and all you expect the voice
mail system to be is a thing that plays a single media prompt based on the
URI you give it, then the URI scheme seems like it sort of works. I have no
issue with URI being used to control media servers - I think that is a good
idea. If you expect the creative application to be implemented on the Voice
Mail system, perhaps several prompts into an evil voice jail system - then
it might be real nice to know the history of this call.

Are you seriously proposing that URI such as

send_this_call_to_cullens_voice_mail_and_you_can_suggest_that_they_can_try_b
ob_and_ted_but_don't_call_wendy's_home_phone_and_don't_try_alice_because_the
_call_already_went_to_her_office_phone_but_if_you_want_to_try_her_cell_that_
is_ all
right_unless_it_is_after_10pm_and_if_they_claim_it_is_really_important_they_
can_page_me_because_this_call_was_sent_to_my_cell_phone_and_people_who_have_
my_cell_phone_number_can_page_me

Are you suggesting that it is a simple matter of local configuration between
the proxies and the VM system to set up URI like this? If we go the URI
route, I think we will need to standardize the Uri's because there is no way
we are going to have reasonably deployable systems that interoperate if the
proxy and VM are from different vendors. What about when the VM prompt
change because of the I was forwarded twice, and the forwards happened by
proxies that belong to two different administrative domains.

What you refer to as "NO EXPLICIT LIMIT" I see as partially limited by
whatever some group of vendors can all agree to implement in a common way.
This might be great for vendors that have a full range of gateways, proxies,
phones, and unified messaging systems but it will suck for everyone else
including the service providers and end users. Personally, I don't see
History as being about reproducing ISDN limitations though it might help
with SIP/ISDN mappings which is not in it's self a bad thing. I see History
as about what happened to a call that might be useful for an application to
know. Like you, I see the URI as about what you want to happen next. It
seems clumsy to try and encode everything about what has happened in the
past into the URI. We could have encoded all the Via information into the
URI, but we didn't - and I'm glad we didn't.

Cullen

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dean Willis
> Sent: Thursday, May 23, 2002 2:19 PM
> To: 'Mark Watson'; [email-masked]; [email-masked]

---

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

> Oddly, I think we are both trying to meet the same goal of
> allowing proxies to change where the call is going for 
> reasons we never imagined and having voice mail systems that 
> can act in way never imaginable and making all this stuff 
> interoperate. In short we both agree, whatever it is you can 
> do on a ISDN voice mail system, it is way short of what one 
> should be able to do with SIP.

Yes, but the "diversion header" approach means the proxy never changes
where the call is going for any reason -- it just inserts one of a very
small number of predefined reason codes into the message and forwards it
to the same destination, independent of reason. The only applications
that can be invoked in this model are ones that correspond one-to-one
with the reason code. This is NOT a service-enabling technique -- it's a
dirty hack for front-ending crippled ISDN voice mailers in the laziest
possible manner. Wow, is it just me, or am I starting to sound like
Henry Sinnreich?

> Part of the issue depends on where you expect some creative
> application to happen. If you expect it to be in the proxy, 
> and all you expect the voice mail system to be is a thing 
> that plays a single media prompt based on the URI you give 
> it, then the URI scheme seems like it sort of works. I have 
> no issue with URI being used to control media servers - I 
> think that is a good idea. If you expect the creative 
> application to be implemented on the Voice Mail system, 
> perhaps several prompts into an evil voice jail system - then 

Or one could say:

Sip:[email-masked];avoid=bobandted@home,avoid=alice@office,avoid=wendy@
home

And the other stuff encoded in your absurd example is either policy
setting for your future calls (therefore out of scope here) or caller
preferences stuff which is also out of scope and should have been
executed by the proxy which is doing this forwarding application (such
as checking to see if it is after 10 before adding wendy's phone to the
list). In other words, you've mixed forward policy requests with
historical reporting.

> Are you suggesting that it is a simple matter of local
> configuration between the proxies and the VM system to set up 
> URI like this? If we go the URI route, I think we will need 
> to standardize the Uri's because there is no way we are going 
> to have reasonably deployable systems that interoperate if 
> the proxy and VM are from different vendors. What about when 
> the VM prompt change because of the I was forwarded twice, 
> and the forwards happened by proxies that belong to two 
> different administrative domains.

One could. Or one use request paremeters to accomplish the same thing.

> What you refer to as "NO EXPLICIT LIMIT" I see as partially
> limited by whatever some group of vendors can all agree to 
> implement in a common way. This might be great for vendors 
> that have a full range of gateways, proxies, phones, and 
> unified messaging systems but it will suck for everyone else 
> including the service providers and end users. Personally, I 
> don't see History as being about reproducing ISDN limitations 
> though it might help with SIP/ISDN mappings which is not in 
> it's self a bad thing. I see History as about what happened 
> to a call that might be useful for an application to know. 
> Like you, I see the URI as about what you want to happen 
> next. It seems clumsy to try and encode everything about what 
> has happened in the past into the URI. We could have encoded 
> all the Via information into the URI, but we didn't - and I'm 
> glad we didn't.

The problem is that "history" first appreaed to emerge as another
attempt to reintroduce the "diversion" header and just stealth it
through under a thin veneer of generality.

I'm not opposed to truly general uses of history. What I AM opposed to
is the "we can use history as an alternative to the Diversion header so
we can continue to use our broken ISDN voicemail systems and we can make
this a standard so that nobody will be able to innovate new services and
displace us" use of History. 

If you can find some way to define a History extension so that it
doesn't get abused this way, I'm with you!

This may be doable by expressing history in the terms of WHAT happened,
not WHY it happened.

For example, tracking things like "ted, bob, and alice have been tried
already" seems harmless, whereas "I am forwarding this to you because I
want you to apply the 'busy message" treatment'" is probably bad.

--
Dean

---

From: Steve Levy <[email-masked]>
Date: Fri, 24 May 2002 16:26:45 -0400

><snip>
>where the call is going for any reason

not true, the proxy can change the call based upon any service it is applying

>-- it just inserts one of a very
>with the reason code.

not true, the draft allows you to define a unique reason code for any 
application you want (or omit the reason code)

>This is NOT a service-enabling technique -- it's a
>possible manner.

you are certainly entitled to your opinion............

>Wow, is it just me, or am I starting to sound like
>Henry Sinnreich?

comparing yourself to Henry, now that is a stretch :-)

>  <snip>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 24 May 2002 17:10:13 -0400

Dean,

Boiling what you have said down, there seems to be three factors:

1) where the value-added information is placed (URI versus header)
2) whether it is to be standardized or not
3) whether it is a "what" or a "why".

The local part of the URI can only be trusted to work in the domain 
identified, so I assume that the burden is on the application in that 
domain to translate that value for the next domain that may need to use 
that information, or all other domains if forking is involved.

Your wish not to standardize the values was already noted.

As for the distinction in 3:
What happened?          User was busy
Why is this forwarded?  User was busy.
Don't see a distinction.  How do I distinguish between what and why?  I 
understand this better as a "this is what was tried and failed" hint rather 
than a policy decision on future untried termination attempts.

Was there anything else?

Mike