Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00

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

Hi Mary, John and Paul

After further thought, we feel that since the CDIV service is already standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence there is no need for explicitly stating the requirements of a CDIV service again in a separate I-D or document. 

Also regarding any existing mechanisms, we feel there is/are no existing mechansim(s) for getting notifications of a particular call diversion service for a particular subscriber other than subscribing to the Call Diversion Notification Information Event package which is already proposed in 3GPP spec 24.604.

Now as per 3GPP's directive, we need to formally standardize the event package in IETF and hence the draft.

So please let us know how we can take this draft forward to a meaningful conclusion.

Thanks


Regards
Ranjit

-----Original Message-----
From: Mary Barnes [mailto:[e-mail]] 
Sent: Friday, May 21, 2010 7:35 PM
To: Avasarala Ranjit-A20990
Cc: [e-mail]; [e-mail]; DISPATCH
Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00

Ranjit,

John's suggestion is the right approach - that's really the only way this work is going to get traction within DISPATCH.

Regards,
Mary
DISPATCH WG co-chair

On Fri, May 21, 2010 at 3:04 AM, Elwell, John <[e-mail]> wrote:
> Ranjit,
>
> What I would like to see are:
> - statement of requirements (for both barring and diversion);
> - survey of solution space, with pros and cons (e.g., event package(s) 
> as so far described versus other approaches);
> - in case of event package, pros and cons of combining diversion and barring into a single event package.
>
> Getting these fundamental principles established is more important than working on details of an event package.
>
> John
>
>> -----Original Message-----
>> From: Avasarala Ranjit-A20990 [mailto:[e-mail]]
>> Sent: 21 May 2010 08:00
>> To: Paul Kyzivat; Elwell, John
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [dispatch] FW: New Version 
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>>
>> Hi Paul
>>
>> So what is the consensus? Come up with a requirements I-D and then 
>> continue on the event package?
>>
>> Thanks
>>
>>
>> Regards
>> Ranjit
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Thursday, May 20, 2010 9:49 PM
>> To: Elwell, John
>> Cc: Avasarala Ranjit-A20990; [e-mail]; [e-mail]
>> Subject: Re: [dispatch] FW: New Version 
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>>
>>
>>
>> Elwell, John wrote:
>> > I too think this work is potentially interesting beyond
>> IMS, and would
>> find it more attractive to combine requirements and have a single 
>> event package.
>> >
>> > Of course, there are other ways of achieving this. There could be 
>> > an
>> HTTP resource that allows me to inspect recent calls that have been 
>> subject to automatic call handling, e.g., by being diverted or barred.
>> Then I could use
>> https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to 
>> be notified of changes to that resource. No SIP standardisation required.
>> It would be interesting to know whether this would solve requirements.
>>
>> I guess this is fundamentally about automatic call handling.
>> Seems like it might be in the scope of BLISS, except I gather BLISS 
>> is winding down.
>>
>>       Thanks,
>>       Paul
>>
>> > John
>> >
>> >> -----Original Message-----
>> >> From: Paul Kyzivat [mailto:[e-mail]]
>> >> Sent: 20 May 2010 16:33
>> >> To: Avasarala Ranjit-A20990
>> >> Cc: Elwell, John; [e-mail]; [e-mail]
>> >> Subject: Re: [dispatch] FW: New Version
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>
>> >>
>> >>
>> >> Avasarala Ranjit-A20990 wrote:
>> >>> Hi Paul
>> >>>
>> >>> No I am not asking for a new WG. I wanted directions to
>> >> take this I-D
>> >>> forward. Like should we merge it with CDIV one as John Elwell was 
>> >>> suggesting or keep this separate - which I think is better.
>> >> Well, with the new operating rules for RAI and DISPATCH,
>> if you want
>> >> this to be worked on by some WG, then we either have to
>> find one to
>> >> recharter to do the work, or else we have to spin up
>> another. I don't
>>
>> >> see any obvious existing one to take on the work.
>> >>
>> >> I *do* think this work is potentially interesting beyond IMS.
>> >> A new WG
>> >> is a *possibility* if the work can be framed in a way that people 
>> >> want to work on. IMO that will mean first defining the
>> requirements,
>> >> without presuming the mechanism. And combining the
>> requirements for
>> >> CDIV and barring would probably make it more attractive.
>> >>
>> >>    Thanks,
>> >>    Paul
>> >>
>> >>> Regards
>> >>> Ranjit
>> >>>
>> >>> -----Original Message-----
>> >>> From: Paul Kyzivat [mailto:[e-mail]]
>> >>> Sent: Thursday, May 20, 2010 6:47 PM
>> >>> To: Avasarala Ranjit-A20990
>> >>> Cc: Elwell, John; [e-mail]; [e-mail]
>> >>> Subject: Re: [dispatch] FW: New Version
>> >>>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>
>> >>>
>> >>>
>> >>> Avasarala Ranjit-A20990 wrote:
>> >>>> Hi
>> >>>>
>> >>>> So is the consensus to proceed forward?
>> >>> Proceed forward in what way? Are you asking for a new WG?
>> >>>
>> >>>   Thanks,
>> >>>   Paul
>> >>>
>> >>>> Regards
>> >>>> Ranjit
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Elwell, John [mailto:[e-mail]]
>> >>>> Sent: Thursday, May 20, 2010 12:15 PM
>> >>>> To: Avasarala Ranjit-A20990; [e-mail]
>> >>>> Cc: [e-mail]
>> >>>> Subject: RE: [dispatch] FW: New Version
>> >>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>> Sorry, I thought I had already responded, but clearly not.
>> >>>>
>> >>>> I am still of the opinion that there is sufficient synergy
>> >> between the
>> >>>> two event packages that they can be combined into a single event 
>> >>>> package. This would have the benefit of being able to have
>> >> a single
>> >>>> subscription to get all information relating to automatic
>> >> handling of
>> >>>> incoming calls, rather than being forced to subscribe
>> >> twice. If you
>> >>>> only want information about diverted calls, or only
>> >> information about
>> >>>> barred calls, you could filter accordingly. If you want
>> different
>> >>>> filtering criteria, or different subscription times for
>> >> the two, there
>> >>>> is nothing to stop you having two separate subscriptions. But we 
>> >>>> should not penalise the simple case by forcing two
>> >> subscriptions where
>> >>>> one would do.
>> >>>>
>> >>>> John
>> >>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Avasarala Ranjit-A20990 [mailto:[e-mail]]
>> >>>>> Sent: 20 May 2010 05:33
>> >>>>> To: Elwell, John; [e-mail]
>> >>>>> Cc: [e-mail]
>> >>>>> Subject: RE: [dispatch] FW: New Version
>> >>>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>> Hi All
>> >>>>>
>> >>>>> Any further comments on this I-D and suggestions for next steps?
>> >>>>>
>> >>>>> Thanks
>> >>>>>
>> >>>>>
>> >>>>> Regards
>> >>>>> Ranjit
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: [e-mail]
>> >> [mailto:[e-mail]] On
>> >>>>> Behalf Of Avasarala Ranjit-A20990
>> >>>>> Sent: Friday, May 14, 2010 11:49 AM
>> >>>>> To: Elwell, John; [e-mail]
>> >>>>> Subject: Re: [dispatch] FW: New Version
>> >>>>>
>> >>
>> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>> Hi John
>> >>>>>
>> >>>>> This I-D on communication barring notification talks
>> >> about an event
>> >>>>> package for reporting the notification information of
>> >> communication
>> >>>>> barrings (call blocking) that happen in the network on
>> >> behalf of the
>> >>>>> users.
>> >>>>>
>> >>>>> For e.g if Alice sets a call blocking rule that all calls
>> >> from Bob
>> >>>>> need to be blocked, then the network blocks all calls from Bob 
>> >>>>> towards Alice.
>> >>>>> So here
>> >>>>> The notification information will include the details
>> of the call
>> >>>>> block
>> >>>>> - i.e (1) the identity of caller (Bob) (2) time of block
>> >> (2) reason
>> >>>>> for block, etc
>> >>>>>
>> >>>>> Yes I agree with you that there is synergy between this
>> >> I-D and the
>> >>>>> one on CDIV, since both of them deal with reporting of
>> >> events that
>> >>>>> occur in the network. While CDIV deals with communication
>> >> diversion,
>> >>>>> this one deals with ICB service. Though both the event
>> >> packages are
>> >>>>> similar in terms of subscriptions and format, their
>> execution and
>> >>>>> user preference may vary. So they need to be looked at
>> differently
>>
>> >>>>> and standardized seperately.
>> >>>>>
>> >>>>>
>> >>>>> Regards
>> >>>>> Ranjit
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Elwell, John [mailto:[e-mail]]
>> >>>>> Sent: Thursday, May 13, 2010 6:25 PM
>> >>>>> To: Avasarala Ranjit-A20990; [e-mail]
>> >>>>> Cc: T Satyanarayana-A12694
>> >>>>> Subject: RE: [dispatch] FW: New Version Notification 
>> >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>
>> >>>>> Ranjit,
>> >>>>>
>> >>>>> It is not entirely clear to me what the notifications
>> report. For
>> >>>>> example, in 6.7, it says "Typically, it will send
>> >>>>>    one when a communication barring is enacted on behalf of the
>> >>> user."
>> >>>>> What is meant by "enacted" here? Is it when some entity,
>> >> on behalf of
>> >>>>> the user, perhaps through some web page, establishes a
>> >> communication
>> >>>>> barring rule? Or is it when an inbound communication
>> >> arrives and is
>> >>>>> processed in accordance with some pre-existing
>> >> communication barring
>> >>>>> rule? I thought at first it was the former, but I am
>> >> tending towards
>> >>>>> thinking it is the latter. Some clarification would be useful.
>> >>>>>
>> >>>>> Assuming it is the latter, there is obviously some synergy with 
>> >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with 
>> >>>>> reporting inbound communications that have been subject
>> >> to some rule,
>> >>>>> the rule being conditional on certain criteria such as
>> caller ID.
>> >>>>> Where the conditions are met for a given call to be
>> subject to a
>> >>>>> given
>> >>>>> rule, a notification in accordance with one or the other event 
>> >>>>> package will be triggered. I fail to see the reason for having
>> >> two separate
>> >>>>> event packages, since this means two separate
>> specifications, two
>> >>>>> different subscriptions, two different formats, etc..
>> >>>>>
>> >>>>> John
>> >>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: [e-mail] 
>> >>>>>> [mailto:[e-mail]] On Behalf Of Avasarala 
>> >>>>>> Ranjit-A20990
>> >>>>>> Sent: 13 May 2010 11:28
>> >>>>>> To: [e-mail]
>> >>>>>> Cc: T Satyanarayana-A12694
>> >>>>>> Subject: [dispatch] FW: New Version Notification for 
>> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>>
>> >>>>>> Hi all
>> >>>>>>
>> >>>>>> I have submitted a new I-D on communication barring
>> notification
>> >>>>>> information based on the following
>> >>>>>>
>> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement
>> >> of dynamic
>> >>>>>> blocking of incoming communications of 3GPP TS 22.173
>> >>>>>>
>> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS
>> >> of 3GPP TS
>> >>>>>> 24.611
>> >>>>>>
>> >>>>>> The draft can be accessed from:
>> >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n
>> >>>>>> otificatio
>> >>>>>> n-00.txt
>> >>>>>>
>> >>>>>> Please review and comment.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>>
>> >>>>>> Regards
>> >>>>>> Ranjit
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: IETF I-D Submission Tool [mailto:[e-mail]]
>> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM
>> >>>>>> To: Avasarala Ranjit-A20990
>> >>>>>> Cc: [e-mail]
>> >>>>>> Subject: New Version Notification for 
>> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00
>> >>>>>>
>> >>>>>>
>> >>>>>> A new version of I-D,
>> >>>>>>
>> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been
>> >>>>>> successfully submitted by Ranjit Avasarala and posted to
>> >> the IETF
>> >>>>>> repository.
>> >>>>>>
>> >>>>>> Filename:
>> >> draft-avasarala-dispatch-comm-barring-notification
>> >>>>>> Revision:       00
>> >>>>>> Title:          A Session Initiation Protocol (SIP) Event 
>> >>>>>> Package for Communication Barring Notification Information in
>> support of the
>> >>>>>> Dynamic Incoming Communication Barring (ICB)
>> Notification service
>> >>>>>> Creation_date:  2010-05-13
>> >>>>>> WG ID:          Independent Submission
>> >>>>>> Number_of_pages: 22
>> >>>>>>
>> >>>>>> Abstract:
>> >>>>>> 3GPP is defining the protocol specification for the
>> >> Communication
>> >>>>>> Barring (CB) service using IP Multimedia (IM) Core
>> Network (CN)
>> >>>>>> subsystem supplementary service and more particularly
>> >> the dynamic
>> >>>>>> incoming communication barring service.  As part of dynamic
>> >>>>> incoming
>> >>>>>> communication barring (ICB) service, a SIP based Event package 
>> >>>>>> framework is used for notifying users about
>> >> communication barrings
>> >>>>>> (dynamic and rule based) of their incoming communication
>> >> sessions.
>> >>>>>> This document proposes a new SIP event package for allowing
>> >>>>> users to
>> >>>>>> subscribe to and receive such notifications.  Users can
>> >>>>> further define
>> >>>>>
>> >>>>>> filters to control the rate and content of such notifications.
>> >>>>>> The proposed event package is applicable to the ICB
>> >> supplementary
>> >>>>>> service in IMS and may not be applicable to the
>> general internet.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> The IETF Secretariat.
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> dispatch mailing list
>> >>>>>> [e-mail]
>> >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>>
>> >>>>> _______________________________________________
>> >>>>> dispatch mailing list
>> >>>>> [e-mail]
>> >>>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>>
>> >>>> _______________________________________________
>> >>>> dispatch mailing list
>> >>>> [e-mail]
>> >>>> https://www.ietf.org/mailman/listinfo/dispatch
>> >>>>
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>