Subject: RE: [Sip-implementors] Re: [SIP] Draft about diversion out of dat e

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 May 2001 03:19:22 -0400

Well, I've got a bunch of issues with this draft. So, lets take it from the
top.

Firstly, we have a process problem. There are now many implementations of
this extension, many of them under the apparent belief that this is going to
be an IETF standard.  Indeed, there is an I-D, which is being actively
maintained. However, it is not a work item of sipping or sip. To my
knowledge, there has not been consensus to move forward with CC-Diversion on
the standards track. According to the notes from IETF-49, there was only
"medium interest", for whatever thats worth. It doesn't have the
draft-ietf-sip-* name. Unfortunately, many other drafts don't have that
title, and yet they are on the standards track.  And thats the problem.

Just because something is submitted to IETF as an I-D, and maintained, does
not mean it is on the standards track, either through the working group, or
individually (and I'll note that very few individual drafts get approved on
the standards track). In fact, a very small fraction of the drafts submitted
ever see standards track. Unfortunately, the SIP group has not done a good
job of helping the community distinguish between documents on the standards
track, and those not on the standards track. The right way to do this is
that all standards track documents are draft-ietf-sip-*. If something new
comes up that people want to make standard, we get it on the charter, and
then rev the doc with a draft-ietf-sip-* name. Before that happens, the
document is NOT ON THE STANDARDS TRACK.

This process problem is not the fault of this draft, but the draft appears
to have brought it forward.

My second problem is the subtle implications this has with backwards
compatibility and interoperability with ISDN/ISUP systems, particularly
voicemail systems. The Diversion header is clearly just the SIP
reincarnation of the existing redirecting number from ISDN and ISUP. That,
of course, facilitates interoperability with ISDN/ISUP. However, it means
that gateways may not properly set the redirecting number in ISUP/ISDN in
the absence of the Diversion header. Similarly, SIP-enabled systems that
look for the Diversion header to define services may not function properly
in the absence of Diversion. As a result of that, Diversion basically
becomes mandatory for these to work. Unfortunately, this appears to have
occurred in some implementations and deployments already. Since proxies are
the ones that insert Diversion, this means that Diversion would require a
Proxy-Require header to function. In fact, its far more insidious than that.
A UAC would need to insert a Proxy-Require in each and every request, not
because the UAC wants a service, but because the call might possibly,
someday, hit a downstream system which uses Diversion. 

Extensions that need Proxy-Require to function are effectively non-backwards
compatible extensions. See draft-ietf-sip-guidelines on why its very, very
bad. May as well call them another protocol, since they are not compatible
with baseline SIP.

Now, this problem is fixable. As Allison has mentioned during IETF 50, all
extensions henceforth MUST describe how backwards compatibility operates.
Therefore, the draft MUST describe how gateways, voicemail servers, and
anything else that looks at Diversion, would work in its absence. 

However, the issue with Proxy-Require is related to an architectural
assumption which I strongly disagree with. The underlying architectural
assumption is that applications on behalf of user A will execute on some
system far downstream from user A. These applications depend on data known
to the proxy that serves A, and therefore this data must be passed to the
application. The Diversion header exists to propagate this information. This
is effectively a centralized service architecture. In a more distributed
system, if I want an application to run on behalf of user A, I run it at the
server which serves user A.

Let me be concrete, with an example. Lets take the interesting scenario
where user X calls boss B. Boss B is not available, so the call gets
forwarded to the secretary S. The secretary is S also not available, so the
call is forwarded to voicemail. An application on the voicemail server,
executing on behalf of boss B and secretary S, determines that the the
voicemail for the boss, not the secretary, should be dropped. Now, if I
assume that this application exists in the voicemail server, downstream from
the caller, then of course some kind of information on this diversion must
be passed to the server.

However, no new extension is needed if a more distributed approach is taken.
When the call reaches the proxy for B, the application for B resides there.
It proxies the call to the proxy for S, and sets the Request-Disposition
header to redirect. The proxy for S runs an application on behalf of the
secretary. This application forwards to voicemail if the secretary is
unavailable. Because of the Request-Disposition, the call is redirected to
voicemail rather than being proxied. This moves control for the call back to
the boss, B. The bosses application decides instead to forward the call to
the boss's voicemail, and so proxies the call to a URI corresponding to the
voicemail drop for the boss. This works just fine, and requires no new
extensions.

Another spin on this is to view it as a feature interaction problem. The
boss wants to forward to his secretary if he is there, otherwise to his own
voicemail if the secretary is not available. The secretary wants to forward
the call to his voicemail if he's not available. These two features are
contradictory, and thus interact with each other. Since the secretary and
boss are served by (potentially) separate proxies, we have a classic MUMC
(multiple-user, multiple-component) interaction. The Diversion approach is
to assume that we can reconcile all these interactions by somehow having
"policy" at the endpoint server. This policy knows what the right
reconciliation is for all potential interactions, assuming it has all the
data it needs. To obtain this data (here, the set of diversions), the data
is passed from the proxies along the path to the application. My concern is
this "magical" assumption that policy on the server will know the right
thing to do in order to reconcile all feature interactions.

Rather than take this approach, a more robust feature interaction approach
is to let the feature for the boss, and the feature for the secretary, run
independently. The feature for the boss runs on the boss's proxy (or
application server). The feature for the secretary runs on the secretary's
proxy (or application server). The two applications know nothing about each
other, and run independently. The bosses application runs first. It "wins"
the feature interaction if it maintains control of the call. The secretary's
application "wins" if it keeps control of the call after the boss forwards
it. As a result, the reconciliation between the features is determined by
the ordering of the invocation of these two, and the flow of control between
them. This is the approach proposed by modern feature interaction systems,
such as Distributed Feature Composition (DFC) and ECLIPSE, and the recent
I-D on SERL [draft-steenfeldt-sip-serl-fwr-00.txt]. All of these are based
on the well-known "cascaded" approach to feature interaction in the IN. Its
also the same as the approach I proposed above using Request-Disposition.
There are many advantages to this approach. It does not require passing
additional information to third party components to perform feature
interaction reconciliation. As a result, there are no security risks (since
no information is divulged), as there are with the Diversion approach.
Managing the feature interactions is easy. As new users are added, we don't
need to program a single system with the interactions between that user's
features, and the features of existing users, as we do in the Diversion
approach. We do not need an extension, since no new information is being
passed between applications. The diversion approach requires an extension.

This distributed approach is also the one advocated by rfc3087, and by
draft-rosenberg-sip-app-components. RFC3087 talked about access to SIP
voicemail features, using the request URI as a service identifier.

So, my point here is that Diversion is needed only under a very specific
architectural model. This model has well known feature interaction
complications, which are resolved readily in a more distributed model.
Furthermore, the distributed approach is more secure and requires no
extension. 

Onto the next issue.

I believe the point was made that Diversion simplifies PSTN
interoperability. If a request has been diverted in the PSTN, we can carry
the PSTN diversion information in SIP in the Diversion headers. This way, we
can design SIP enabled systems that provide servers to PSTN endpoints,
without loss of information. However, we've talked about this issue for a
long time. The SIP group has already decided that instead of defining each
ISUP/ISDN header as a SIP header, we will encapsulate these PSTN messages as
bodies, and use SIP-T. That means we can still build SIP enabled systems
that provide services to PSTN users, without loss of information, yet we can
avoid replicating each ISUP header into SIP. 

OK, now to some nitty gritty issues I have with Diversion. It says that the
proxies only insert the Diversion header when the call is diverted, which is
defined as:

diversion:      A change to the ultimate destination endpoint
                    of a request.  A change in the Request-URI of a
                    request that was not caused by a routing decision.
                    This is also sometimes called a deflection or
redirection.
A diversion can occur when the "user" portion of the
                    Request-URI is changed for a reason other than
                    expansion or translation.

Now, I would be really impressed if someone can tell me how to program a
proxy to know the difference between a routing decision that changes the
ultimate destination, and one that does not. In SIP, we make no distinction
between the two. So, effectively, every single proxy or redirect operation
will require the insertion of this Diversion header. This means another set
of stacked headers, of exactly the same length as the Via headers. That
significant overhead, and its additional processing. Furthermore, every
proxy would need to do it for each and every call, since they don't know
whether the ultimate recipient will need to make use of Diversion to provide
some services. 

