Subject: Re: [dispatch] Commentsrequestedon draft-avasarala-dispatch-comm-div-notification

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 5 Feb 2010 20:24:30 +0800

Hi All

Any comments on how we can progress this I-D?

Thanks 

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Avasarala Ranjit-A20990
Sent: Friday, January 29, 2010 2:26 PM
To: Cullen Jennings; DISPATCH
Subject: Re: [dispatch]Commentsrequestedon
draft-avasarala-dispatch-comm-div-notification

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. 

Cullen <in my individual contributor role>

On Jan 15, 2010, at 2:49 AM, Avasarala Ranjit-A20990 wrote:

> 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
> 
> 
>> -----Original Message-----
>> 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,
>> 
>> 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-n
>> otification-02
>> 
>> Based on the comments received, we will talk to our ADs about this 
>> piece of work.
>> 
>> Thanks,
>> 
>> Gonzalo
>> DISPATCH co-chair
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 05 Feb 2010 09:47:35 -0600

Sorry; I just now tripped across this.

Probably the most important work the IETF does to foster innovation lies 
not in what we choose to standardize, but in what we choose to leave 
unstandardized. With rare exception, the IETF does not standardize how 
to implement services in SIP. One of the key philosophies that has been 
central to the development of the SIP protocol is that the IETF defines 
a rich and powerful set of protocol tools, and allows application 
developers to implement services using these tools.

This draft, however, is standardizing a service. No part of this is 
re-usable in any way.

So, what we really need to do here is back up to requirements: what are 
you trying to achieve? I looked through 24.604 briefly, and think I 
understand what you're trying to do here. And I'm sure you can define 
some generally useful, re-usable tools to achieve your goals.

I would offer that a general-purpose means for subscribing to the target 
generation steps at a SIP proxy would be both generally useful and 
sufficient to implement the service you have in mind.

/a

On 2/5/10 6:24 AM, Avasarala Ranjit-A20990 wrote:
> Cullen<in my individual contributor role>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 07 Feb 2010 18:05:38 -0500

inline...

Avasarala Ranjit-A20990 wrote:

>> 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?
>>
>> <Ranjit> The server looks for the incoming caller identity and the 
>> 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?
> 
> <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. 

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

OK. So once again I have to ask for a description of the system 
architecture(s) in which this event package makes sense - where the 
notifier would have the knowledge to make the proposed kind of 
notifications.

>> If the registered 
>>          contact is not an AoR, then the call cannot be routed to it 
>> and
> 
> 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.
> 
> <Ranjit-Jan27th> Agree with you on this.
> 
>> hence will be routed to the main AoR i.e sip:[email-masked] and the 
>> 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 !!

I'm am getting more confused, not less.

I think the draft needs some significant rewriting in terms of concepts 
and terminology, as well as assumed architecture, in order to be 
comprehensible in any context other that pure IMS. And frankly I don't 
understand it even if I restrict the context to IMS.

>> 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.
> 
> 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.
> 
> <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 does that simplify anything? If anything that makes it worse. 
Notifications go to the subscriber, and the content of that notification 
should in general have nothing to do with who the subscriber is. (But 
may be influenced by authorization policy.) Notifications are always 
in-dialog, to the remote target of that dialog, and hence pretty much 
never go to an AOR.

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

You are missing my point entirely. I'm not asking about where the 
notifications are *sent* (which is irrelevant). I'm asking about the 
*content* of those notifications, and of the filters that select which 
ones the subscriber is interested in.

Assume for the moment that we have AOR sip:[email-masked].
And registered with that AOR are contact addresses 
sip:[email-masked] and sip:[email-masked].

Some UA (I'll not say which) is concerned about diversions related to 
that AOR. It subscribes to the comm-div package that sip:[email-masked]. 
It may include some sort of filter in the subscription.

If a request comes in to the AOR, and neither of the contacts responds, 
a server serving that AOR (perhaps an AS) may eventually decide to 
forward the request to a VM server. I can see how this would be 
considered a real diversion, and how the server would know about it. So 
it can generate a NOTIFY reporting this diversion.

Next, its possible that Alice, from her mobile phone, establishes a 
forwarding rule, that sends all incoming calls to the AOR to 
sip:[email-masked]. The server would apply this rule, as policy, to all 
incoming requests to the AOR, bypassing contact routing. Again its 
unremarkable that it would be able to generate a notification when 
carrying out such a retargeting.

None of that requires any filter on the address at which diversion takes 
place, because it takes place exactly on diversion of requests to the 
same URI to which the subscription was made.

Your filter package implies that the notifier can generate notifications 
for cases where the diversion takes place from some URI *other* than the 
one for which the subscriptions is made. I am guessing you mean cases 
when the diversion takes place after the call has been retargeted to one 
of the contacts. I have two problems with that:

1) how would the server for sip:[email-masked] know that a diversion has 
occurred on a request targetted to sip:[email-masked]?

2) even if it had a way to discover that, how would a subscriber know 
the URI sip:[email-masked] in order to place it in a filter?

But I find I am repeating myself (see below from before.)
There must be some fundamental difference in perspective that is 
preventing us from understanding one another.

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

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Mon, 8 Feb 2010 18:09:20 +0800

Hi Paul

My comments <Ranjit-Feb08> 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 08, 2010 4:36 AM
To: Avasarala Ranjit-A20990
Cc: Elwell, John; DISPATCH
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification

inline...

> *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.)
> 
> <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-Feb08> The proposed I-D is actually for registering the proposed
event package for the communication diversion service described in 3GPP
TS 24.604. So here the notifier would the AS where the communication
diversion service is running. So yes it would have knowledge of on whose
behalf it is
Doing the diversion and to whom it should notify.

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

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

<Ranjit-Feb08> Actually the terminology and the service in general is
explained in 24.604 (Section 4.10). So we felt that this I-D would just 
Register the proposed event package.

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

> that notifications always go to the main AoR i.e the Public User Bu
> Identity (in IMS)

<Ranjit-Feb08> True. Notification go to the subscribed entity as shown
in the example in 24.604. 

> to particular devices?
> 
> <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

<Ranjit-Feb08> The content of notifications are the elements specified
in the event pacakge. The example shows both a sample notification and
the elements that can be used as filters to control the content of
notifications. E.g. Section 4.10.1.1.1.2 of 24.604

<Ranjit-Feb08> True. So here the notification would be towards
sip:[email-masked] with entity="sip:[email-masked] OR
entity=sip:[email-masked] on whose behlaf the diversion took place
or where the call landed. 

<Ranjit-Feb08> so here if Alice gets notified whenever a incoming call
to her gets forwarded to Bob. If she sets a filter criteria like
timeofday, then only incoming calls during that time get notified and
not others. So the notifications depend on the target of the incoming
call and other specified criteria. 

<Ranjit-Feb08> why not? Filters can be set based on time, range of time
or particular day or context (alice is OOO, etc)

<Ranjit-Feb08> No No. Notifier generates notifications only for
diversions that take place on behalf of the subscribed entity and not
others. So here sip:[email-masked] subscribes to diversions taking place
at any of its contacts and get notified based on filter criteria. The
filter critera can specify which contacts the notification is required
for and which of those notifications are not required. 

But I find I am repeating myself (see below from before.) There must be
some fundamental difference in perspective that is preventing us from
understanding one another.

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

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

	Thanks,
	Paul

Regards
Ranjit

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 8 Feb 2010 14:43:09 +0100

Can I understand where this discussion is going?

The relevant paragraph of http://tools.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt is:

   Individuals may wish to publish SIP Event packages that they believe
   fall outside the scope of any chartered work currently in RAI.
   Individual proposals for registration of a SIP event package MUST
   first be published as Internet-drafts for review by the DISPATCH
   Working Group, or the working group, mailing list, or expert
   designated by the RAI Area Directors if the DISPATCH Working Group
   has closed.  Proposals should include a strong motivational section,
   a thorough description of the proposed syntax and semantics, event
   package considerations, security considerations, and examples of
   usage.  Authors should submit their proposals as individual Internet-
   Drafts, and post an announcement to the working group mailing list to
   begin discussion.  The DISPATCH Working Group will determine if a
   proposed package is a) an appropriate usage of SIP which should be
   spun into a new effort, b) applicable to SIP but not sufficiently
   interesting, general, or in-scope to adopt as a working group effort,
   c) contrary to similar work chartered in an existing effort, or d)
   recommended to be adopted as or merged with chartered work elsewhere
   in RAI. 

Are we still trying to prove somehow that this is generally applicable, for which I strongly suspect the answer is NO and it never will be no matter how much manipulation it requires.

Are are we trying to identify that there is some error in the documentation that needs correction?

regards

Keith

