RE: [Sipping-tispan] ACR Requirements

["GARCIN Sebastien RD-CORE-ISS" <[e-mail]>]

Hi,

In the PSTN world we have two separate things:

- a calling party category.  The network behavior associated to those categories is left for each operator to decide.
- an indication generated by the network that a call has calling party identity presentation restricted by the network.

These requirements have nothing to do with each other (the value "police" or "authority" does not exist in the calling party category value). 

This requirement is of "legacy" type hence PSTN interoperability should be a goal, and we should not try and re-invent it. 
All we need is a "network restricted" indication.

Regards
sebastien 




-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Paul Kyzivat
Envoyé : mardi 30 août 2005 00:18
À : Jesske, R
Cc : [e-mail]; [e-mail]
Objet : Re: [Sipping-tispan] ACR Requirements



Jesske, R wrote:
> Dear all,
> After several discussions I had the last days regarding the ACR 
> requirements I would like to propose the following:
> 
> 1. To define a requirement that marks a communication where the ID is 
> network restricted. The rest with regard to ACR is the definition how 
> the service will use such a network restricted information.
> 
> E.G
> [ACR-2] To avoid that the ACR rejects communications that have no 
> originating Identity due to the fact that this was restricted by the 
> network and not by a privacy service initiated or initiated on behalf 
> by the originator of the communication a indication is needed to mark 
> that communication as a network restricted communication.

I think I understand what you mean. But I am a little troubled by the term "restricted" for this. I suppose it is enshrined by prior use, but it seems to convey the wrong implications to me. It implies that the may still be known to the network, but withheld at the whim of the network rather than at the whim of the user, and that somehow that is ok.

It would be more comforting to me if you were to use the term "unknown" 
rather than "restricted".

> 2. To delete the by-pass requirement for authorities.
> 
> Due to the bypass of ACR several issues were discussed. Fact is it is 
> not clear if this is required by regulation or not.

That would certainly simplify things.

> It was mentioned
> that a originating identification is needed. Due to the fact that 
> there is an other requirement ([REQ-CAT-1] For service applicability 
> to special groups and interoperability with the PSTN/ISDN an 
> indication of the originating party category is needed. This is needed 
> due to the fact that some services apply a special behaviour to 
> special user groups (e.g., like Pay-Phones). And [REQ-CAT-2] The 
> originating party category referred to in REQ-CAT-1 must be inserted 
> by a trusted entity. )

At least this would move some of the discussion to another topic, though it probably won't make it go away.

> it is
> proposed to use this functionality then if a bypass is needed. This 
> requirement is independent from the ACR bypass, because a originating 
> user indication (Calling Party's Category) is needed anyway.

But this would then become just another requirement imposed on ACR would it not? Using REQ-CAT-1 and REQ-CAT-2 will perhaps factor out the determination of category, but the bypass of ACR based on category remains. In fact it then becomes an issue to specify exactly which of the categories are eligible to bypass ACR. (police:yes, fire:maybe, pay-phone:no, prison:certainly.) That decision could be defined for each service, or it could be a user option. (But somehow I doubt tispan would let this be a user option.)

	Paul

> I hope we can go such a way and solve  the network restricted problem.
> 
> Best Regards
> 
> Roland
> 
> 
> 
> Deutsche Telekom AG
> T-Com Zentrale
> Roland Jesske, TE332-2
> Section TE33; Signalling, Gateways and Switching Systems Am 
> Kavalleriesand 3, 64295 Darmstadt, Germany
> Phone:  [phone]
> Fax:      [phone]
> email:  _____ [e-mail]_
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> 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