The final concern I have is a "slippery slope" argument. Effectively,
Diversion is about encapsulating a routing decision made at point A, and
sending it to a downstream device. Right now, Diversion handles routing
decisions such as call-forward-no-answer, call-forward-busy, unconditional,
and so on. However, in practice, the logic for a call diversion can be
arbitrarily complex. What if its some complex CPL script that caused the
diversion? How do I represent that kind of logic? Where do we draw the line?
The problem is avoided by not trying to transfer this kind of information in
the first place. If an application requires routing information on proxy A
to function, then the application runs at A.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Bryan Byerly [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2001 5:33 PM
> To: Igor Slepchin
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [Sip-implementors] Re: [SIP] Draft about diversion 
> out of date
> 
> 
> Hi Igor,
> 
> I've attached an additional example of a scenario that you've 
> requested.
> 
> Please see other responses inline.
> 
> thanks for your help,
> Bryan
> 
> Igor Slepchin wrote:
> 
> > > -----Original Message-----
> > > From: Bryan Byerly [mailto:[email-masked]]
> > >
> > > As I presented at the December 2000 IETF, the I-D is
> > > motivated by several
> > > PSTN/SIP internetworking scenarios including:
> >
> > I'd like to see what internetworking scenarios don't work 
> without it.
> 
> I've attached one such example.
> 
> > > Multiple diversions.
> >
> > Hmm, these are not really supported by PSTN. Just as your 
> draft says, the
> > only information available in ISDN parameters are the 
> called party and the
> > redirecting number. Nowhere does PSTN remember all the 
> previous redirections
> > like suggested by the draft.
> 
> Actually, as the Diversion I-D points out, most ISUP and ISDN 
> variants support
> up to 2 redirecting numbers.  Could you point out the part of 
> the Diversion
> I-D that led you to believe there could be only one?  We'd 
> need to clarify that
> section.
> 
> > > Diverting a call to an E.164 service.
> >
> > What services is Diversion header required for? There are 
> lots of obscure
> > parameters in PSTN signaling; replicating all of them in 
> SIP does not sound
> > like a very good idea and is not necessary for internetworking.
> 
> The Diversion I-D is focused on answering 2 questions for the 
> (ultimately)
> called user agent:
> From whom was the call diverted?
> Why was the call diverted?
> 
> Implementations of services such as voicemail and night 
> service frequently
> require this information.
> 
> > > Configuration issues (moving policy configuration to edges (UAs))
> > >
> > > An ultimately called UAS can use the Diversion headers to
> > > implement a local
> > > policy for his particular service.  For example, to answer
> > > the question:
> > > Into which voice mailbox should a message be placed?  It's
> > > important to
> > > understand that this is a policy decision; and as such should be
> > > configurable at the ultimate edge of the voice network (i.e.
> > > move the smarts
> > > to the edges).  The examples in section 9 do cover some of
> > > these issues.
> >
> > I find examples in section 9 rather farfetched. No company 
> is ever going to
> > have SIP addresses that look like sip:[email-masked] 
> (when was the last
> > time you saw a real company with an email account at aol.com?)
> > Realistically, the night service calls you mentioned will 
> be redirected to
> > something like [email-masked] or [email-masked].
> 
> The example shows translation of a generic keyword (pizza) 
> into a specific URL
> as determined by the policy of the "carrier".  Today's web brower
> "carriers" already exhibit this type of behavior today.  Try 
> typing "pizza" in
> your web browser...  I wouldn't be surprised if the topmost 
> hits weren't
> somehow compensating the web browser "carrier".  I'd imagine 
> that tomorrow's
> VoIP carriers could base some business models off of this idea.
> 
> Again, please also see the attached example below.  Perhaps 
> it will seem more
> realistic.
> 
> The Diversion header is merely providing supplementary 
> information that cannot
> always be found in any other parts of the SIP PDU.  
> Implementors of some
> services (including voicemail and nightservice) need a consistent
> (standardized) mechanism to retrieve this supplementary 
> information so that
> they can apply policy decisions to it to affect their service 
> logic.  The
> Diversion header provides such a mechanism and does so 
> without creating a
> configuration burden on system administrators of intermediate 
> gateway/routing
> nodes.
> 
> thanks again for your help,
> Bryan
> 
> Bryan J. Byerly
> [email-masked]
> 
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 May 2001 08:56:46 -0400

To add (or probably just rephrase): In the voicemail case, leaving the
decision to the secretary's proxy is also not the right thing. How is
the secretary to know what to do? After all, there may well be cases
where the secretary *should* get the voicemail, since S may be the one
that can actually access it in time. Indeed, by infering intent from
route, I can get myself into the situation that I want to avoid talking
to B's voicemail (since I know B can't or won't pick it up) and instead
want to either get B directly or talk to S. If I rely on diversion, I
will inevitably end up in B's mailbox.

Thus, the mere indication of diversion provides insufficient clarity as
to the intent of the caller or any intermediate parties for further
handling of the request.

On the other hand, B's proxy can make this decision, since it's B's
call.

Thus, this is also an example of explicit vs. implicit. In the old phone
system, we could only express things implicitly ("because these things
happened, the caller must have meant to do X").

Also note that for the most common case, we already have the most
important information, namely the caller-intended destination, in the To
header.

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 16 May 2001 12:09:03 -0400

Hi Jonathan,

Thank you for your responses.  I appreciate discussion on the Diversion I-D.
Comments are in-line.

Jonathan Rosenberg wrote:

<snip>

> The Diversion header is clearly just the SIP
> becomes mandatory for these to work.

I think you've just made the case for the Diversion header.  ;^)

>  Since proxies are
> Proxy-Require header to function.

A small nit, both proxies and user agent servers end up inserting the Diversion
header.  Smart user agent servers are able to implement call forward services
locally (without any assistance from a proxy).  There are examples of both
(proxy and UAS) diversion scenarios in Section 7 of the Diversion I-D.

I agree that Proxy-Require headers are an evil source of protocol
incompatability.  However, in the instance of the Diversion header, no
Proxy-Require header is needed.  The Diversion header is supplemental
information.  If a SIP proxy involved in a PSTN call doesn't add it, the worst
that will happen is that the customer expected behavior may not occur and
customers may complain until such time that the expected behavior is achieved.

<snip>

> bad. May as well call them another protocol, since they are not compatible

Again, this is a strawman argument.  Although I agree that Proxy-Require
headers cause compatability problems, Diversion does not require use of a
Proxy-Require header.

> anything else that looks at Diversion, would work in its absence.

So, the backward compatibilty issue is that this supplemental information was
not provided in the past.  Thus, services relying on this supplemental
information didn't work in the past.

<snip>

To summarize, there appear to be two models.  In the first model, (voicemail)
service policy is controlled at the user-agent server (Diversion I-D).  In the
second model, (voicemail) service policy is controlled at intermediate SIP
proxies or gateways (RFC3087).  In SIP-only networks or small networks, where
the SIP/PSTN gateway, SIP proxy, and SIP voicemail server are all owned and
administrated by the same domain, either model can work.

However, as networks scale up, ownership and connectivity of the devices
spreads out.  Here's an example that causes problems for RFC3087, but is simply
solved by supporting Diversion:

=====================
Scenario 1: Off-net diversion
=====================

In the following ladder diagram, a call is placed from the PSTN to 5551234
which hangs off of the 555xxxx PBX.  The Call Forward No Answer (CFNA) timer
expires in the PBX, and the PBX diverts the call to the user's admin/secretary
at 5551001.  The secretary's phone is busy, so the PBX diverts the call through
the local PSTN/SIP gateway and SIP proxy to the voicemail service with which
the enterprise has contracted, in this case a SIP voicemail service.  The SIP
proxy performs an (ENUM) lookup of 9231000 which resolves to 3.3.3.3.

When the call reaches the voicemail server, the message may be deposited into a
voice mailbox for 5551234, 5551000, or both depending on the configured policy.

In addition, in practice one would normally encounter scenarios where the SIP
proxy is owned by a carrier and the voicemail server by a third party.  In this
example, usage of the Diversion header allows voicemail service policy to be
changed (by the voicemail provider) without requiring changes in the carrier's
equipment.

RFC3087 approach:
--------------

Voicemail policy configuration-++
                               ||
                               ||
                               \/
                        |<---------carrier A-------->|<-Voicemail vendor X->|
                 (555xxxx)                                 (9231000)
                           (1.1.1.1)      (2.2.2.2)        (3.3.3.3)
PSTN              PBX         GW           SIP Proxy   SIP voicemail server
|                  |           |                |              |
|--Setup---------->|           |                |              |
|  called:5551234  |           |                |              |
|                  |           |                |              |
|<-Call Proceeding-|           |                |              |
|                  |           |                |              |
|<-Alerting--------|           |                |              |
|                  |           |                |              |
|          CFNA timer expires  |                |              |
|                  |           |                |              |
|              ----|           |                |              |
|            /   Call presented to 5551001 (admin)             |
|            \     |           |                |              |
|             ---->|           |                |              |
|                busy          |                |              |
|                  |           |                |              |
|                  |--Setup--->|                |              |
|                  |  called: 9231000           |              |
|                  |  1st Redirection: 5551234  |              |
|                  |    reason=cfna             |              |
|                  |  2nd Redirection: 5551001  |              |
|                  |    reason=cfb              |              |
|                  |  counter=2                 |              |
|                  |           |                |              |
|                  |           |--INVITE ------>|              |
|                  |(Request-URI) sip:[email-masked];user=phone
|                  |           |  To: [email-masked]
|                  |           |                |              |
|                  |           |        routing lookup (eg. ENUM)
|                  |           |        (9231000->3.3.3.3)
|                  |           |                |              |
|                  |           |                |--INVITE ---->|
|                  |           |     (Request-URI)
sip:[email-masked]
|                  |           |                |  To: [email-masked]
|                  |           |                |              |
|                  |           |                |<-200---------|
|                  |           |<-200-----------|              |
|                  |           |--ACK------------------------->|
|                  |<-Connect--|                |              |
|<-Connect---------|           |                |              |
|                  |           |                |              |

In this approach, every carrier's PSTN/SIP GW would need to be configured with
voicemail vendor X's service policy.  For N voicemail service vendors, there
would need to be (at least) N policy rules in each PSTN/SIP GW.  Assuming
voicemail service policy which is configurable per-user, there would be the sum
(from 1 to NumVoicemailVendors) of the number of users of each voicemail
vendor:

NumVoicemailVendors
--
\      NumUsers(i)
/
--
i=1

As the number of (voicemail) service vendors increases, the complexity of this
policy configuration at _every_ PSTN/SIP GW increases.

Diversion I-D approach:
------------------

Voicemail policy configuration----------------------------------++
                                                                ||
                                                                ||
                                                                \/
                        |<---------carrier A--------->|<-Voicemail vendor X->|
                (555xxxx)                                     (9231000)
                           (1.1.1.1)      (2.2.2.2)           (3.3.3.3)
PSTN              PBX         GW           SIP Proxy     SIP voicemail server
|                  |           |                |                |
|--Setup---------->|           |                |                |
|  called:5551234  |           |                |                |
|                  |           |                |                |
|<-Call Proceeding-|           |                |                |
|                  |           |                |                |
|<-Alerting--------|           |                |                |
|                  |           |                |                |
|          CFNA timer expires  |                |                |
|                  |           |                |                |
|              ----|           |                |                |
|            /   Call presented to 5551001 (admin)               |
|            \     |           |                |                |
|             ---->|           |                |                |
|                busy          |                |                |
|                  |           |                |                |
|                  |--Setup--->|                |                |
|                  |  called: 9231000           |                |
|                  |  1st Redirection: 5551234  |                |
|                  |    reason=cfna             |                |
|                  |  2nd Redirection: 5551001  |                |
|                  |    reason=cfb              |                |
|                  |  counter=2                 |                |
|                  |           |                |                |
|                  |           |--INVITE ----------------------->|
|                  |(Request-URI) sip:[email-masked];user=phone
|                  |           |  To: [email-masked]
|                  |           |  Diversion:
<sip:[email-masked];user=phone>;reason=cfb,
|                  |           |
<sip:[email-masked];user=phone>;reason=cfna
|                  |           |                |                |
|                  |           |        routing lookup (eg. ENUM)
|                  |           |        (9231000->3.3.3.3)       |
|                  |           |                |                |
|                  |           |                |--INVITE ------>|
|                  |           |     (Request-URI) sip:3.3.3.3;user=ip
|                  |           |                |  To: [email-masked]
|                  |           |                |  Diversion:
<sip:[email-masked];user=phone>;reason=cfb,
|                  |           |                |
<sip:[email-masked];user=phone>;reason=cfna
|                  |           |                |                |
|                  |           |                |<-200-----------|
|                  |           |<-200-----------|                |
|                  |           |--ACK--------------------------->|
|                  |<-Connect--|                |                |
|<-Connect---------|           |                |                |
|                  |           |                |                |

With this approach, no policy configuration in the SIP GW or SIP proxy is
needed.  Each voicemail service vendor locally configures the desired policy.

====================================
Scenario 2: Diversion to Off-net voicemail server
====================================

In the following ladder diagram, a call is placed from a SIP user agent (UA1)
to 5551111.  The SIP proxy resolves this to another SIP user agent (UA2).  The
Call Forward No Answer (CFNA) timer expires in the SIP proxy, and the SIP proxy
diverts the call to the user's admin/secretary at 5551112.  The secretary's
phone is busy, so the SIP proxy diverts the call through the local SIP/PSTN
gateway to a PSTN voicemail service.

When the call reaches the voicemail server, the message may be deposited into a
voice mailbox for 5551234, 5551000, or both depending on the configured policy.

In addition, in practice one would normally encounter scenarios where the SIP
proxy and SIP GW is owned by a carrier and the voicemail server by a third
party.  In this example, usage of the Diversion header allows voicemail service
policy to be changed (by the voicemail provider) without requiring changes in
the carrier's equipment.

RFC3087 approach:
--------------

Voicemail policy configuration---++
                                 ||
                                 ||
                                 \/
                       |<---------carrier A--------->|<-Voicemail vendor X->|
                                                           (666xxxx)
      (5551111) (5551112)  (1.1.1.1)     (2.2.2.2)
UA1    UA2      UAS3       SIP Proxy     SIP/PSTN GW   PSTN voicemail server
|       |         |              |              |                  |
|--INVITE ---------------------->|              |                  |
|  sip:[email-masked];user=phone               |                  |
|       |                        |              |                  |
|       |<-INVITE----------------|              |                  |
|       |  sip:5551111@UA2;user=phone           |                  |
|       |         |              |              |                  |
|       |--180------------------>|              |                  |
|       |         |              |              |                  |
|<-180---------------------------|              |                  |
|       |         |              |              |                  |
|       |         |       CFNA timer expires    |                  |
|       |         |              |              |                  |
|       |         |<-INVITE------|              |                  |
|       |         |  sip:5551112@UA3;user=phone |                  |
|       |         |              |              |                  |
|       |         |--486-------->|              |                  |
|       |         |            CFBusy           |                  |
|       |         |              |--INVITE----->|                  |
|       |         |              |  sip:[email-masked];user=phone |
|       |         |              |              |                  |
|       |         |              |              |-Setup----------->|
|       |         |              |              | called:6661112   |
|       |         |              |              |                  |
|       |         |              |              |<-Call Proceeding-|
|       |         |              |              |<-Alerting--------|
|       |         |              |<-180---------|                  |
|<-180---------------------------|              |                  |
|       |         |              |              |<-Connect---------|
|       |         |              |<-200---------|                  |
|<-200---------------------------|              |                  |
|--ACK----------------------------------------->|                  |

Here's a second call, using the same voicemail server:

Voicemail policy configuration---++
                                 ||
                                 ||
                                 \/
                       |<---------carrier A-------->|<-Voicemail vendor X->|
                                                           (666xxxx)
                           (1.1.1.1)     (2.2.2.2)
UA3    UA4      UAS5       SIP Proxy     SIP/PSTN GW   PSTN voicemail server
|       |         |              |              |                  |
|--INVITE ---------------------->|              |                  |
|  sip:[email-masked];user=phone               |                  |
|       |                        |              |                  |
|       |<-INVITE----------------|              |                  |
|       |  sip:5551114@UA4;user=phone           |                  |
|       |         |              |              |                  |
|       |--180------------------>|              |                  |
|       |         |              |              |                  |
|<-180---------------------------|              |                  |
|       |         |              |              |                  |
|       |         |       CFNA timer expires    |                  |
|       |         |              |              |                  |
|       |         |<-INVITE------|              |                  |
|       |         |  sip:5551115@UA3;user=phone |                  |
|       |         |              |              |                  |
|       |         |--486-------->|              |                  |
|       |         |            CFBusy           |                  |
|       |         |              |--INVITE----->|                  |
|       |         |              |  sip:[email-masked];user=phone |
|       |         |              |              |                  |
|       |         |              |              |-Setup----------->|
|       |         |              |              | called:6661115   |
|       |         |              |              |                  |
|       |         |              |              |<-Call Proceeding-|
|       |         |              |              |<-Alerting--------|
|       |         |              |<-180---------|                  |
|<-180---------------------------|              |                  |
|       |         |              |              |<-Connect---------|
|       |         |              |<-200---------|                  |
|<-200---------------------------|              |                  |
|--ACK----------------------------------------->|                  |

In this approach, the voicemail server must own a block of E.164 numbers (one
per subscriber).  For N voicemail service subscribers, the voicemail server
would need to own N E.164 numbers.  As the numbers of subscribers increases,
this may become a significant cost-issue for the voicemail service vendor.

Also notice that, in this approach, voicemail service policy is configured in
the carrier's SIP proxy.

Diversion I-D approach:
------------------

Voicemail policy configuration------------------------------------++
                                                                  ||
                                                                  ||
                                                                  \/
                         |<---------carrier A------->|<-Voicemail vendor->|
                                                          (66622222)
      (5551111) (5551112)  (1.1.1.1)     (2.2.2.2)
UA1    UA2      UAS3       SIP Proxy     SIP/PSTN GW  PSTN voicemail server
|       |         |              |              |                  |
|--INVITE ---------------------->|              |                  |
|  sip:[email-masked];user=phone               |                  |
|       |                        |              |                  |
|       |<-INVITE----------------|              |                  |
|       |  sip:5551111@UA2;user=phone           |                  |
|       |         |              |              |                  |
|       |         |       CFNA timer expires    |                  |
|       |         |              |              |                  |
|       |         |<-INVITE------|              |                  |
|       |         |  sip:5551112@UA3;user=phone |                  |
|       |         |  Diversion: <sip:[email-masked];user=phone>;reason=cfna
|       |         |              |              |                  |
|       |         |--486-------->|              |                  |
|       |         |            CFBusy           |                  |
|       |         |              |--INVITE----->|                  |
|       |         |              |  sip:[email-masked];user=phone |
|       |         |              |  Diversion:
<sip:[email-masked];user=phone>;reason=cfb,
|       |         |              |
<sip:[email-masked];user=phone>;reason=cfna
|       |         |              |              |                  |
|       |         |              |              |-Setup----------->|
|       |         |              |              | called:6662222   |
|       |         |              |              | 1st Redirection: 5551111
|       |         |              |              | 2nd Redirection: 5551112
|       |         |              |              |                  |
|       |         |              |              |<-Connect---------|
|       |         |              |              |<-Call Proceeding-|
|       |         |              |              |<-Alerting--------|
|       |         |              |<-180---------|                  |
|<-180---------------------------|              |                  |
|       |         |              |              |<-Connect---------|
|       |         |              |<-200---------|                  |
|<-200---------------------------|              |                  |
|--ACK----------------------------------------->|                  |

With this approach, the voicemail vendor only needs one E.164 number and no
policy configuration in the carrier's SIP GW or SIP proxy is needed.  Each
voicemail service vendor locally configures the desired policy.

* I would really appreciate voicemail vendors (and voicemail equipment
manufacturers) speaking up on this issue.  Are you actually willing to depend
on your carrier to configure your service policy (per RFC3087)?  Are you
willing to wait for your carrier to deploy equipment that can configure the
service policy?  When your carrier misconfigures your service policy, who will
your customers blame?  What incentive will the carrier have to fix the problem
in a timely fashion?  Wouldn't you rather be in control of your own policy
(using a mechanism such as the Diversion I-D)?

* I would also appreciate feedback from carriers (and carrier equipment
manufacturers).  Per RFC3087, do you really want to have to change the policy
in all of your domain's border (GW and proxy) nodes everytime a third-party
(voicemail) service customer wants to change a service policy for one of their
customers?  What incentive do you have to update this policy in a timely
manner?  What incentive do you have to deploy equipment to support third-party
policy configuration?  Wouldn't you rather the (voicemail) service vendors
just  manage their own policy (using a mechanism such as the Diversion I-D)?

> avoid replicating each ISUP header into SIP.

If PSTN calls use SIP only for backbone signalling, the SIP-T encapsulation
approach is fine.  However, when terminating SIP calls on PSTN networks, or
PSTN calls on SIP networks, a translative approach is needed to achieve the
expected behavior.

Although I'm not advocating replicating every ISUP header in SIP, I don't see
anything wrong with using equivalent (or a superset) of functionality of useful
ISUP headers.  A case-by-case approach seems appropriate to me.  Regardless,
this draft's sole focus is Diversion information.

> between the two.

One suggestion is to apply the same algorithm that we use for spiral loop
detection.  If the user portion of the (sip:user@host) URL does not change,
then consider it a simple routing decision (that does not require a Diversion
header).  If the user portion of the (sip:user@host) URL does change, then add
a Diversion header.

> So, effectively, every single proxy or redirect operation

As I've described above, this argument does not apply.  If the user portion of
the URL changes, add a Diversion header.  If the user portion of the URL
doesn't change, don't add a Diversion header.

> diversion? How do I represent that kind of logic? Where do we draw the line?

If several features such as CFB, CFNA, CFTOD are defined in one CPL script,
then the script would be capable of marking any one of 3 reasons (cfb, cfna,
cftod) depending on which scenario was encountered.  If the script truly has a
new reason, then define a new reason code.  This argument is akin to asking how
many response codes should be defined in SIP.  The answer is to define the ones
that you need, and don't define any more than you need.

thanks for your help,
Bryan

Bryan J. Byerly
[email-masked]

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 16 May 2001 12:44:14 -0400

Hi Henning,

I appreciate your responses.  Please see comments inline.

> happened, the caller must have meant to do X").

Whether the SIP proxy, GW (using RFC3087), or user-agent server (using
Diversion I-D) is making the policy decision, the same incoming information
is being used to apply the policy, namely the request-URI (and diversion
reason) at the time the call was diverted.

> important information, namely the caller-intended destination, in the To

RFC3087 and the Diversion I-D both agree that the To: header cannot always
be used.

Here's an excerpt from RFC3087 on this matter, Section 3.1.2.1, paragraph
2:
An application designer may be tempted to attempt to match the To:
   and From: headers on a call to infer information.  However, this
   approach could cause complications when multiple proxy forwards occur
   in a call.  For example, A calls B, who has all calls forwarded to C.
   C forwards the call to her voice mail service.  If the voice mail
   service matches the To: header to determine the message store, it
   will get the information for B instead of C.  But there is no reason
   to assume that C's voice mail service has any knowledge of B.

Here's an excerpt from draft-levy-sip-diversion-02.txt, Section 9.3:
    Question 1:
        Why do we need the Diversion header when we can see the To: header?

    Answer:
        a) The To: header is not guaranteed to have significance
           to the called party.

           For example, the To: header may contain a locally significant
           URL (to the caller) such as a private numbering plan,
           speed dial digits, telephony escape digits, or
           telephony prefix digits.

           Without a Diversion header, enumerating all possible locally
           significant To: headers that anyone might use to contact
           [email-masked] becomes a configuration problem at
           [email-masked] and is prone to namespace collision.

           Support for Diversion headers enables Bob to contract
           a third-party service ([email-masked]) with a single
           globally significant URL for his voice mailbox
           ([email-masked]).

Even if the To: header contained the relevant information 98% of the time;
customers would certainly complain about the 2% of the time that a To:
header dependent implementation failed to provide the expected behavior.

Bryan J. Byerly
[email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 16 May 2001 13:54:12 -0400

> reason) at the time the call was diverted.

The point is that Diversion is neither useful nor required for this
service. Indeed, it only encourages the old-style implict service model.
If it's not useful, it doesn't need to be standardized.

>    to assume that C's voice mail service has any knowledge of B.

The whole point is that B should remain in control of the call, since it
is the designated location. The Diversion header does not help at all in
clarifying intent by any of the parties involved.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 16 May 2001 14:08:15 -0400

Hi Henning,

> clarifying intent by any of the parties involved.

This is appears to be an underlying assumption at which we're diverging.  When
control of the call is diverted (to a new user), we're assuming that control of
the called leg is transferred to that new user.  I believe that you're assuming
that control of the call remains with the original user.

Without an agreement on this assumption, I believe that we'll have to agree to
disagree.

Bryan J. Byerly
[email-masked]

---

From: Bryan Byerly <[email-masked]>
Date: Wed, 16 May 2001 14:28:53 -0400

> If it's not useful, it doesn't need to be standardized.

I've pointed out several scenarios where the Diversion header is useful and
preferable for (voicemail) service vendors.  Please refer to the responses to
Jonathan's note.

thanks,
Bryan

---

From: "Bert Culpepper" <[email-masked]>
Date: Thu, 17 May 2001 10:29:45 -0400

-----Original Message-----
From: Bryan Byerly
Sent: Wednesday, May 16, 2001 12:09 PM
To: Jonathan Rosenberg
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [SIP] Re: [Sip-implementors] Discussion about Diversion

<snip>

> manufacturers) speaking up on this issue.  Are you actually willing to
> depend on your carrier to configure your service policy (per
> RFC3087)?  Are you willing to wait for your carrier to deploy
> equipment that can configure the service policy?  When your
> carrier misconfigures your service policy, who will your customers
> blame?  What incentive will the carrier have to fix the problem in a
> timely fashion?  Wouldn't you rather be in control of your own policy

