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

From: "Mary Barnes"<[email-masked]>
Date: Wed, 22 May 2002 12:45:28 -0500

Jason,

We are working towards a solution which could apply to your voicemail
scenario.  The requirements are specified in:
http://www.ietf.org/internet-drafts/draft-watson-sipping-req-history-01.txt

In the appendix, voicemail is given as an example as one of many
applications that could make use of a solution to these requirements. 

We had some good discussion on this draft at the SIP Interim meeting.  Refer
to the detailed minutes and the charts presented at:
http://www.softarmor.com/sipwg/meets/interim-may-02/index.html

This requirements draft will be updated soon to fully address the Security
and Privacy issues and then we'd like to progress the detailed solution work
given WG concensus on the requirements. 

Regards,
Mary H. Barnes 
IMS Solutions Standards Strategy 
ESN 444-5432 
Wireless 817-703-4806
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 11:16 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] Question regarding Redirect reason and SIP

Questions:
 
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.
 
Regards,
 
Jason Bach
Level 3 Communications
1025 Eldorado Blvd.
Broomfield CO 80021
Bus. (720) 888-2821
Mob. (720) 272-8698
mailto:[email-masked]

---

From: [email-masked]
Date: Wed, 22 May 2002 13:32:02 -0600

The reason for standardization is for interoperability between carriers. If
both endpoints are in the same network, then it is a local problem and can
be handled in numerous ways (as long as you don't have a mixture of
vendors). The problem comes when you have mixed networks and mixed vendors.
Without standardization, you will have too many variants to be
interoperable. If there is one standard way of mapping ISDN parameters to
SIP parameters/headers (without using SIP-T to encode the entire ISDN
message), then you can achieve interoperability. SIP is very extensible, but
that is only useful if all endpoints are aware of the extensions.

Thanks,
Rich Terpstra
Level (3) Communications
1025 Eldorado Dr.
Broomfield, CO 80021

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, May 22, 2002 12:52 PM
To: Bach, Jason; [email-masked]
Cc: Terpstra, Rich
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: "Sanjoy Sen"<[email-masked]>
Date: Thu, 23 May 2002 09:08:51 -0500

There're advantages and disadvantages to both:
1) doesn't need any new client capability, but without strong
control/guidelines on how these URI's are generated, this approach will
quickly lead to creation of URI's having local significance within an
operator network and will become an interoperability nightmare
2) , as Dean pointed out, needs creation of standard specifications to suite
different service needs. One example of such service need is to carry
call-history information (including the redirect reasons) to the service
endpoint (e.g., a voice-mail server). The requirements are in
http://search.ietf.org/internet-drafts/draft-watson-sipping-req-history-01.t
xt
<http://search.ietf.org/internet-drafts/draft-watson-sipping-req-history-01.
txt>  and the solution will be developed soon. 
 
Sanjoy

-----Original Message-----
From: Watson, Mark [MDN05:EP10:EXCH] 
Sent: Thursday, May 23, 2002 4:34 AM
To: 'Dean Willis'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Question regarding Redirect reason and SIP

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 

> From: Dean Willis [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: 22 May 2002 19:52 
> To: [email-masked]; [email-masked] 
> Cc: [email-masked] 
<https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Mary Barnes"<[email-masked]>
Date: Fri, 24 May 2002 16:25:05 -0500

Dean,

I've tried to refrain from adding my views to the list on this thread as I
don't like political or religious debates,  but I do have some specific
things that I would like to be certain are clear.  My comments are indicated
by [MB]/[end-MB} below:

Mary. 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, May 24, 2002 2:28 PM
To: 'Cullen Jennings'; [email-masked]; Watson, Mark [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Question regarding Redirect reason and SIP

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

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 
> 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_ali
> ce_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_i
> mportant_they_
> can_page_me_because_this_call_was_sent_to_my_cell_phone_and_pe
> ople_who_have_
> my_cell_phone_number_can_page_me

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.

[MB] There was really no stealth involved.  Yes, some of us did come into
this looking for a solution to a specific problem that we were faced with in
deploying SIP in a real network with existing real equipment that serves a
real function in today's network. And yes, we continue to use voicemail as
an example where one could use the Request History concept. We did try to
initially generalize the problem and evaluate it from the perspective of be
able to provide something that wasn't unique to this specific problem and
we've continue to provide other examples, however, everyone fixates on this
specific one. 
[end-MB]

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. 

[MB] I don't think this is a valid justification for blocking the progress
of the
Request History work.  I don't think the SIP or SIPPING WG is chartered to
be the protocol police and there's nothing anyone can do to stop people from
using headers to  interface to all flavors of non-SIP systems.  The problems
that we're all facing in the real world of deploying SIP is that there are
currently a myriad of different ways of interfacing to PSTN gateways,
voicemail servers, media servers etc.  It's very frustrating that we're
trying to follow the process (that 3GPP was so severely scolded for not
following initially) to bring fundamental requirements (and NOT how we want
to use SIP in a "broken" way) to the WG and folks continue to fixate on the
"broken" thing rather than on the requirements we're trying to discuss.  I
think 3GPP has clearly proven that there are going to be implementations of
SIP that don't match the IP purist view of the SIP world (whether they're
wireless specific, PSTN specific, etc.). We can all continue to use SIP in
the "broken" way and resolve interworking problems outside standards with
our 3rd party agreements or in other Standards organizations or we can get
to work to come up with fundamental SIP building blocks that can be used for
implementing many things by many other SDOs and vendors. 
[end-MB]

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.

[MB] I clearly don't see a problem with the WHY. The current view is that we
could use the new REASON header for this or existing SIP Response codes. Why
is "why" a bad thing?  
[end-MB] 

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: Gordon Ledgard <[email-masked]>
Date: Tue, 28 May 2002 12:07:16 -0400

I think Dean has himself hung up on PSTN hate. Which is not
a bad thing, mind you... but it's not helping this debate.

If you stop thinking about "History" or "Diversion" as existing
for the sake of VoiceMail systems, or ISDN mappings, and take
it at face value; i.e. a method for tracking what happened to
a session setup and why, it's actually a legitimate networking
mechanism.

And if that mechanism is flexible enough for the network to 
continually add new "reasons" to the fray as it grows and changes,
its a good thing. Elements no matter what their function in the
network can use this information as they please. There is no mandate
or even expectation of behavior being built in here.

The "History" or "Diversion" mechanisms also do not dictate a specific
network path as Dean implies. Its not true that the "proxy never changes
where the call is going" [sic]. The redirection of a call is entirely
up to the algorithm in the proxy acting on behalf of the caller,
and is not determined by the target (be it VM or my Grandma's 
home-brewed Linux SIP agent).

Now then, having said that, once this information is available in 
a SIP invitation, and there are some common, standardized reasons
I might take advantage of, why shouldn't I be able to build a home
brewed Linux SIP agent that engages differing behaviours based on
what those reasons were? That seems neither constraining, nor limited.

Three things have always bothered me about the "URI" method of invoking
services. In no particular order:

1) There is an implicit assumption using the URI method that the
element sending the INVITE to the service KNOWS what that service
is, and shapes its request accordingly, filling in reasons and parameters
and such in order to obtain some desired behaviour. This seems to 
me exactly the kind of binding of network and service that we are
all trying so hard to avoid. I do not wish to have a network be that
interdependent. I do not want to REQUIRE that a proxy "know" that it
is forwarding a message to voicemail or UM or anything else. And I
especially do not want that proxy to "know" what BRAND of UM is there.

Now in complete contrast to the above there may well be times when
the agent placing the call "knows" EXACTLY what service is being
invoked, and what it wants that service to do. Insuring this
capability is what provides the groundwork for the true "brave new
world" of SIP. But these are NOT contradictory goals. So long as
the initial intent of the caller can be preserved as the request
goes foward in the network, his/her service will not be lost. But
the elements in between, which may be forced to redirect that call,
should not stomp out that information by troding on the only record
of it (the URI in the URI model) that exists. Thus a proposed history
mechanism.

2) What happens when the route between the caller and the end service
runs through several intermediary services, perhaps provided by
different vendors? How does the original URI with its embedded, implicit
parameters and function requests get maintained as my call bounces
from a SIP portal to a Call Center Dispatcher to a Load balancing
distributor to my UM proxy? And each of these services "knows" what
the service at the next hop is? And how to encode its functions?
And how to preserve the functions of the service behind it "all
in this itty-bitty URI?" to paraphrase Bullwinkle? I think not.

3) I have always objected to the notion that it was OK to parameterize
behaviour in a URI; that it was OK to mix up control over the network
with control over an application. Its just Baaaaaaad. I'm at a loss
sometimes to understand why that's not obvious.

Gordon R. Ledgard
IPeria, Inc.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Friday, May 24, 2002 3:28 PM
To: 'Cullen Jennings'; [email-masked]; 'Mark Watson'
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] Question regarding Redirect reason and SIP

Or one could say:

--
Dean