Subject: RE: [SIP] Re: [Sip-implementors] Discussion about Diversion

From: "Roy, Radhika R" <[email-masked]>
Date: Thu, 17 May 2001 10:44:45 -0400

In reality, the service control features will reside in both places:
Endpoints and Network. It will be a mixture of both situations.

Assuming this is the practical situation, let us develop the protocol that
does not exclude anyone of those situations.

In this context, let us have a second look for the "Diversion" service
capabilities.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 10:30 AM
To: 'Bryan Byerly'; 'Jonathan Rosenberg'
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [SIP] Re: [Sip-implementors] Discussion about Diversion

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

> * 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)?

<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

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

_______________________________________________
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: Gordon Ledgard <[email-masked]>
Date: Thu, 17 May 2001 11:52:53 -0400

Bryan wrote - 

<snip>

<snip>

Here's a voicemail vendor speaking up. Would I be willing to depend on a
carrier to configure my service policy? That depends entirely on my
relationship with the carrier. In many circumstances, our equipment will be
purchased by carriers who then resell the voicemail feature to their end
customers. In this model, service configuration is very much the carrier's
bailiwick. In another model, an independent secondary service provider will
sell services (voicemail) directly to end customers, and (as a possibility)
they will tell the customer to use the provider's provisioning website to
give them XYZ voicemail.

I also do not believe that we will ever get to the point, nor will we really
wish to, where the endpoint is aware of ALL of the services that it must
use, and explicitly specifies them.

A couple of thoughts about implicit versus explicit functionality also comes
to mind in response to Hennings argument about Diversion creating an
implicit service model: Explicit service models make sense when the commands
that operate the service can be made generic enough that differing vendors
of the service can utilize the same command protocol. I think we can come up
with a short list fitting that criteria. Voicemail MIGHT be one of them. But
an explicit service (such as "I want to leave a message for user X on
voicemail system J with parameters A,B,C") creates a tight binding between
the consumer, provider and protocol. Lest I state the obvious, the point I
am trying to make is that explicitly driven functionality will soon become
outmoded no matter how noble your intent, and applications will forever be
drilling into SIP packets to make all sorts of inferences. We must recognize
that both implicit and explicit functions will happen in the network, and
that neither is evil.

Gordon R. Ledgard
Principal Software Engineer
IPeria, Inc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 May 2001 18:42:19 -0400

My apologies for the tardiness of this reply. I chose to spend all of my
"IETF cycles" on updating bis, instead of answering list email. Now that
bis-03 is back, its time to get back to the 450 unread sip list messages in
my inbox.

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

>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 
>>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.
>
>I think you've just made the case for the Diversion header.  ;^) 

I could make the same point above for every single ISUP/ISDN parameter. I
suppose you would argue, then, that these too should therefore be added to
SIP?

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

Sounds like you are making the case for Proxy-Require here. Proxy-Require is
needed in a request if it cannot be processed correctly without
understanding the extension. Correctly, to me, implies that the result of
the call is what the customer expects. If they need to call customer support
every time they make a call, because it doesn't do the right thing, that
sounds like an extension that is mandatory.

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

This is a red herring. Once you've built devices which expect to see this
header, you now have to worry about the fact that existing proxies and UAs
won't insert it. 

I am really concerned about defining new extensions that effectively require
every single proxy to insert a new header for every single request, in order
to support proper operation of services which may occassionally get invoked.
The answer, "well, the customers will just call customer support", hardly
seems satisfactory.

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

Since the service is provided for the carriers benefit, don't you think the
carrier should determine what service is invoked when a request is sent to
the voicemail provider?

>RFC3087 approach: 
>
>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. 

You have a whole bunch of assumptions here that I think are not right. First
off, I don't expect a carrier to work with THAT many voicemail providers all
at once. Maybe 3 or something like that. Secondly, there is absolutely,
positively no reason why the URI syntax would vary from end user to end
user, so your summation is irrelevant. Furthermore, even though voicemail
providers could, in principal, use different URI syntax as rfc3087
discusses, I suspect many would adopt common naming conventions (such as the
one spelled out in rfc3087). We've seen the same thing in dialing plans,
which have a few variants but are repeated alot across enterprise systems.

So, the configuration burden is not much different than between peer voip
carriers in a clearinghouse, who must agree on numbering plans and other URI
formatting conventions (which domain name to use, tel url vs. sip url,
etc.). 

So, realistically, this is not much of an administrative burden in a
gateway. You can always forward the call, using SIP-T, to some application
platform which does the same thing the gateway would otherwise do, if you
want to outsource the function.

I compare this burden, with the burden that Diversion requires - that every
proxy support it for all requests - and this configuration seems very minor.

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

Thats only if you perform the gateway function in this fashion. This is
exactly what I was talking about regarding considerations for backwards
compatibility.

When the proxy decides to call-forward-busy to the voicemail service, it
constructs a sip URL like:

sip:666222-5551114-dep-fb@gw-ip-address

which indicates the number of the voicemail server (666222) and then the
rest is the username, service, and reason as described in rfc3087.

You can argue that this is a configuration burden for a gateway compared to
diversion, but thats a red herring also. Both approaches carry two phone
numbers; both approaches require the gateway to know to look for both
numbers (in one case, it looks for Diversion, and in the other, looks for a
specific URI format). The huge difference is that one approach requires all
proxies to insert this header henceforth for all time, and the other does
not.

>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:5551112@
>1.1.1.1;user=phone>;reason=cfb, 
>|       |         |              |             <sip:5551111@
>1.1.1.1;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 still like to understand how you propose handling the feature
interaction problem in such a manner. All the work in feature interaction to
date has been aimed at avoiding constructing such "policies" that consider
the interactions of all features in one piece of logic.

>* 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)? 

