AW: [Sipping-tispan] ACR Requirements

["Jesske, R" <[e-mail]>]

Erik,
This definition is also OK for me.

Roland

> -----Ursprüngliche Nachricht-----
> Von: Hans Erik van Elburg (RY/ETM) 
> [mailto:[e-mail]] 
> Gesendet: Dienstag, 30. August 2005 10:24
> An: Jesske, Roland; [e-mail]; [e-mail]
> Betreff: RE: [Sipping-tispan] ACR Requirements
> 
> 
> I find this formulation very complicated with all these 
> negations, I think the following would be much more understandable:
> 
> [ACR-2] The originating network shall be able to indicate to 
> the terminating network side that for an anonymous call the 
> caller identity could not be presented due to originating 
> network limitations. This to allow to distinguish this case 
> from anonymous calls where the identity presentation is 
> restricted by a privacy service of the caller. This allows 
> the first category of calls to bypass the ACR service.
> 
> 
> /Hans Erik
> 
> -----Original Message-----
> From: Jesske, R [mailto:[e-mail]]
> Sent: Tuesday, August 30, 2005 9:55 AM
> To: [e-mail]
> Subject: AW: [Sipping-tispan] ACR Requirements
> 
> 
> Proposal:
> [ACR-2] To avoid that the ACR rejects communications that have no 
> originating Identity is unknown due to missing network 
> capabilities providing a asserted identity  
> and not restricted by a privacy service initiated or initiated 
> on behalf by the originator of the communication a indication 
> is needed 
> to mark that this communication has no asserted identity 
> included because of restricted network capabilities.
> 
> Is this acceptable?
> 
> More comments inline
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Paul Kyzivat [mailto:[e-mail]] 
> > Gesendet: Dienstag, 30. August 2005 00:18
> > An: Jesske, Roland
> > Cc: [e-mail]; [e-mail]
> > Betreff: 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.
> 
> I know but as I was told if such a requirement is existing 
> than it is based on national solutions and will not described 
> within the ACR service itself. Therefore from my point of 
> view the Issue is disappeared. Of course such a service could 
> be build upon such a originating category.
> 
> > 
> > > 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? 
> 
> For me it is not longer a requirement to ACR to have such a 
> bypass for police ect.
> 
> >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.)
> 
> If such a service appear then it must be controlled by the network. 
> 
> With regard to the Calling Party's category we need the 
> category for other purposes than bypassing. We need it as a 
> selection criteria for services and routing.
> 
> Roland
> 
> > 
> > 	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
> > 
> 
> -------------------------------------------------------------------
> Mail archive for TISPAN_WG3  can be browsed at the following url :
>          http://list.etsi.org/TISPAN_WG3.html
> -------------------------------------------------------------------
> 

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