AW: [Sipping-tispan] ACR Requirements

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

Sebastien,
We are on the track now (hopefully).
The only thing at the moment is the definition of the requirement.

Two definitions are in the air:

1. From Erik

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

2. Two other one from Paul

A) the originating network makes the determination about which calls
    are to bypass ACR if it is present, and delivers the decision
    to the terminating network in some way. The terminating network
    (the ACR function) simply acts on this determination
    unconditionally.

B) the originating network categorizes each call, using categories
    known to both the originating and terminating network. The
    terminating network (the ACR function) determines which calls
    are to bypass ACR, using the categorization and/or some other
    way at its discretion.

I'm happy with the definition from Erik. I don't know if Paul too.

Best Regards

Roland



> -----Ursprüngliche Nachricht-----
> Von: GARCIN Sebastien RD-CORE-ISS 
> [mailto:[e-mail]] 
> Gesendet: Dienstag, 30. August 2005 10:39
> An: [e-mail]
> Betreff: Re: [Sipping-tispan] ACR Requirements
> 
> 
> 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
> 
> -------------------------------------------------------------------
> 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