Subject: [dispatch] Comments requested on draft-avasarala-dispatch-comm-div-notification

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jan 2010 16:02:43 +0200

Hi,

we would like to ask for comments on the following draft. Do you find it 
useful? Do you think it should be published as an RFC?

http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-02

Based on the comments received, we will talk to our ADs about this piece 
of work.

Thanks,

Gonzalo
DISPATCH co-chair

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jan 2010 19:39:06 -0500

I've provided comments on earlier versions of this document.
Most of my concerns expressed before remain with this version.
I can post them again if desired. (I think they may have been private 
rather than on the list before.)

My main concern with this document is that it seems to have been 
designed for a very specific architecture (based on IMS I presume),
yet the applicability statement doesn't make that clear. The 
applicability statement says:

    The event package defined in this document is intended for use with
    network-based application servers that provide a CDIV service

(where CDIV is then defined as "CDIV: Communication Diversion".) This 
seems pretty generic (*a* CDIV service, not *the IMS* CDIV service), 
such as might be within the scope of the BLISS WG. But in fact, as one 
reads the details, it becomes apparent that a very specific architecture 
is being addressed. Yet that architecture is never spelled out.

The document never specifies what URL the subscriber is to use in the 
subscription request, or how it relates to the URLs for which the 
subscriber wishes diversion information. The subscribe request contains 
a body, acting as a filter, that selects the URLs for which diversion 
information is requested. That implies to me that the subscription is 
not addressed to the URL for which diversion information is requested. 
That is part of my concern about the unstated architecture.

Beyond that, the design is not to my taste. But that need not be 
relevant if it is to the taste of those concerned with the scope of 
applicability.

So, IMO this doc should not be published by the IETF unless its 
applicability is scoped to the garden in which its unstated architecture 
holds, or else the architecture for which it applies is thoroughly 
specified.

	Thanks,
	Paul

Gonzalo Camarillo wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 14 Jan 2010 19:27:41 -0600

Gonzalo Camarillo wrote:
> Hi,
>
> we would like to ask for comments on the following draft. Do you find
> it useful? Do you think it should be published as an RFC?
Looks mostly harmless. Of course, I said that about presidential
candidate George W. Bush too, so what do I know?

I'm not sure I would find it useful. I'm still facing challenges getting
basic  security working with SIP service providers. I find it less than
likely that something with this level of complexity will be widely
implemented. On the other hand, having the specification published isn't
likely to negatively impact anything in the real world either.

--
dean

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Jan 2010 09:39:36 +0200

Hi Paul,

> rather than on the list before.)

if you could post them again, that would be great. In that way, we would 
have all possible information when making a decision.

Thanks,

Gonzalo

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 15 Jan 2010 16:42:25 +0800

Hi Gonzalo

To give a brief,

This I-D defines a new SIP event package on lines of RFC 3265 for the Communication Diversion notification information (CDIV) that is defined in 3GPP TS 24.504 and 3GPP TS 24.604. 

So the applicability of the event package would be for conveying the CDIV Notification Information by the Notifies (which could be Application Servers in IMS) to the subscriber UEs (UAC in SIP terminology). Now this could be re-worded as

"The event package defined in this document is intended for use with SIP based network servers that provide CDIV service." to make it more general.

Below are Paul's initial comments on this I-D

John-Luc,

This sounds like a useful capability. Based on a quick scan, this proposal seems off to a good start.

For some of us that aren't actively involved with 3gpp, the references to 3gpp documents are somewhat inconvenient. Of particular note, I would

like to see the xml schema for application/comm-div-info+xml included in

this draft.

I'm also a bit confused, because you call for the same doc format to be used in both subscriptions and notifications. That at least seems odd, though perhaps it will become clear when I see the actual schema. Since it will perform a different role in these differing cases, it would be helpful if you could explain more about that.

Also I found the references to "user" somewhat ambiguous. I see a definition of Diverting User, and a note that "user" when not qualified should mean Diverting User. But I then also see "user" used in contexts discussing the subscriber.

For SUBSCRIBE, the R-URI identifies the "resource" to which a subscription is addressed. I would hope to see a very clear relationship

spelled out between the subscription resource and the processing of requests that are "diverted". My assumption is that "diversion" is performed with respect to a particular R-URI in an INVITE request, and that to be notified of such a diversion one would need be subscribed to this event package addressed to the same URI. If that is so, it should be spelled out. And if that isn't quite what you mean then its even more

important to spell out what you do mean.

    Thanks,
    Paul

The above comments are addressed in -02 version of the I-D. 

More comments welcome

Thanks
Ranjit

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Friday, January 15, 2010 1:10 PM
To: Paul Kyzivat
Cc: DISPATCH
Subject: Re: [dispatch] Comments requestedon draft-avasarala-dispatch-comm-div-notification

Hi Paul,

> rather than on the list before.)
 o
if you could post them again, that would be great. In that way, we would have all possible information when making a decision.

Thanks,

Gonzalo
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch <<FW: [dispatch] comm-div-notification event package update>> 

Subject: FW: [dispatch] comm-div-notification event package update
From: "Avasarala Ranjit-A20990" <[email-masked]>
To: <[email-masked]>
Date: Fri, 15 Jan 2010 16:38:13 +0800

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, June 04, 2009 10:24 AM
To: John-Luc Bakker
Cc: [email-masked]
Subject: Re: [dispatch] comm-div-notification event package update

John-Luc,

This sounds like a useful capability. Based on a quick scan, this proposal seems off to a good start.

For some of us that aren't actively involved with 3gpp, the references to 3gpp documents are somewhat inconvenient. Of particular note, I would

like to see the xml schema for application/comm-div-info+xml included in

this draft.

I'm also a bit confused, because you call for the same doc format to be used in both subscriptions and notifications. That at least seems odd, though perhaps it will become clear when I see the actual schema. Since it will perform a different role in these differing cases, it would be helpful if you could explain more about that.

Also I found the references to "user" somewhat ambiguous. I see a definition of Diverting User, and a note that "user" when not qualified should mean Diverting User. But I then also see "user" used in contexts discussing the subscriber.

For SUBSCRIBE, the R-URI identifies the "resource" to which a subscription is addressed. I would hope to see a very clear relationship

spelled out between the subscription resource and the processing of requests that are "diverted". My assumption is that "diversion" is performed with respect to a particular R-URI in an INVITE request, and that to be notified of such a diversion one would need be subscribed to this event package addressed to the same URI. If that is so, it should be spelled out. And if that isn't quite what you mean then its even more

important to spell out what you do mean.

    Thanks,
    Paul

John-Luc Bakker wrote:
> Hi,
>
> We have submitted a draft which proposes registration of an event 
> package, based on work ongoing in 3GPP (and TISPAN).
>
> (The most likely protocol output is going to be a new event package).
>
> The document can also be found in:
>
>
http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch-comm-di
v-notification-00.txt
>
> Updates since last version:
>
>    Changes from draft-avasarala-sipping-comm-div-notification-01
>
>
>
>    o  Changed contact details for co-author Subir Saha
>
>
>
>    o  Moved from SIPPING to DISPATCH WG
>
> Regards,
>
> John-Luc
>
>
>
>
>
> ---
> John-Luc Bakker
> Standards Manager
> Research In Motion
> BlackBerry: +1 (908) 463 7321
> Office: +1 (972) 373-1761
> Internal: (820) 63761
> E-mail: [email-masked]
>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential

> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other
than
> the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and
delete
> this information from your system. Use, dissemination, distribution,
or
> reproduction of this transmission by unintended recipients is not 
> authorized and may be unlawful.
>
>
>
------------------------------------------------------------------------

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

      See the Web&#39;s breaking stories, chosen by people like you. Check out Yahoo! Buzz. http://in.buzz.yahoo.com/

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jan 2010 10:27:26 +0100

I reserve judgement on how useful this would be. Concerning comments from Paul, I could imagine that the SUBSCRIBE request is addressed to the AOR URI for which notifications of diverted inbound requests are required, and that information from that AOR's domain proxy would be used as the basis for notifications. So the notifier would need somehow to be coupled to the domain proxy. This could certainly do with clarification.

It is unclear to me how one would handle a subscription in the following circumstances. The subscription is to [email-masked]. At any given time, there might be several contacts registered against [email-masked]. According to relative priorities of those contacts, scripting rules at the proxy, caller preferences, etc., a given inbound request to Alice would go to one or more of those contacts. Is it the intention that those contacts that do not receive that inbound request would receive a notification within the context of this event package? So if Alice's deskphone is one contact and her cellphone is another contact, if her current rules are for calls to go to her cellphone, her deskphone would receive notifications, and vice versa?

Or is that out of scope? Is the intention to limit the scope to cases where an inbound communication is diverted away from the AOR concerned?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: 14 January 2010 14:03
> To: DISPATCH
> Subject: [dispatch] Comments requested on 
> draft-avasarala-dispatch-comm-div-notification
> 
> Hi,
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 15 Jan 2010 17:49:56 +0800

Hi John

Yes the notifications are generated for the AoR (contact) for which the
diversion has occurred. 

So even though there could be multiple contacts registered for a
particular AoR, if the diversion has occurred for a particular contact
say alice at cellphone, then the notification information would go only
to her cellphone and not to all registered contacts.  This way we would
be limiting the number of notifications that are sent.

In current call diversion service configurations, there is no concept of
notifying subscribers when a particular call gets diverted based on a
particular rule. 

Considering the case of [email-masked]. Lets say Alice has setup a
call diversion rule for her cellphone to divert all calls from a
particular caller between 9 AM and 10 AM to her voicemail. But for some
reason she could have wrongly configured the rule as 9 to 10 AM or could
have put the caller id as wrong one. So it would be very difficult for
her to manually spot this error by reviewing the complete set of call
diversion services. So in order to facilitate Alice to effectively find
out the error, a notification mechanism is required.

So here th URI for subscription would be the URI that is associated with
diversion . E.g. Alice@cellhone or Alice@deskphone, etc.

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Friday, January 15, 2010 2:57 PM
To: Gonzalo Camarillo; DISPATCH
Subject: Re: [dispatch] Comments requestedon
draft-avasarala-dispatch-comm-div-notification

I reserve judgement on how useful this would be. Concerning comments
from Paul, I could imagine that the SUBSCRIBE request is addressed to
the AOR URI for which notifications of diverted inbound requests are
required, and that information from that AOR's domain proxy would be
used as the basis for notifications. So the notifier would need somehow
to be coupled to the domain proxy. This could certainly do with
clarification.

It is unclear to me how one would handle a subscription in the following
circumstances. The subscription is to [email-masked]. At any given
time, there might be several contacts registered against
[email-masked]. According to relative priorities of those contacts,
scripting rules at the proxy, caller preferences, etc., a given inbound
request to Alice would go to one or more of those contacts. Is it the
intention that those contacts that do not receive that inbound request
would receive a notification within the context of this event package?
So if Alice's deskphone is one contact and her cellphone is another
contact, if her current rules are for calls to go to her cellphone, her
deskphone would receive notifications, and vice versa?

Or is that out of scope? Is the intention to limit the scope to cases
where an inbound communication is diverted away from the AOR concerned?

John

> Based on the comments received, we will talk to our ADs about this 
> piece of work.
> 
> Thanks,
> 
> Gonzalo
> DISPATCH co-chair

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jan 2010 11:03:34 +0100

Ranjit,

> From: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
> Sent: 15 January 2010 09:50
> To: Elwell, John; Gonzalo Camarillo; DISPATCH
> Cc: [email-masked]
> Subject: RE: [dispatch] Comments requestedon 
[JRE] This worries me. Requests initially are going to be targeted at [email-masked], not alice@cellphone or alice@deskphone. The last two are the registered contacts for [email-masked] (I assume). I had not imagined a service at the domain proxy where I can divert based on particular contacts - only the phones themselves would be authoritative for that, e.g., if contact alice@deskphone is selected, the deskphone host would be responsible for any diversion, and that would not require an event package, since the information is already at the UA.

This certainly means we need a much clearer illustration of the proposed architecture, to ensure it is compatible with RFC 3261.

John

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 15 Jan 2010 19:45:21 +0800

Hi John

Completely agree with you. The subscribe requests will be towards the
public AoR i.e alice@example. But the diversion rules could be set for
specific registered contact Uris so that diversions for that particular
URI are notified. 

For e.g. if a call diversion rule for Alice is something like: "If call
from Bob's cellphone comes between 9 AM and 10 AM to Alice's sell phone,
divert the call to Alice's voicemail". So now if when the call from Bob
gets diverted to Alice voicemail, notification message is sent to
Alice's cellphone.

Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, January 15, 2010 3:34 PM
To: Avasarala Ranjit-A20990; Gonzalo Camarillo; DISPATCH
Cc: [email-masked]
Subject: RE: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

Ranjit,
betwee
> Yes the notifications are generated for the AoR (contact) for which 
> the diversion has occurred.
> 

> say alice at cellphone, then the notification information would go 
> only to her cellphone and not to all registered contacts.  This way we

> would be limiting the number of notifications that are sent.
> 
> In current call diversion service configurations, there is no concept 
> of notifying subscribers when a particular call gets diverted based on

> a particular rule.
> reason she could have wrongly configured the rule as 9 to 10 AM or 
> could have put the caller id as wrong one. So it would be very 
> difficult for her to manually spot this error by reviewing the 
> complete set of call diversion services. So in order to facilitate 
> Alice to effectively find out the error, a notification mechanism is 
> required.
> 
> So here th URI for subscription would be the URI that is associated 
> with diversion . E.g. Alice@cellhone or Alice@deskphone, etc.
[JRE] This worries me. Requests initially are going to be targeted at
[email-masked], not alice@cellphone or alice@deskphone. The last two
are the registered contacts for [email-masked] (I assume). I had not
imagined a service at the domain proxy where I can divert based on
particular contacts - only the phones themselves would be authoritative
for that, e.g., if contact alice@deskphone is selected, the deskphone
host would be responsible for any diversion, and that would not require
an event package, since the information is already at the UA.

This certainly means we need a much clearer illustration of the proposed
architecture, to ensure it is compatible with RFC 3261.

John

> used as the basis for notifications. So the notifier would need 
> somehow to be coupled to the domain proxy. This could certainly do 
> with clarification.
> 
> It is unclear to me how one would handle a subscription in the 
> following circumstances. The subscription is to [email-masked]. At 
> any given time, there might be several contacts registered against 

> scripting rules at the proxy, caller preferences, etc., a given 
> inbound request to Alice would go to one or more of those contacts. Is

> it the intention that those contacts that do not receive that inbound 
> request would receive a notification within the context of this event 
> package?
> contact, if her current rules are for calls to go to her cellphone, 
> her deskphone would receive notifications, and vice versa?
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 15 Jan 2010 12:59:28 +0100

> Sent: 15 January 2010 11:45
[JRE] This is the problem I am having. The call is originally is to Alice, not specifically to Alices's cellphone. We seem to have a 2-step approach here. The entity responsible for Alice determines that the appropriate contact is Alice's cellphone, and the entity responsible for Alice's cellphone then determines that it needs instead to go to Alice's voicemail. So the net result is that, when a call comes in to Alice, it is determined that the contact to which it should be sent is Alice's voicemail.

So what you are proposing is that if somebody subscribes to this event package for Alice, they will be notified when any call targeted at Alice is routed to any contact of Alice, say Alice's cellphone, Alice's voicemail, Alice's deskphone or Alice's homephone?

John

> [mailto:[email-masked]] On 
> > Behalf Of Elwell, John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 09:12:13 -0500

> have all possible information when making a decision.

Attached. These were comments made against a copy sent to me privately. 
I believe it was a pre-release of the -01 version. The current -02 
version isn't dramatically different.

	Thanks,
	Paul

Subject: Re: [dispatch] comm-div-notification event package update
From: Paul Kyzivat <[email-masked]>
To: Al-Bakri Ban-QBA002 <[email-masked]>
Cc: John-Luc Bakker <[email-masked]>, Ranjit Avasarala <[email-masked]>
Date: Thu, 18 Jun 2009 15:48:16 -0400

Ban,

I skimmed over the new version. Its better in that I now have a better 
sense of what you are trying to do. But of course, with that comes new 
questions. You were asking before posting the new version. I have quite 
a number of comments. But I think you should go ahead and post anyway, 
so others can comment as well. If you do, then I will repost these 
comments to the list. It makes no sense to do so if the doc isn't 
available to all.

One thing that is becoming more apparent now is that you have a 
particular implementation architecture in mind. It doesn't seem to be 
your intent to force use of that architecture, yet it colors the way you 
describe things, probably without you realizing it. And it is confusing 
to someone with a different conceptual model of how this might be 
implemented. I have a vague idea of what your model is, based on the IMS 
approach to things, but even so I'm not certain. It might be helpful if 
you gave an example of what you have in mind, perhaps as a non-normative 
appendix. Or else you can try to scrub the doc of any such assumptions. 
I will call out places where this was an issue for me.

I also think there are still issues around the distinction, or lack of 
one, between the subscriber and the diverting user. I think you have in 
mind that these are always the same, and word things with that 
assumption in mind. But I don't think these need always be the same. I 
can think of useful cases when they are not. So I think more care is 
needed here.

Another thing, that I mentioned before, is still hazy. That is regarding 
what the R-URI of the subscribe identifies. Is it the URI of the 
diverting user? Or is it just the URI of some server that can get access 
to information about the diverting user(s) the subscriber is interested 
in? Initially I thought it was the URI of the diverting user. But when I 
saw the description of the schema I found that a filter can select which 
diverting user(s?) are of interest. That suggests that the target of the 
subscribe is something else. This needs serious clarification. If it is 
just some server, how is the subscriber supposed to know what the URI 
is? And if multiple diverting users can be referenced by a single 
subscription, then how does the subscriber know the chosen server can 
access the complete set of users of interest?

Now some section by section comments:

Section 1:

>    In this document, We define a SIP event package that allows a SIP
>    Event Publication Agent (EPA) to be notified about communication
>    diversions enacted on their behalf.  This allows subscribers to
>    subscribe to this event package to gather this information.  When

Above is confusing to me. It isn't the EPA that is being notified is it? 
You don't otherwise use the term EPA in the document.

> 4.2.  Definitions
> 
>       Subscriber - The user who has subscribed to the Communication
>       diversion notification service and on whose behalf the
>       Communication diversions occur in the network.

Its the "and on whose behalf" that has me bothered in the above.
This implies equivalence of function that may or may not be present in 
practice.

>       Diverting User - The user who has configured a Communication.

This implies that this is a person. But I think what is of interest is 
not a person, but a URI (AOR) for which incoming calls might be diverted.

>       This could be the subsriber who has configured the Communication
>       DIversion service rules in the network.  Diversion mechanism via
>       subscription to a CDIV service.  The subscriber is the original
>       target of the incoming communication, before it is diverted to
>       another destination.  When not qualified, the term "user" or
>       "subscriber" should be referred to as the Diverting User.

The above doesn't parse correctly as an English paragraph. The second 
"sentence" is not a complete sentence.

It also doesn't make much sense to me otherwise because of the confusion 
of roles that I mentioned earlier. *Somebody* presumably configured the 
diversion rules. But we have no reason to believe that it was the 
subscriber. The subscriber is presumably identified by the From-uri of 
the subscribe. The entity that did the configuration may not even have a 
URI.

Event notification, or state change notification? Recent evolution of 
event service is to define it in terms of state change notification. But 
that doesn't work for this usage. Here we have real events. The 
occurrence of these events doesn't imply any change in state. This could 
present a problem in rate limiting.

Section 6.7:

>    In the case of a pending subscription, when final authorization is
>    determined, a NOTIFY can be sent.  If the result of the authorization
>    was success and a communication diversion is enacted on behalf of the
>    subscriber, a NOTIFY SHOULD be sent and SHOULD contain a complete
>    comm-div-info document subject to any rules specified by the
>    authorization policy that governs the subscription and to preferences
>    indicated at the time of subscription.

How is this supposed to work? Unless there is a diversion at *exactly* 
the same time that final authorization is obtained, what would the 
notification contain? Would it be the *last* diversion that occurred? 
Does that imply that the "last" diversion should be retained as state 
and returned any time a new subscription is established?

The work on 3265bis has surfaced a more refined view of what the event 
service deals with. The current thinking seems to be that the event 
notifications are really reporting on the state of some resource - 
either the complete state or the change in state since the last 
notification.

I'm not certain if your usage fits that model or not. On the surface it 
doesn't, since the events seem to be "diversions", and there is no 
permanent state of those. But perhaps the above paragraph implies that 
there *is* some retained state of diversions that can be reported on at 
a later time. And the later description of the xml schema is, I think, 
consistent with a model of retained history of diversions. But if so 
there is a lot missing to describe that.