<snip>

I can sympathize will "both sides" in this discussion.  IMHO, one
approach places service control in the network whereas the other
supports service control in the endpoints.  I myself prefer control in
the endpoint, I don't want to rely on any more functionality outside of
my box than I have to.  And like other feature support defined for SIP,
there are multiple approaches.

I do believe for the proxy approach that feature provisioning will be made
available to the end user via the web (most likely) at some point,
minimizing a user's reliance on their service provider to make changes.

I also feel that useful/desirable end-user experiences can occur without
specific support for Diversion within proxies.  Endpoints that insert and
use Diversion only need proxies to pass along the header.

I believe Diversion has multiple applications but are they enough to
warrant standardization by an IETF WG.  I myself can't answer that
question.  It seems to me a more appropriate WG might be SIPPING.

Best Regards,
Bert

---

From: Anders Kristensen <[email-masked]>
Date: Sun, 20 May 2001 16:54:21 -0400

Bryan Byerly wrote:
> One suggestion is to apply the same algorithm that we use for spiral
> loop detection.  If the user portion of the (sip:user@host) URL does
> not change, then consider it a simple routing decision (that does not
> require a Diversion header).  If the user portion of the
> (sip:user@host) URL does change, then add a Diversion header.

I have at least 5 different email addresses that I use in various
contexts. None of them have the same user part. I don't think the
heuristic you're proposing is going to be very effective in eliminating
"routing decisions" changes to request URLs. Hence you end up with all
the problems listed by Jonathan.

--
Anders Kristensen