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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 15 May 2001 08:34:07 -0400

I'll address the process problems.

Drafts which are sip wg items will, at the next rev after
they are accepted as work group items, be called draft-ietf-sip.
The rechartering process is still underway, but the sip
(as opposed to sipping) charter is posted, and the
drafts are listed.

Anyone can write a draft, submit it, and "announce" it to
the appropriate list.  Discussion can ensue.  The chairs
will rule pretty quickly if the draft is so far outside
the charter that it is inappropriate to continue on the list,
but in most cases, we will allow discussion to continue
for a while.

If the resulting discussion indicates that the level of 
interest is low, we will halt discussion on the list.
Authors are free to pursue the work on their own, creating
special lists, and announcing same on the sip list.
If the resulting discussion indicates that the level of
interest is high, the chairs will consider a request to
add the draft to the accepted items list.  The barrier
for entry is presently VERY high.  It may take discussion
at a meeting for such a move to be completed, or list
discussion may suffice.  Regardless, the process is that
the authors ask, the chairs rule.  If you don't ask,
it isn't a WG item.  AD participation in this process is
almost mandatory given the work load.  We aren't going to
add any item that could reasonably be done in another
group, or that seriously expands the charter.

WG items are tracked on the auxiliary web page.  Non items
are not tracked.  If it isn't on the tracking page, it
isn't a work item.  The "official" WG page is also updated
with accepted work items.

In this case, the authors have asked, and thus far, the chairs
have been not inclined to carry this item forward, but have
been allowing discussion to continue for a while.  Shortly,
we will have to decide if this is, or isn't appropriate.
As we said, the barrier is very high.  If you WANT this item
to move forward, get into the discussion.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 3:19 AM
> To: 'Bryan Byerly'; Igor Slepchin
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [Sip-implementors] Re: [SIP] Draft about diversion out of
> dat e
> 
> 
> 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.
> 

_______________________________________________
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: "Mark Watson" <[email-masked]>
Date: Tue, 15 May 2001 17:25:19 +0100

Jonathan,

If I understand correctly, you are arguing that wherever possible, services
should be designed so that they can get the mandatory information they need
from the Request-URI and the standard headers. This is consistent with the
meaning of URIs, which identify a particular abstract resource that is
required (i.e. particular voicemail *box*) rather than a device (i.e.
voicemail server).

This is a good point. However, as long as the entity asking for the service
is aware of the service it is asking for, it can include the appropriate
headers to access that service.

You also described two service architectures, with the example of User X
calling Boss B, being forwarded to Secretary S and subsequently to
voicemail. You argue that the service which decides to whose voicemail the
service should be forwarded to is associated with B, and so should reside
with B. So, the S sends a redirect request back to B, which B recognises as
a divert-to-voicemail. Then B decides which voicemail to divert to.

In this case too, though, the information needed by the voicemail platform
(namely, whose voicemail box?) is included in the INVITE sent to the
voicemail platform. Whether the information is encoded into the Request-URI
or the Diversion header seems to me unrelated to which 'service
architecture' is used.

So, I agree with your points about service architecture. The model you
describe below and in draft-rosenberg-sip-app-components is a good one.

I also agree with the point that where information is logically appropriate
for the Request-URI, then that is where it should go, not in a new header.
In the voicemail case, the abstract 'resource' which is indicated in the URI
is a particular *voicemail box* not a particular voicemail server (by
analogy, an HTTP URI identifies a document, service, whatever, not just a
server on which the resource resides).

However, I don't see why these two points are related.

So, using the Diversion header for voicemail is a bad idea because it
requires that the entity sending the call to voicemail needs to know that
the Diversion header is required. Or, put another way, a voicemail service
based on this can only be sold to users who have a proxy which can include
the Diversion header for them on calls it sends to voicemail. Mayby
voicemail platform vendors have a good reason for restricting their market
in this way.

On the other hand, a SIP voicemail platform owner who wishes to offer
service to PSTN endpoints, needs to make sure that the PSTN gateway(s) used
by their customers include the diverting number (=voicemail owners number)
in the SIP INVITE, whether it be in the Request-URI, in the Diversion header
or in the encapsulated ISUP IAM. The problem of ensuring that a capable
gateway is used is no easier if you choose one approach (encapsulation)
against another (Diversion).

To my mind, Diversion information is an example of the 'service capability'
approach - it is a generic capability which could be used for multiple
services. So, it's not sufficient anyway to demonstrate that it is a 'bad
idea for voicemail' to demonstrate that it is a bad idea full stop.

We will presumably define many service capabilities, upon which innovative
services can be built. It will always be the case that only users supporting
the underlying service capabilities can access the service. A UA which does
not support REFER cannot participate in a Call Transfer. The corollory is
that sensible service designers will only rely on service capabilities that
they absolutely do need. The Service Capabilities which are developed and
deployed on SIP UAs will be driven by the popularity of the Services which
rely on them.

To my mind, the capability to transport the identity of a 'diverting' user
is a useful service capability. At the very least it can be presented to the
eventual called user on a 'best effort' basis. Services which make use of
this capability have to be aware that it will not always be present, or the
Service can only be offered to users with the Capability. The presence of
the diverting identity would mean that the call had encountered some form of
Diversion, but the absence of this information would not mean that diversion
had not been encountered. To ensure that privacy is handled correctly with
respect to this information, I'd suggest using Remote-Party-ID to carry it.

The usefulness of explicit 'diversion reasons' is less clear, since in a SIP
network we are not restricted to the old PSTN/ISDN diversion reasons (busy,
no answer, universal, not reachable) - there could be as many diversion
reasons as there are CPL scripts, so such information could be simply a text
string.

Regards,

Mark Watson
Nortel Networks

> Sent: 15 May 2001 08:19

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 May 2001 02:10:41 -0400

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 6:30 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]
> date
> At 12:19 AM 5/15/2001, Jonathan Rosenberg wrote:
> >Now, this problem is fixable. As Allison has mentioned 
> during IETF 50, all
> Jonathan, you mentioned that this was not standards track. 
> Why must we 
> describe backwards compatibility with any old 
> draft-yournamehere-sip-xxx.txt document?

An informational document that simply describes one vendors approach does
not need to worry about compliance with anything, since its just
informational.

However, this draft is aimed at becoming a standards track extension, and
thus needs to worry about backwards compatibility.

-Jonathan R.

---