>    Notifiers will typically detect that a communication diversion was
>    enacted on behalf of the subscriber via a "History-Info" header field
>    value, per [2] or [1], sent from an application server hosting the
>    CDIV application.

The "typically" above reflects an assumption about the architecture of 
systems that support this event package. I don't agree that this is an 
architecture that is widely used outside the IMS world. If you want to 
want to say it (and I have no problem with that), I think you need to 
expound on the architecture in which it applies. I don't think that 
would be normative material. It might be useful to have an appendix that 
discusses this architecture.

Section 6.10:

>    Comm-div-info notifiers SHOULD NOT generate notifications for a
>    single user at a rate of more than once every five seconds.

This could be clearer. How about:

    Comm-div-info notifiers SHOULD NOT generate notifications for a
    single subscription at a rate of more than once every five seconds.

Then I think you need to specify what happens when the rate of 
diversions exceeds this rate. Do you just drop any that occur too soon? 
Or do you delay them and combine with later ones in a single NOTIFY?

Section 8:

>    o  state: This attribute indicates whether the document contains the
>       full communication diversion information, or whether it contains
>       only information of those communication diversions that have
>       occured since the previous document (partial).

This is what I was referring to earlier. This seems to imply that full 
state includes a list of all diversions that have occurred. But that is 
an unbounded set. Surely you don't intend the state to include a history 
of *all* diversions. But if it is some and not all, then describing what 
it is gets harder.

>    o  entity: This attribute contains a URI that identifies the
>       subscriber whose Communication diversion information is reported
>       in the remainder of the document.

I would expect it to identify the URI for which diversions occurred. 
Saying it identifies the subscriber implies some things that probably 
should not be implied:
- an authorization rule - that subscriptions will only be
   authorized when the identity of the subscribe matches that
   of the Diverting User.

- that only the diverting user would be interested in this info.

A particular implementation may indeed have authorization rules that are 
restrictive in that way. But the design of the package shouldn't make 
such assumptions.

>    The comm-div-info element has a series of elements describing the
>    particular communication diversion or the filter criteria for
>    receiving the communication diversion information.

Now that I see the definition I remain unconvinced that it makes sense 
to use the same format for filters in subscriptions and for 
notifications. As defined there are definitely values conforming to this 
syntax that would only make sense as filters, and others that would only 
make sense as notifications. But they will be permitted in the wrong 
context - leaving issues about what should be done in such a case. It 
would be much clearer to have two different formats, one for filters to 
be supplied in a SUBSCRIBE, and another to be used in notifies. If there 
are elements that make sense in body, that can be defined and used in both.

> 8.1.1.1.1.1.  user-info
> 
>    This element gives user details like username and URI.  This element
>    has further sub-elements for describing username and user URI
> 
> 8.1.1.1.1.1.1.  User-name
> 
>    This element gives Username.  E.g "Alice".
> 
> 8.1.1.1.1.1.2.  User-URI
> 
>    This element gives User URI.  E.g "sip:[email-masked]".

So is the intent here that I could specify User-name of Alice, and it 
would trigger on any SIP URI that has a user part of Alice? I question 
the value of such a thing, but if you want it I guess it is ok. But then 
I think you had better specify the matching rules. Does it apply only to 
sip/sips URIs? Is it a full case-sensitive match on the user name? Is 
there punctuation that might be ignored? Or parameters in the user part 
that might be ignored? Can it apply to tel URIs as well? Should it be 
able to match phone numbers?

> 8.1.1.1.2.1.1.  start-time
> 
>    This element specifies the start time for receiving notifications.
>    Its value is expressed in YYYY:MM:DDTHH:MM:SS format.

What about timezones? Unless the subscriber knows the timezone that is 
being used there will be a mess. I think you either need to specify that 
it is always GMT/UTC that is used, or else you need to include the 
timezone in the specification.

> 8.1.1.1.3.  diverting-user-selection-criteria
> 
>    This element gives details of diverting user.  This element consists
>    of sub-elements defined for "user-info" element
>    Section 8.1.1.1.1.1.1.

Presumably this only applies to filters. This decouples the selection of 
the Diverting User from the R-URI of the subscription. In that case, 
what is the significance of the R-URI of the subscription? And how does 
one know where to subscribe that will have access to the info about the 
desired diverting user(s)?

> 8.1.1.1.5.1.  diversion-reason-info
> 
>    This element gives the actual reason for the communication diversion.
>    E.g reason codes like 3xx or Type of communication diversions like
>    CFX - CFB, CFNA, etc.

I see that this ultimately comes down to diversion-reason-info-type, 
which is an enumeration of sip response codes, and 
diversion-rule-info-type, which seems to be an unconstrained string. If 
that string is unconstrained, how does anyone know what to put? And how 
do creators of new rule types chose values that don't conflict with 
existing values.

> 8.1.1.2.1.  notification-time-selection-criteria
> 
>    This element informs the server about the time at which the
>    notification should be triggered.  This notification trigger time is
>    expressed using the element "time-range" defined in
>    Section 8.1.1.1.2.1.

How does this differ from 8.1.1.1.2.1.  time-range???

> 8.1.1.2.2.  presence-status-selection-criteria
> 
>    This element gives the presence status of the subscriber, based on
>    which the decision can be made, whether the user wishes to receive
>    notification information or not.
> 
> 8.1.1.2.2.1.  presence-selection-info
> 
>    This element gives the presence status of the subscriber as per
>    Presence event package defined in [10].

I don't understand this. Does it mean that the notifier is supposed to 
subscribe to the presence status of the subscriber, and make decisions 
about whether to send notifications as the subscriber presence state 
changes? I guess that is *possible* but why would you do that. The 
subscriber can change its own subscription as its presence status changes.

And assuming you want to do this, how does the presence-selection-info 
influence notifications? Are they sent when the presence status matches? 
Or are they suppressed when the presence status matches? And what 
constitutes a match?

> 8.1.1.2.3.  notification-buffer-interval

There is no description of this. What is it?

	Thanks for opportunity to comment,
	Paul

