Subject: AW: [Sipping-tispan] ACR Requirements

From: "Jesske, R" <[email-masked]>
Date: Tue, 30 Aug 2005 09:54:32 +0200

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:[email-masked]] 
> Gesendet: Dienstag, 30. August 2005 00:18
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]
> 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:  +49 6151 83-5940
> > Fax:      +49 6151 83-4577
> > email:  _____ [email-masked]
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > Sipping-tispan mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sipping-tispan
> 

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

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Tue, 30 Aug 2005 10:24:02 +0200

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:[email-masked]]
Sent: Tuesday, August 30, 2005 9:55 AM
To: [email-masked]
Subject: AW: [Sipping-tispan] ACR Requirements

Proposal:

Is this acceptable?

More comments inline

Roland

> > email:  _____ [email-masked]

-------------------------------------------------------------------
Mail archive for TISPAN_WG3  can be browsed at the following url :
         http://list.etsi.org/TISPAN_WG3.html
-------------------------------------------------------------------

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 30 Aug 2005 10:26:50 +0200

Erik,
This definition is also OK for me.

Roland

> Von: Hans Erik van Elburg (RY/ETM) 
> [mailto:[email-masked]] 
> Gesendet: Dienstag, 30. August 2005 10:24
> An: Jesske, Roland; [email-masked]; [email-masked]
> 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
> 
> originating Identity is unknown due to missing network 
> capabilities providing a asserted identity  
> to mark that this communication has no asserted identity 
> included because of restricted network capabilities.
> 
> Is this acceptable?
> 
> More comments inline
> 
> 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 
> 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
> >

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Tue, 30 Aug 2005 10:39:12 +0200

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 : [email-masked] [mailto:[email-masked]] De la part de Paul Kyzivat
Envoyé : mardi 30 août 2005 00:18
À : Jesske, R
Cc : [email-masked]; [email-masked]
Objet : Re: [Sipping-tispan] ACR Requirements

Jesske, R wrote:
> 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 
> 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".

> Due to the bypass of ACR several issues were discussed. Fact is it is 

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

> requirement is independent from the ACR bypass, because a originating 

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:  +49 6151 83-5940
> Fax:      +49 6151 83-4577
> ----------------------------------------------------------------------
> --
>

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 30 Aug 2005 10:59:12 +0200

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

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

> Von: GARCIN Sebastien RD-CORE-ISS 
> [mailto:[email-masked]] 
> Gesendet: Dienstag, 30. August 2005 10:39
> An: [email-masked]
> - 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. 
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Paul Kyzivat
> on behalf 
> 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.
> 
> topic, though it probably won't make it go away.
> 
> > it is
> 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, 
> defined for each service, or it could be a user option. (But 
> somehow I doubt tispan would let this be a user option.)
> 
> 	Paul
>