> [mailto:[email-masked]] On Behalf Of Avasarala 
> Ranjit-A20990
> Sent: Monday, February 08, 2010 10:09 AM
> To: Paul Kyzivat
> Cc: DISPATCH
> architecture(s) in which this event package makes sense - 
> where the notifier would have the knowledge to make the 
> proposed kind of notifications.
> 
> <Ranjit-Feb08> The proposed I-D is actually for registering 
> the proposed event package for the communication diversion 
> service described in 3GPP TS 24.604. So here the notifier 
> would the AS where the communication diversion service is 
> running. So yes it would have knowledge of on whose behalf it 
> is Doing the diversion and to whom it should notify.
> 
> >> If the registered 
> I think the draft needs some significant rewriting in terms 
> of concepts and terminology, as well as assumed architecture, 
> in order to be comprehensible in any context other that pure 
> IMS. And frankly I don't understand it even if I restrict the 
> context to IMS.
> 
> <Ranjit-Feb08> Actually the terminology and the service in 
> general is explained in 24.604 (Section 4.10). So we felt 
> that this I-D would just Register the proposed event package.
> 
> Notifications go to the subscriber, and the content of that 
> notification should in general have nothing to do with who 
> the subscriber is. (But may be influenced by authorization 
> policy.) Notifications are always in-dialog, to the remote 
> target of that dialog, and hence pretty much never go to an AOR.
> 
> <Ranjit-Feb08> True. Notification go to the subscribed entity 
> as shown in the example in 24.604. 
> 
> You are missing my point entirely. I'm not asking about where 
> the notifications are *sent* (which is irrelevant). I'm 
> asking about the
> *content* of those notifications, and of the filters that 
> select which ones the subscriber is interested in.
> 
> <Ranjit-Feb08> The content of notifications are the elements 
> specified in the event pacakge. The example shows both a 
> sample notification and the elements that can be used as 
> filters to control the content of notifications. E.g. Section 
> 4.10.1.1.1.2 of 24.604
> 
> Some UA (I'll not say which) is concerned about diversions 
> related to that AOR. It subscribes to the comm-div package 
> that sip:[email-masked]. 
> If a request comes in to the AOR, and neither of the contacts 
> responds, a server serving that AOR (perhaps an AS) may 
> eventually decide to forward the request to a VM server. I 
> can see how this would be considered a real diversion, and 
> how the server would know about it. So it can generate a 
> NOTIFY reporting this diversion.
> 
> <Ranjit-Feb08> True. So here the notification would be 
> towards sip:[email-masked] with 
> entity="sip:[email-masked] OR 
> entity=sip:[email-masked] on whose behlaf the diversion 
> took place or where the call landed. 
> 
> Next, its possible that Alice, from her mobile phone, 
> establishes a forwarding rule, that sends all incoming calls 
> to the AOR to sip:[email-masked]. The server would apply this 
> rule, as policy, to all incoming requests to the AOR, 
> bypassing contact routing. Again its unremarkable that it 
> would be able to generate a notification when carrying out 
> such a retargeting.
> 
> <Ranjit-Feb08> so here if Alice gets notified whenever a 
> incoming call to her gets forwarded to Bob. If she sets a 
> filter criteria like timeofday, then only incoming calls 
> during that time get notified and not others. So the 
> notifications depend on the target of the incoming call and 
> other specified criteria. 
> 
> None of that requires any filter on the address at which 
> diversion takes place, because it takes place exactly on 
> diversion of requests to the same URI to which the 
> subscription was made.
> 
> <Ranjit-Feb08> why not? Filters can be set based on time, 
> range of time or particular day or context (alice is OOO, etc)
> 
> Your filter package implies that the notifier can generate 
> notifications for cases where the diversion takes place from 
> some URI *other* than the one for which the subscriptions is 
> made. I am guessing you mean cases when the diversion takes 
> place after the call has been retargeted to one of the 
> contacts. I have two problems with that:
> 
> <Ranjit-Feb08> No No. Notifier generates notifications only 
> for diversions that take place on behalf of the subscribed 
> entity and not others. So here sip:[email-masked] subscribes 
> to diversions taking place at any of its contacts and get 
> notified based on filter criteria. The filter critera can 
> specify which contacts the notification is required for and 
> which of those notifications are not required. 
> 
> 1) how would the server for sip:[email-masked] know that a 
> diversion has occurred on a request targetted to 
> sip:[email-masked]?
> 
> 2) even if it had a way to discover that, how would a 
> subscriber know the URI sip:[email-masked] in order 
> to place it in a filter?
> 
> There must be some fundamental difference in perspective that 
> is preventing us from understanding one another.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Feb 2010 09:10:24 -0500

> Are we still trying to prove somehow that this is generally applicable, for which I strongly suspect the answer is NO and it never will be no matter how much manipulation it requires.

I started out with the working assumption that this could be of general 
interest. I still think something addressing the same general area might 
be. But I am reaching the conclusion that the authors have no particular 
interest in generalizing it.

So I think it is probably better viewed as something specific for the 
IMS community. If I understand the procedures, it would be ok to publish 
this as such, but think the text should be very clear about the area of 
applicability. As currently worded I think people outside the IMS 
community might attempt to implement it without the guidance of 
additional IMS documents. IMO if they did so the likelihood of 
interoperable implementations would be slim to none.

	Thanks,
	Paul

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 9 Feb 2010 00:45:54 +0800

