Re: [dispatch] Comments requestedondraft-avasarala-dispatch-comm-div-notification

["Avasarala Ranjit-A20990" <[e-mail]>]

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:[e-mail]] 
Sent: Monday, February 08, 2010 7:40 PM
To: DRAGE, Keith (Keith)
Cc: Avasarala Ranjit-A20990; DISPATCH
Subject: Re: [dispatch] Comments
requestedondraft-avasarala-dispatch-comm-div-notification



DRAGE, Keith (Keith) wrote:
> 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.

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

> Are are we trying to identify that there is some error in the
documentation that needs correction?
> 
> regards
> 
> Keith
> 
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]] On Behalf Of Avasarala 
>> Ranjit-A20990
>> Sent: Monday, February 08, 2010 10:09 AM
>> To: Paul Kyzivat
>> Cc: DISPATCH
>> Subject: Re: [dispatch] Comments
>> requestedondraft-avasarala-dispatch-comm-div-notification
>>
>> Hi Paul
>>
>> My comments <Ranjit-Feb08>
>>
>>
>> Regards
>> Ranjit
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> 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...
>>
>> Avasarala Ranjit-A20990 wrote:
>>
>>>> Assuming sip:[e-mail] is not an AOR, but
>> rather is a
>>>> registered contact to sip:[e-mail], 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.
>>
>> <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 
>>>>          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:[e-mail] 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:[e-mail] is
>> the AoR and
>>
>>> diversions are taking Place for sip:[e-mail], then 
>>> notifications will be sent to sip:[e-mail] only and not to 
>>> sip:[e-mail]. 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.
>>
>> <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.
>>
>>>> But if sip:[e-mail] 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 Bu 
>>> 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:[e-mail].
>> 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.
>>
>> <Ranjit-Feb08> True. Notification go to the subscribed entity as 
>> shown in the example in 24.604.
>>
>>>> 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.
>>
>> <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
>>
>> Assume for the moment that we have AOR sip:[e-mail].
>> And registered with that AOR are contact addresses 
>> sip:[e-mail] and sip:[e-mail].
>>
>> Some UA (I'll not say which) is concerned about diversions related to

>> that AOR. It subscribes to the comm-div package that 
>> sip:[e-mail].
>> 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.
>>
>> <Ranjit-Feb08> True. So here the notification would be towards 
>> sip:[e-mail] with entity="sip:[e-mail] OR 
>> entity=sip:[e-mail] 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:[e-mail]. 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:[e-mail] 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:[e-mail] know that a diversion 
>> has occurred on a request targetted to sip:[e-mail]?
>>
>> 2) even if it had a way to discover that, how would a subscriber know

>> the URI sip:[e-mail] 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:[e-mail] and sip:[e-mail].
>> AFAIK that
>>> isn't the norm, so if you are assuming it then please make
>> that clear.
>>
>> 	Thanks,
>> 	Paul
>>
>> Regards
>> Ranjit
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>