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

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"                                                                                                     
                      <taylor@nortel.com>         To:       Miguel Garcia <Miguel.An.Garcia@nokia.com>                                    
                      Sent by:                    cc:       sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>             
                      sipping-tispan-bounc        Subject:  Re: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements           
                      es@ietf.org                                                                                                         

                      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
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan