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

[Paul Kyzivat <[e-mail]>]

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