The voicemail provider serves the carrier. When the carrier sends a call to
the voicemail provider, presumably its because there was a specific service
the carrier wanted from the voicemail provider (i.e., leave a message). How
can you argue that the carrier has no place in dictating what the service is
that is provided by its service provider?

Let me give an analogy in another related space.

Lets say a carrier is providing conferencing services. It outsources that to
a conferencing provider. When a user makes a call to join the conference,
the provider forwards the call to a particular number (i.e., request URI) at
the conferencing provider. Applying your argument here, the conferencing
provider should determine which conference each user gets dropped into,
rather than it being dictated by the request URI as set by the provider (as
in draft-rosenberg-sip-conferencing-models and
draft-rosenberg-sip-app-components, where the R-URI identifies the
conference). The conferencing provider would sometimes look at the Subject
line, and mix together all calls with the same Subject. Or, maybe it keeps
lists of who likes who, and mixes together users who are known to be
friends. Clearly, I am being ridiculous, but it is to make a point. The
feature WILL NOT WORK as users expect unless there is a clear serviec
interface between the carrier and its conferencing provider. That service
interface dictates exactly what happens when a call is sent to that
provider. Without knowing that, the carrier has no way to know how and when
to send calls to the conferencing provider.

The notion of the request URI clearly identifying the resource to be
invoked, is at the heart of rfc3087, the app components architecture, and
the multiparty conferencing models. Do you believe that this approach is
flawed?

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

Fine enough. One can easily translate this request URI:

sip:666222-5551114-dep-fb@gw-ip-address

into the appropriate ISUP.

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

This would be true if you wanted to assume that the model for features and
services in ISUP should be the same as SIP. I'm not prepared to do that.

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

This is a big assumption. It will do the wrong thing in cases. As Anders has
pointed out, people use many different email addresses. In fact, within
dynamicsoft, I have both [email-masked] and
[email-masked]. The latter is actually the "official" email
address which drives internal configurations. As a result, the dynamicsoft
proxy will need to translate [email-masked] to
[email-masked]. This would be marked as a Diversion by your
approach. WHen this gets sent to the voicemail provider, what will happen?
No clue, of course, because with your approach there is no well defined
service interface. Its up to the "policy" of the provider. 

Here's another example, even more interesting. Someone calls
[email-masked]. This is our main number. When it reaches our
proxy, it gets translated to [email-masked], since we use 4 digit
extensions internally. So, here, the username has changed, but the end user
has not. 

Another funny one. Lets say I have a secretary, Jack D. Rosen, who is a
contractor for secretaries.com. A call comes for me, and rings my phone. I'm
not there. So, the proxy diverts, and forwards to Jack. Jacks email is
[email-masked]. Same username as me, but different domain. Now,
according to your algorithm, this won't be considered a diversion, and so if
Jack is not there, it drops to his voicemail instead of mine. Of course, had
my voicemail application running in my domain been EXPLICIT and specifically
tried to drop a message to my voicemail, it would work.

These are all symptoms of a system whereby applications are invoked
implicitly by trying to guess the sequence of logic and behaviors in
upstream devices which resulted in the call being delivered to it. 

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

Well, even if this were true, and it isn't, every proxy that modifies the
r-URI username would need to insert a diversion header, since it can't know
whether a voicemail server might be reached downstream. Thus, in order for
the voicemail service to work with high reliability, every proxy server that
changes the request URI username must always insert this, which means its a
Proxy-Require (and I have argued that it will need to be there even when the
R-URI username doesn't change, since the proxy can't know reliably whether
its a diversion.)

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

The insidious problem I am pointing out is that my CPL-based proxy doesn't
know which of these new reason codes are used by the "policy" of some
downstream voicemail server. For things to work reliably, it would need to
support every single one of them that is ever defined. Of course, you would
need to define lots of them to provide more and more cooler voicemail drop
features. Had you instead put the voicemail logic in the same place as that
proxy, you would need none.

-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 
  
> 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: 
> 
> > > 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] 
> 
> 

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