Al-Bakri Ban-QBA002 wrote:
> John-Luc and Paul,
> 
> Please find the updated version of this IETF draft provided by Ranjit,
> with the following updates:
> 1. Added the Comm-div-info document structure and scheme.
> 2. Incorporated Paul Kyzivat's comments on clarification of "user" and
> subscriptions.
> 
> If these changes are ok with you, we can submit the draft to the
> DISPATCH reflector.
> 
> Thank you,
> 
> Best regards,
> 
> Ban and Ranjit
> 
> 
> 
> From: John-Luc Bakker [mailto:[email-masked]] 
> Sent: 04 June 2009 17:37
> To: Paul Kyzivat
> Cc: Al-Bakri Ban-QBA002
> Subject: RE: [dispatch] comm-div-notification event package update
> 
> Paul,
> 
> Thanks for the comments.
> I am busy finding and packing my swimsuit today to go to the beach for a
> week. :) A response shall be somewhat delayed ...
> 
> Kind regards,
> 
> 	John-Luc
> 
> For some of us that aren't actively involved with 3gpp, the references
> to 3gpp documents are somewhat inconvenient. Of particular note, I would
> 
> I'm also a bit confused, because you call for the same doc format to be
> used in both subscriptions and notifications. That at least seems odd,
> though perhaps it will become clear when I see the actual schema. Since
> it will perform a different role in these differing cases, it would be
> helpful if you could explain more about that.
> 
> Also I found the references to "user" somewhat ambiguous. I see a
> definition of Diverting User, and a note that "user" when not qualified
> should mean Diverting User. But I then also see "user" used in contexts
> discussing the subscriber.
> 
> For SUBSCRIBE, the R-URI identifies the "resource" to which a
> subscription is addressed. I would hope to see a very clear relationship
> 
> spelled out between the subscription resource and the processing of
> requests that are "diverted". My assumption is that "diversion" is
> performed with respect to a particular R-URI in an INVITE request, and
> that to be notified of such a diversion one would need be subscribed to
> this event package addressed to the same URI. If that is so, it should
> be spelled out. And if that isn't quite what you mean then its even more
> 
> non-public information. Any use of this information by anyone other than
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jan 2010 09:28:13 -0500

> Yes the notifications are generated for the AoR (contact) for which the

John asked some follow up questions on this, and I will too.

In my experience, routing to registered contacts is not considered to be 
diversion.

This just points up the need for a much clearer explanation of the 
assumed environment in which this feature is expected to work.

	Thanks,
	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Sat, 16 Jan 2010 05:56:58 -0000 (UTC)

> specific registered contact Uris so that diversions for that particular

What isn't clear here is the underlying diversion architecture.

I believe John has in mind a model where each UA has local divert
capability; that is, it can receive an INVITE request and divert to
another location without the registrar having knowledge of this diversion.
Thus, diversion subscriptions have to be serviced by the UAs themselves,
which are the notifiers. This means a "forked SUBSCRIBE" scenario with
multiple 200s, which is a bit messy (i.e., it isn't likely to work very
well).

However, the CDIV architecture as I understand it assumes diversion is
handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
first determines a routing for the INVITE to various contacts, then
executes diversion on a per-contact basis if needed. Consequently, the
S-CSCF has full knowledge of diversion status, and can serve as the
notifier for the diversion notification package. This all requires some
way for a UA to inform an S-CSCF to invoke diversion, which is outside the
scope of this document.

And this is exactly the description of architectural model that is
apparently not adequately disclosed in the draft, and probably should be.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 16 Jan 2010 10:43:32 -0500

Dean is on the track that I was thinking.

But I also can't reconcile Ranjit's statement, that the subscription 
would be addressed to the AOR of the diverted user, with the syntax of 
the filter, which has a separate selector for the diverted users to 
notify about. That only makes sense if the subscription is to an entity 
that has visibility to a variety of diverted users.

I also continue to question whether contact routing should be considered 
diversion. That did not seem to be the common understanding during the 
long discussions on History-Info. I agree that getting info on which 
contact was selected might be useful, but then I think terms should be 
more carefully defined.

	Thanks,
	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Sat, 16 Jan 2010 11:36:42 -0800

Instead of emphasizing and clarifying how this work is 3gpp specific it 
might be better to focus on how to make it more generally applicable (or 
palatable, if you prefer). ISTM that at its core this could be generally 
useful and need not be tied to 3gpp. The result may be somewhat 
different from what's in the current draft, but it can serve as a 
starting point.

Anders

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 10:02:30 +0100

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 16 January 2010 05:57
> To: Avasarala Ranjit-A20990
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
> Subject: Re: [dispatch] Comments 
[JRE] To be clear, I was not advocating that model, but just questioning whether that was the model the author had in mind.

John

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 18 Jan 2010 18:06:48 +0800

Hi Dean

The Call diversion architecture and service are explained in 3GPP TS
24.604.  So here the diversion service gets executed in the network by
the CSCFs or the Application Servers on behalf of the individual
subscribers. So here the UA(s) do not do the actual diversion, but set
rules on the server for triggering diversions. 

So in this model, as users set several call diversion rules based on
several criteria like incoming caller identity or time of day, etc,
there are bound to be some errors in configuration. So in order to
convey the actual outcome of the diversion, there is a need to notify
the actual user i.e on whose behalf the diversion has occurred. This
notification information is expressed as an CDIV notification event
package which is the main purpose of this document. 

The proposed CDIV notification information event package definition
conform to the standard event package template as defined in RFC 3265
and is applicable to CDIV service that gets executed in the server
rather than by individual User Agents. 

Thanks and looking forward to more comments and directions to take this
work forward.

Regards
Ranjit

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Saturday, January 16, 2010 11:27 AM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; Gonzalo Camarillo; DISPATCH
Subject: Re: [dispatch] Comments

> specific registered contact Uris so that diversions for that 
> particular URI are notified.

another location without the registrar having knowledge of this

However, the CDIV architecture as I understand it assumes diversion is
handled at the S-CSCF on behalf of all UAs. In this model, the S-CSCF
first determines a routing for the INVITE to various contacts, then
executes diversion on a per-contact basis if needed. Consequently, the
S-CSCF has full knowledge of diversion status, and can serve as the
notifier for the diversion notification package. This all requires some
way for a UA to inform an S-CSCF to invoke diversion, which is outside
the scope of this document.

And this is exactly the description of architectural model that is
apparently not adequately disclosed in the draft, and probably should
be.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jan 2010 11:23:27 +0100

Ranjit,

Thanks for your explanation. However, if the IETF is to publish an RFC on diversion notification, it will need to relate it clearly to RFC 3262. So if the scope is just notifications of diversions away from the original target AOR towards some other target AOR, I am comfortable. If it is to do with selection of an appropriate registered contact for the original target AOR, I am uncomfortable and would require further explanation.

John

> Sent: 18 January 2010 10:07
> To: Dean Willis
> Cc: Elwell, John; Gonzalo Camarillo; DISPATCH; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 09:32:08 -0500

> different from what's in the current draft, but it can serve as a 

