Re: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

["Tom-PT Taylor" <[e-mail]>]

I fetched the directive, from
http://register.consilium.eu.int/pdf/en/02/st03/03636en2.pdf

It's a well-informed piece of work.  I note, as you have, that there is 
no support for REQ-ACR-2.  I wonder if Roland has misunderstood or if 
this is a national requirement only.

Taylor, Tom-PT [CAR:5N00:EXCH] wrote:
> This is a clear statement of REQ-ACR-1 and the surrounding context in
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02a.txt 
> 
> 
> However, what we have actually been arguing over is REQ-ACR-2.
> 
> Philip Mart wrote:
> 
>> I wonder if I can help you avoid a rathole! If we go back to the original
>> source of the requirement we may be able to remove some of this abiguity.
>>
>> The base requirement as a stage 1 like text is in DIRECTIVE 2002/58/EC OF
>> THE EUROPEAN PARLIAMENT AND OF THE COUNCIL  (Directive on privacy and
>> electronic communications)and is available in all community languages 
>> from
>> the www.europa.eu.int. The relevant text is in Article 8 paragraph 3 and
>> states:
>>
>> 3. Where presentation of calling line identification is offered
>> and where the calling line identification is presented prior to
>> the call being established, the service provider must offer the
>> called subscriber the possibility, using a simple means, of
>> rejecting incoming calls where the presentation of the calling
>> line identification has been prevented by the calling user or
>> subscriber.
>>
>> Calling Line identity is not defined in this directive but the 
>> requirement
>> to make it available comes from Article 29 of the Universal Service
>> Directive (2002/22/EC) which is specifically related to undertakings that
>> operate public telephone networks.
>>
>> 1) Thus calling line identification can be restricted, if need be, to the
>> information conveyed by a TelUri. The requirement is also limited to
>> presentation which occurs before the call is established.
>>
>> 2) The obligation is on the service provider so the assumption that it 
>> can
>> be left to a customer's User Agent is not valid.
>>
>> 3) We do not need to guess the meaning of anonymous, the requirement 
>> is to
>> reject calls where the caller has chosen not to provide a calling line
>> identity. If this happened because he is connected to the network
>> anonymously, and there is also a possibility to provide an identity, then
>> the caller has chosen to withold CLI. If there is no network 
>> capability to
>> provide a CLI the then it is not the caller who prevented the 
>> presentation
>> of the identity and so the feature should not be activated.
>>
>> The ETSI stage 1 requirements in clause 5 of ETSI EN 301 798 states:
>>
>> The Anonymous Call Rejection (ACR) supplementary service allows the 
>> served
>> user to reject incoming calls from users or subscribers who have 
>> restricted
>> the presentation of their calling line identity according to the CLIR
>> supplementary service [3] and [5].
>>
>> ACR will reject all calls with CLI marked "presentation restricted"
>> according to CLIR. The calls are rejected regardless of the current state
>> (e.g. free or busy) of the served user's access. The ACR supplementary
>> service shall not reject calls with a CLI marked "presentation restricted
>> by network". The served user's ability to originate calls is 
>> unaffected by
>> the ACR supplementary service.
>>
>> The calling user shall be given an appropriate indication that the 
>> call has
>> been rejected due to the application of the ACR supplementary service.
>>
>> NOTE: The method of rejection of anonymous calls is a service provider
>> option, and may include the
>> functionality where all anonymous calls are forwarded to e.g. a voice 
>> mail
>>
>> It can be seen that this is a restatement of the directive within the
>> context of the ISDN.
>>
>> 4) It is here that we get the requirement about the indication. Note that
>> the word indication does not refer to a protocol message, instead it is
>> just an indication to a person and could be aural, visual or tactile 
>> to the
>> calling user that a successful call might be made if he behaves
>> differently. This sending of information to allow behavioural 
>> modification
>> is a normal in both the ISDN and SIP.
>>
>> At the real "requirements" level I cannot find where any authorised 
>> caller
>> should be given special treatment. I think that the police are 
>> expected to
>> release their CLI, after all it could be just a presentation number and
>> doesn't even have to be reachable to bypass the ACR mechanism.
>>
>> I hope this is one some use
>>
>>
>>
>>                                                                                                                                           
>>                       "Tom-PT 
>> Taylor"                                                                                                     
>>                       <[e-mail]>         To:       Miguel 
>> Garcia <[e-mail]>                                    
>>                       Sent by:                    cc:       
>> [e-mail], "Alexeitsev, D" 
>> <[e-mail]>                                   
>> sipping-tispan-bounc        Subject:  Re: AW: AW: [Sipping-tispan] 
>> TISPAN requirements, first requiements                                 
>> [e-mail]                                                                                                         
>>                                                                                                                                           
>>                                                                                                                                           
>>                       25/08/2005 
>> 14:59                                                                                                    
>>                                                                                                                                           
>>                                                                                                                                           
>>
>>
>>
>>
>> You are missing a case.  The distinction is whether the caller is
>> anonymous to the network as well as to the called party.  So one of the
>> ACR cases is when the network has the identity of the caller but will
>> not disclose it due to operation of the Privacy service.
>>
>> Miguel Garcia wrote:
>>
>>> So what is an anonymous user? An anonymous user is one for which his
>>> identity is not determined. The reason why a user is anonymous is
>>> another story (the user want, or the network can't provide an identity),
>>> but they are anonymous in both cases.
>>>
>>> /Miguel
>>>
>>> Tom-PT Taylor wrote:
>>>
>>>
>>>> I think your requirement is not quite accurate even at this level of
>>>> abstraction.  Roland has identified two different cases.  One is your
>>>> "certain anonymous users", but the other is the case where the user
>>>> identity is unable due to the network's inability to provide it.
>>>>
>>>> I guess I can see your point about pushing too hastily to mechanism.
>>>> Roland actually identified the information that might be used to
>>>> resolve the issue at the rejection point: on the one hand, the
>>>> identity of the caller if present in a P-A-Id, and on the other hand,
>>>> the absence of a P-A-Id.  It may be that this is all that is needed,
>>>> and no further discussion is required in SIPPING.  (Of course, that's
>>>> assuming that the number of authorized caller identities any one
>>>> rejection point has to keep track of is limited and provisionable.)
>>>>
>>>> Miguel Garcia wrote:
>>>>
>>>>
>>>>> Tom:
>>>>>
>>>>> I agree with you in the essence, but you are referring to a solution,
>>>>> not to a requirement. Essentially, whenever you need to speak about
>>>>> an "indicator", it raises an alarm in my head that you are speaking
>>>>> about a possible solution rather than a requirement.
>>>>>
>>>>> So the requirement is tha there are certain anonymous users that are
>>>>> not subject to be filtered by ACR. Then we can further discuss the
>>>>> solution, which is probably going in the direction you suggest.
>>>>>
>>>>> /Miguel
>>>>>
>>
>> ...
>>
>>
>> _______________________________________________
>> Sipping-tispan mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>
>>
>>
>>
>>
>>
>>
> 
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 
> 


_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan