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

[Paul Kyzivat <[e-mail]>]

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