I agree that something along these lines could be generally useful.
But providing this sort of functionality does impose some constraints on 
the overall system architecture to ensure that there is some entity that 
can serve as notifier that has access to the requested information. (Its 
certainly possible to construct useful sip-based systems that do 
diversion that don't have that property.)

So there is some question whether there is interest in standardizing 
such an architecture, beyond what is already being done for IMS.

If there is not such interest, then I see no reason to object to this 
draft, as long as it is properly scoped as to its applicability.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 20 Jan 2010 01:48:51 +0800

Hi John

Sorry for the late response. Yes the notifications will be from the
server towards the original AoR with the registered contact specified as
part of the event package (e.g in the element "diverting-user"). So it
would be the job of the notifier to generate appropriate diversion
notification information towards the target AoR.

Thanks

Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, January 18, 2010 3:53 PM
To: Avasarala Ranjit-A20990; Dean Willis
Cc: Gonzalo Camarillo; DISPATCH; [email-masked]
Subject: RE: [dispatch] Comments

Ranjit,

Thanks for your explanation. However, if the IETF is to publish an RFC
on diversion notification, it will need to relate it clearly to RFC
3262. So if the scope is just notifications of diversions away from the
original target AOR towards some other target AOR, I am comfortable. If
it is to do with selection of an appropriate registered contact for the
original target AOR, I am uncomfortable and would require further
explanation.

John

> Thanks and looking forward to more comments and directions to take 
> this work forward.
> 
> 
> 
> Regards
> Ranjit
> 
> Thus, diversion subscriptions have to be serviced by the UAs 
> themselves, which are the notifiers. This means a "forked SUBSCRIBE" 
> scenario with multiple 200s, which is a bit messy (i.e., it isn't 
> likely to work very well).
> 

> notifier for the diversion notification package. This all requires 
> some way for a UA to inform an S-CSCF to invoke diversion, which is 
> outside the scope of this document.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 19 Jan 2010 19:05:26 +0100

> Sent: 19 January 2010 17:49
> To: Elwell, John; Dean Willis
[JRE] This just confuses me again. It first says the notification will be sent from the server to the original AOR, and then it says notification information is send towards the target AOR - apparently a contradiction, unless these two terms mean the same thing. Also, why is the registered contact (I assume this means contact URI) sent in element "diverting-user" rather than the original AOR?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Jan 2010 13:15:19 -0500

> [JRE] This just confuses me again. It first says the notification will be sent from the server to the original AOR, and then it says notification information is send towards the target AOR - appare…

This has confused me from the beginning.
It seems the assumption is that only the "diverting user" will 
subscribe. But in reality that doesn't make much sense if the 
subscription is addressed to the diverting user.

It makes some sense if the subscribers are UAs that have registered with 
the AOR of the diverting user, and the notifier is a server that 
mediates arriving requests to that AOR.

But even then, while its reasonable to expect that the registered 
devices might be interested in subscribing to this, surely they aren't 
the *only* plausible subscribers. Assuming they are is, IMO, a mistake.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Jan 2010 00:04:22 -0600

On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:

>>> From: Avasarala Ranjit-A20990 [mailto:[email-masked]] Sent:  
>>> 19 January 2010 17:49
>>> Subject: RE: [dispatch] Comments requestedondraft-avasarala- 
>>> dispatch-comm-div-notification
>>>
>>> Hi John
>>>
>> [JRE] This just confuses me again. It first says the notification  
>> will be sent from the server to the original AOR, and then it says  
>> notification information is send towards the target AOR -  
>> apparently a contradiction, unless these two terms mean the same  
>> thing. Also, why is the registered contact (I assume this means  
>> contact URI) sent in element "diverting-user" rather than the  
>> original AOR?
>

The diverting user has multiple user agents. Said user cannot remember  
which user agent is set to divert, or what it is diverting to. So said  
user subscribes to the divnot package in order to find out what the  
heck is happening.

>
> It makes some sense if the subscribers are UAs that have registered  
> with the AOR of the diverting user, and the notifier is a server  
> that mediates arriving requests to that AOR.
>

Yes, I think that's the intent

> devices might be interested in subscribing to this, surely they  
> aren't the *only* plausible subscribers. Assuming they are is, IMO,  
> a mistake.

I think your view of the architecture is somewhat larger than the  
author's. This is not unreasonable. Like you, I can envision other use  
cases, such as call center scenarios.

Is there any reason NOT to generalize the specification for broader  
applicability?

--
Dean

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 21 Jan 2010 01:44:20 +0800

Hi Dean

A sample diversion notification document would like  

<comm-div-info>
  <comm-div-ntfy-info>
    <originating-user-info>
      <user-name>Boss</user-name>
      <user-URI>sip:[email-masked]</user-URI>
    </originating-user-info>
    <diverting-user-info>
      sip:[email-masked]
    </diverting-user-info>
    <diverted-to-user-info>
      sip:[email-masked]
    </diverted-to-user-info>
    <diversion-time-info>1999-06-01T13:20:00-05:00</diversion-time-info>
    <diversion-reason-info>404
  </comm-div-ntfy-info>
</comm-div-info>

So here, the subscribing AoR would be [email-masked]. The
<diverting-user-info> which is [email-masked] gives the URI that is
actually diverting. While the <diverted-to-user-info> element gives the
final target of the call.

So at any point of time, [email-masked] can check all the
notifications received to determine the set of diversions that have
taken place at various registered contacts of Alice.  

Now if we take the call centre scenario, then a particular incoming call
could get forked probably sequentially until one of the agents picks the
call. So I feel this is not a valid use case of call diversion, but
would qualify for a use case of sequential or simultaneous forking. 

Regards
Ranjit

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Wednesday, January 20, 2010 11:34 AM
To: Paul Kyzivat
Cc: Elwell, John; Avasarala Ranjit-A20990; DISPATCH; Gonzalo Camarillo
Subject: Re: [dispatch] Comments

On Jan 19, 2010, at 12:15 PM, Paul Kyzivat wrote:

>>> server towards the original AoR with the registered contact 
>>> specified as part of the event package (e.g in the element 
>>> "diverting-user").
>>> So it
>> notification information is send towards the target AOR - apparently 
>> a contradiction, unless these two terms mean the same thing. Also, 
>> why is the registered contact (I assume this means contact URI) sent 
>> in element "diverting-user" rather than the original AOR?
>

The diverting user has multiple user agents. Said user cannot remember
which user agent is set to divert, or what it is diverting to. So said
user subscribes to the divnot package in order to find out what the heck
is happening.

> with the AOR of the diverting user, and the notifier is a server that 

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2010 13:10:42 -0500

> final target of the call.

Hmm. Can you explain further?

Is the AOR sip:[email-masked], with sip:[email-masked] being a 
registered Contact for that?

If so, I would expect that sip:[email-masked] would be the diverting 
user. For sip:[email-masked] to be the diverting user, wouldn't that 
phone have to initiate the diversion? If that were the case, how would 
the notifier for the event discover that the diversion has occurred?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Jan 2010 22:12:27 +0100

> Sent: 20 January 2010 18:11
> Cc: Dean Willis; Elwell, John; DISPATCH; Gonzalo Camarillo
[JRE] I have exactly the same questions as Paul, but also an addition question. If sip:[email-masked] is the contact URI for AOR sip:[email-masked], why would <originating-user-info> not contain sip:[email-masked]? Although the contact URI would be available, often the contact URI is not meaningful, i.e., often it would not explicitly identify boss. Also, from a return call perspective, sip:[email-masked] would be more useful, since it would hopefully reach boss on whatever device he happens to be using at the time.

John

> apparently

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 22 Jan 2010 18:31:40 +0800

Hi all

The elements have following meaning

<subscriber-info>       This element would give the details of
subscriber user - E.g. [email-masked]

<originating-user-info> This element gives the details of the call
originator. i.e the caller. Which in the example is sip:[email-masked]
or 
                        sip:[email-masked].
<diverting-user-info>   This element gives the details of the device on
whose behalf diversion is taking place. For e.g. if [email-masked] has
set a
                        rule for [email-masked] to divert all
calls from Bob between 9 AM and 10 AM to voice-mail, then the 
                        [email-masked] would be the
"diverting-user"
<diverted-to-user>      This element gives the final target of the call.
For e.g. the voice-mail.

<diversion-time-info>   This element gives the actual time of diversion.
E.g. 9.30 AM

,diversion-reason-info> This element gives the reason for diversion.
E.g. Rule-id of Reason like CFB

So based on this a typical subscription document would like

<comm-div-info>
     <subscriber-info>
       <user-info>
         <user-name> Alice </user-name>
         <user-URI> [email-masked] </user-URI>
       </user-info>
     </subscriber-info>
     <comm-div-subs-info>
         <comm-div-selection-criteria>
            <originating-user-selection-criteria>
              <user-info>
                <user-name>Bob</user-name>
                <user-URI>
                  sip:[email-masked]
                </user-URI>
              </user-info>
            </originating-user-selection-criteria>
            <diverting-user-info>
               <user-info>
                <user-name>Alice-Office</user-name>
                <user-URI>
                  sip:[email-masked]
                </user-URI>
              </user-info>
            </diverting-user-info>
            <diversion-time-selection-criteria>
              <time-range>
               <start-time>2010-01-22T09:00:00-05:00</start-time>
               <end-time>2010-01-22T10:00:00-05:00</end-time>
              </time-range>
            </diversion-time-selection-criteria>
            <diversion-reason-selection-criteria>
              <diversion-reason-info></diversion-reason-info>
            </diversion-reason-selection-criteria>
          </comm-div-selection-criteria>
      </comm-div-subs-info>
   </comm-div-info>

The above XML document represents a subscription document for notifying
diversiosn that occur between 9 and 10 AM at divering user alice@
Regards
Ranjit

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, January 21, 2010 2:42 AM
To: Paul Kyzivat; Avasarala Ranjit-A20990
Cc: Dean Willis; DISPATCH; Gonzalo Camarillo
Subject: RE: [dispatch] Comments

> the notifier for the event discover that the diversion has occurred?
[JRE] I have exactly the same questions as Paul, but also an addition
question. If sip:[email-masked] is the contact URI for AOR
sip:[email-masked], why would <originating-user-info> not contain
sip:[email-masked]? Although the contact URI would be available, often
the contact URI is not meaningful, i.e., often it would not explicitly
identify boss. Also, from a return call perspective, sip:[email-masked]
would be more useful, since it would hopefully reach boss on whatever
device he happens to be using at the time.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Jan 2010 09:45:26 -0500

Ranjit,

The URLs you are using are suggestive as to their roles, but its still 
not entirely clear to me. Is the following correct?

sip:[email-masked]		AOR

[email-masked]		Contact registered to
				sip:[email-masked]

sip:[email-masked]		AOR

sip:[email-masked]	Contact registered to
				sip:[email-masked]

More inline

>                         sip:[email-masked].

How is the originator of a request determined? Is it from From or 
P-A-ID? How is it that either of the above might be the originator?

>                         [email-masked] would be the

Some questions about above:

Assuming sip:[email-masked] is not an AOR, but rather is a 
registered contact to sip:[email-masked], where in the routing of the 
call does the server that evaluates this rule get control?

How would it work in cases where the address for Alice's office phone is 
a dynamically assigned ip address rather than a dns name?

> <diverted-to-user>      This element gives the final target of the call.

The *final* target? I don't think that is possible.
It can at best be the address last known to the server doing the 
reporting. If the call is diverted again downstream, that won't be 
known. Or am I missing something?

Also, suppose we have an SSP that services multiple AORs. But still the 
subscriptions are on a per-AOR basis. If Alice gives a rule that diverts 
her calls to Charlie, who is also a customer of the same SSP, and 
Charlie has also installed diversion rules for his AOR, do you expect 
the notifications from subscription to Alice to report on the downstream 
diversions performed by Charlie?

>                   sip:[email-masked]

I thought the user-name was the same as the user portion of the URI. If 
not, how does a server determine what it is in a request in order to do 
matching on it?

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 25 Jan 2010 18:16:44 +0800

Hi Paul

My responses inline <Ranjit>

Sip:[email-masked] OR sip:[email-masked] would be the
registered contacts for sip:[email-masked]. So these two registered
contacts could have individual URIs (using GRUU). 

The

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, January 22, 2010 8:15 PM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; DISPATCH
Subject: Re: [dispatch] Comments

Ranjit,

sip:[email-masked]		AOR

sip:[email-masked]		AOR

More inline

Avasarala Ranjit-A20990 wrote:
> originator. i.e the caller. Which in the example is 
> sip:[email-masked] or

<Ranjit> The originating-user-info URL would be the incoming caller
identity that is present in "From" header. So it could be
sip:[email-masked] OR 
         sip:[email-masked] depending on caller id configuration
and how the caller wants his or her identity to be displayed to the
called user.

         So yes the originator of the request is determined from the
P-Asserted-Identity of the caller. 

> whose behalf diversion is taking place. For e.g. if [email-masked] 
> has set a

<Ranjit> The server looks for the incoming caller identity and the
destination identity to see if there is a matching rule configured. If
the registered 
         contact is not an AoR, then the call cannot be routed to it and
hence will be routed to the main AoR i.e sip:[email-masked] and the
rule would
         not be executed. But if sip:[email-masked] is an AoR
(e.g. GRUU), then the call could be routed and if there is adiversion
rule there,
         the diversion rule would get executed and a notification
generated towards that AoR.

<Ranjit> Since the notification gets generated dynamically when ever the
diversion occurs, the new ip address is taken prior to sending the
notification.

<Ranjit> True, the final-target here means the next hop from the server.
E.g if the server diverts the call to another server, then that server
would be the final target. Agree with you that getting the final target
of diversion would not be possible if there are multiple entities
involved in the path.

<Ranjit> No. All notifications to Alice indicate that calls to Alice got
diverted to Charlie. What happened beyond that, Alice would not know. 

>                 <user-name>Alice</user-name>
>                 <user-URI>

<Ranjit> Yes. Agree with you. Changed it

	Thanks,
	Paul

> The above XML document represents a subscription document for 
> notifying diversiosn that occur between 9 and 10 AM at divering user 
> alice@ Regards Ranjit
> 
> sip:[email-masked]? Although the contact URI would be available, 
> often the contact URI is not meaningful, i.e., often it would not 
> explicitly identify boss. Also, from a return call perspective, 
> sip:[email-masked] would be more useful, since it would hopefully 
> reach boss on whatever device he happens to be using at the time.
> 
> John
> 
>> 	Thanks,
>> 	Paul
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2010 09:21:23 -0500

Comments inline.

	Thanks,
	Paul

> contacts could have individual URIs (using GRUU). 

OK, I guessed right on that part.

> P-Asserted-Identity of the caller. 

OK, no surprises.

> destination identity to see if there is a matching rule configured.

I guess my question wasn't clear.
Where in the routing sequence does this server reside?
If it is positioned before the contact routing has occurred, then it 
can't know which contact was chosen.

Since this proposal is coming, more or less, from IMS I assume you are 
imagining this is an IMS Application Server. IIRC, those get control 
*before* contact routing is done by the S-CSCF. So how would the AS know 
if a particular contact was chosen. (I take some issue with calling 
contact routing "diversion", but lets not discuss that right now.)

> If the registered 

Huh? Whether the registered contact is an AOR has no bearing on whether 
its possible to route to it. And, its in general impossible to determine 
by looking whether a URI is an AOR or not.

> rule would not be executed.

That statement makes me even more confused. I have no idea what it means.

> But if sip:[email-masked] is an AoR

This is getting more and more confusing. So I have even more desire for 
at least a detailed use case that shows all the players, their addresses 
and relationships to one another, and the call flow.

> diversion occurs, the new ip address is taken prior to sending the

Again it seems my question wasn't clear.
You are showing rules that contain the contact addresses of particular 
devices. If the contact URIs registered by those devices contain 
dynamically assigned addresses, how would a subscriber know how to 
construct the rule that selects a particular device? Or if it is 
receiving all the diversions, how would it relate the reported results 
to particular devices?

This relates, in a way, to whether contact routing is diversion or not. 
Typically what I think of as real diversion would be to a URI that *is* 
an AOR, and hence stable and knowable by those formulating rules. But 
typical contact routing would involve URIs that aren't very meaningful.

If you want to be able to write rules like: "let me know when the call 
is routed to the phone in my office rather than the one in my home" 
(where both have the same "phone number"), then you are going to have to 
find a way to give those stable URIs, like sip:[email-masked] 
and sip:[email-masked]. AFAIK that isn't the norm, so if you are 
assuming it then please make that clear.

> diverted to Charlie. What happened beyond that, Alice would not know. 

OK. Good.

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 27 Jan 2010 23:56:55 +0800

Hi Paul

Reply inline <Ranjit-27Jan> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, January 25, 2010 7:51 PM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; DISPATCH
Subject: Re: [dispatch] Comments

Comments inline.

	Thanks,
	Paul

>          sip:[email-masked] depending on caller id 
> configuration and how the caller wants his or her identity to be 
> displayed to the called user.
> 

OK, no surprises.

> registered contact to sip:[email-masked], where in the routing of 
> the call does the server that evaluates this rule get control?
> 

<Ranjit-Jan27> The server could be the Application Server where the
diversion rules reside and get executed.

If it is positioned before the contact routing has occurred, then it
can't know which contact was chosen.
<Ranjit-Jan27th> No it would be before that. 

<Ranjit-Jan27th> Yes you are right. This proposal is more from a IMS and
3GPP perspective and I am trying to generalize it for IETF.

<Ranjit-Jan27th> Agree with you on this.

> rule would not be executed.

That statement makes me even more confused. I have no idea what it
means.

<Ranjit-Jan27th> Here I mean, the notifications would be sent to the
main AoR with the details of "diverting-user", "diverted-to-user" being
part
Of the XML package. The notifications need not be sent to the registered
contact. For e.g if sip:[email-masked] is the AoR and diversions are
taking
Place for sip:[email-masked], then notifications will be sent
to sip:[email-masked] only and not to sip:[email-masked]. This will
simplify things I feel !!

> But if sip:[email-masked] is an AoR (e.g. GRUU), then the 
> call could be routed and if there is adiversion rule there,

<Ranjit-Jan27th> as I mentioned above, to simplify things, lets assume
that notifications always go to the main AoR i.e the Public User
Identity (in IMS)
And not to any of the registered AoR irrespective of who the diverting
user is. So here even tough the divering user is sip:alice@office or
sip:alice@home, the notifications always go to sip:[email-masked]. 

> How would it work in cases where the address for Alice's office phone 
> is a dynamically assigned ip address rather than a dns name?
> 
> <Ranjit> Since the notification gets generated dynamically when ever 
> the diversion occurs, the new ip address is taken prior to sending the

<Ranjit-Jan27th> if the notifications are sent to PUI, then the contact
addresses are specified as URLs. So there is no need to send any
notifications to individual contact adsresses

> would be the final target. Agree with you that getting the final 
> target of diversion would not be possible if there are multiple 
> entities involved in the path.
> 
> Also, suppose we have an SSP that services multiple AORs. But still 
> the subscriptions are on a per-AOR basis. If Alice gives a rule that 
> diverts her calls to Charlie, who is also a customer of the same SSP, 
> and Charlie has also installed diversion rules for his AOR, do you 
> expect the notifications from subscription to Alice to report on the 
> downstream diversions performed by Charlie?
> 
> <Ranjit> No. All notifications to Alice indicate that calls to Alice 
> got diverted to Charlie. What happened beyond that, Alice would not
know.

OK. Good.

> I thought the user-name was the same as the user portion of the URI. 
> If not, how does a server determine what it is in a request in order 
> to do matching on it?
> 
>>> If so, I would expect that sip:[email-masked] would be the 
>>> diverting user. For sip:[email-masked] to be the diverting user, 
>>> wouldn't that phone have to initiate the diversion? If that were the

>>> case, how would the notifier for the event discover that the 
>>> diversion has occurred?

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 10:07:11 -0700

There are way to accomplish the same end goals as this draft suggests using things that are very likely to predate RIM's IPR on the topic. For example the ideas on using things similar to the dialog events package or reporting events about call forking on proxies. I have a strong preference for doing this in an IPR free way. I strongly encourage the WG to explore alternative ways to solve these problems before deciding what to do with this draft. 

Cullen <in my individual contributor role>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 29 Jan 2010 16:55:31 +0800

Hi Cullen

This draft is kind of straight forward as it proposes a SIP based XML
event package for reporting call diversions that occur in the network on
behalf of the subscribers that set call forwarding rules based on
various criteria like "incoming caller identity", "time-of-day", etc.

The IPR is essentially based on the proposed event package and the call
diversion notification service that gets triggered whenever a call gets
diverted on behalf of a subscriber. This service is standardized in 3GPP
TS 24.604. Now since 3GPP does not standardize XML packages, there was a
need to submit an IETF draft and get it standardized.  With this intent,
we proposed an informational I-D on communication diversion notification
event package.

So I really do not think there is any other alternate way to accomplish
what we are trying to propose in this I-D. 

Comments welcome

Thanks

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Wednesday, January 27, 2010 10:37 PM
To: DISPATCH
Subject: Re: [dispatch] Commentsrequestedon
draft-avasarala-dispatch-comm-div-notification

There are way to accomplish the same end goals as this draft suggests
using things that are very likely to predate RIM's IPR on the topic. For
example the ideas on using things similar to the dialog events package
or reporting events about call forking on proxies. I have a strong
preference for doing this in an IPR free way. I strongly encourage the
WG to explore alternative ways to solve these problems before deciding
what to do with this draft. 

> particular caller between 9 AM and 10 AM to her voicemail. But for 
> some reason she could have wrongly configured the rule as 9 to 10 AM 
> or could have put the caller id as wrong one. So it would be very 
required.

package?