Hi Paul, Keith

True. This event package is intended for CDIV procedures outlined in
24.604. The specific CDIV procedures and the event package are already
described in 24.604. The schema too is well explained. But 3GPP wanted
the event package and the schema to be registered through a
informational or standards track RFC as per IETF.

So we submitted an I-D proposing the CDIV notification event package
putting reference to 24.604. 

Thanks 

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, February 08, 2010 7:40 PM
To: DRAGE, Keith (Keith)
Cc: Avasarala Ranjit-A20990; DISPATCH
Subject: Re: [dispatch] Comments

DRAGE, Keith (Keith) wrote:
> The relevant paragraph of
http://tools.ietf.org/id/draft-peterson-rai-rfc3427bis-04.txt is:
> Are we still trying to prove somehow that this is generally
applicable, for which I strongly suspect the answer is NO and it never
will be no matter how much manipulation it requires.

	Thanks,
	Paul

>> <Ranjit-Feb08> The proposed I-D is actually for registering the 
>> proposed event package for the communication diversion service 
>> described in 3GPP TS 24.604. So here the notifier would the AS where 
>> the communication diversion service is running. So yes it would have 
>> knowledge of on whose behalf it is Doing the diversion and to whom it

>> should notify.
>> I think the draft needs some significant rewriting in terms of 
>> concepts and terminology, as well as assumed architecture, in order 
>> to be comprehensible in any context other that pure IMS. And frankly 
>> I don't understand it even if I restrict the context to IMS.
>>

>> explained in 24.604 (Section 4.10). So we felt that this I-D would 
>> just Register the proposed event package.
>>
>>> Identity (in IMS) And not to any of the registered AoR irrespective 
>>> of who
>> the diverting
>>
>> notification should in general have nothing to do with who the 
>> subscriber is. (But may be influenced by authorization
>> policy.) Notifications are always in-dialog, to the remote target of 
>> that dialog, and hence pretty much never go to an AOR.
>>
>> <Ranjit-Feb08> True. Notification go to the subscribed entity as 
>> shown in the example in 24.604.
>>
>>>> the diversion occurs, the new ip address is taken prior to sending 
>>>> the notification.
>> *content* of those notifications, and of the filters that select 
>> which ones the subscriber is interested in.
>>
>> specified in the event pacakge. The example shows both a sample 
>> notification and the elements that can be used as filters to control 
>> the content of notifications. E.g. Section
>> 4.10.1.1.1.2 of 24.604
>>

>> responds, a server serving that AOR (perhaps an AS) may eventually 
>> decide to forward the request to a VM server. I can see how this 
>> would be considered a real diversion, and how the server would know 
>> about it. So it can generate a NOTIFY reporting this diversion.
>>
>> entity=sip:[email-masked] on whose behlaf the diversion took 
>> place or where the call landed.
>>
>> <Ranjit-Feb08> so here if Alice gets notified whenever a incoming 
>> call to her gets forwarded to Bob. If she sets a filter criteria like

>> None of that requires any filter on the address at which diversion 
>> takes place, because it takes place exactly on diversion of requests 
>> to the same URI to which the subscription was made.
>>
>> <Ranjit-Feb08> why not? Filters can be set based on time, range of 
>> time or particular day or context (alice is OOO, etc)
>>
>> notifications for cases where the diversion takes place from some URI

>> *other* than the one for which the subscriptions is made. I am 
>> guessing you mean cases when the diversion takes place after the call

>> has been retargeted to one of the contacts. I have two problems with 
>> that:
>>

>> others. So here sip:[email-masked] subscribes to diversions taking 
>> place at any of its contacts and get notified based on filter 
>> criteria. The filter critera can specify which contacts the 
>> notification is required for and which of those notifications are not

>> required.
>>
>> 1) how would the server for sip:[email-masked] know that a diversion 
>> has occurred on a request targetted to sip:[email-masked]?
>>

>> But I find I am repeating myself (see below from before.) There must 
>> be some fundamental difference in perspective that is preventing us 
>> from understanding one another.
>>

---

From: Dean Willis <[email-masked]>
Date: Mon, 08 Feb 2010 16:39:09 -0600

> putting reference to 24.604. 

So I think we're jut arguing about the applicability statement.

Something like "Applicability Statement: The event package defined in
this specification is designed to work in the context of IMS, using
specifics thereof which are defined in 3GPP specification 24.604.",
along with appropriate bibliography entries.

Further, the AS should go on to state how the target environment, in
general, differs from the "general SIP environment", specifically
discussing the assumptions about which servers know about diversion and
can act as notifiers.

--
Dean