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

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

All,

As an operator, I'd like to support Roland on this particular point. Also this doesn't prevent anybody from implementing this type on feature on SIP phones.

BR,
sebastien 

-----Message d'origine-----
De : [e-mail] [mailto:[e-mail]] De la part de Jesske, R
Envoyé : jeudi 25 août 2005 13:16
À : [e-mail]; [e-mail]
Cc : [e-mail]; Alexeitsev, D
Objet : AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

John,
First it is a regulatory service that must be provided by an operator in Europe.
Second there is also a marked demand to fulfil such services (not only ACR also others) within the network.

We as want to add our networks services to satisfy our customers.

Roland 

> -----Ursprüngliche Nachricht-----
> Von: Elwell John [mailto:[e-mail]]
> Gesendet: Donnerstag, 25. August 2005 13:10
> An: Jesske, Roland; [e-mail]
> Cc: [e-mail]; Alexeitsev, Denis
> Betreff: RE: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 
> Roland,
> 
> See below.
> 
> John
>  
> 
> > -----Original Message-----
> > From: Jesske, R [mailto:[e-mail]]
> > Sent: 25 August 2005 11:59
> > To: Elwell John; [e-mail]
> > Cc: [e-mail]; Alexeitsev, D
> > Subject: AW: AW: [Sipping-tispan] TISPAN requirements, first 
> > requiements
> > 
> > John,
> > Yes of course the the UAS can do this. But this is also possible in 
> > the PSTN/ISDN world where this service is working.
> > 
> > This service with this bypass is especially working in some networks 
> > (not in Germany). In this countries it is also coming from the 
> > regulator if my knowledge is correct.
> > 
> > I can do the same manually when unknown is displayed in my
> ISDN phone.
> > 
> > But the important is that the originator (Police) has the chance to 
> > come through.
> [JRE] Without the ACR service all requests / calls will get through to 
> the UAS. The UAS will decide how to handle individual requests 
> according to setting, rules, etc. An ACR service in the network would 
> merely filter out some requests before they get to the UAS. What is 
> the benefit?
> > 
> > Best Regards
> > 
> > Roland
> > 
> > 
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Elwell John [mailto:[e-mail]]
> > > Gesendet: Donnerstag, 25. August 2005 12:52
> > > An: Jesske, Roland; [e-mail]
> > > Cc: [e-mail]; Alexeitsev, Denis
> > > Betreff: RE: AW: [Sipping-tispan] TISPAN requirements, first 
> > > requiements
> > > 
> > > 
> > > Roland,
> > > 
> > > What value is the ACR server adding that cannot be provided by the 
> > > UAS? Or put it another way, even if the ACR server allows certain 
> > > authorised callers to override ACR, an "ACR" capability at the UAS 
> > > would presumably not allow this so it would still reject all 
> > > anonymous calls. So what
> > has the ACR
> > > server achieved?
> > > 
> > > John
> > > 
> > > > -----Original Message-----
> > > > From: Jesske, R [mailto:[e-mail]]
> > > > Sent: 25 August 2005 09:52
> > > > To: [e-mail]
> > > > Cc: [e-mail]; Alexeitsev, D
> > > > Subject: AW: AW: [Sipping-tispan] TISPAN requirements, first 
> > > > requiements
> > > > 
> > > > Paul,
> > > > I hope we do understand in future. Next Try. See below.
> > > > 
> > > > 
> > > > 
> > > > > -----Ursprüngliche Nachricht-----
> > > > > Von: Paul Kyzivat [mailto:[e-mail]]
> > > > > Gesendet: Donnerstag, 25. August 2005 05:31
> > > > > An: Jesske, Roland
> > > > > Cc: [e-mail]; [e-mail]; 
> > > > > Alexeitsev, Denis
> > > > > Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first 
> > > > > requiements
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Jesske, R wrote:
> > > > > > Paul,
> > > > > > With regard to this feature it must be based on trust
> > > > > relationship as defined within RFC3325 for the
> > > P-Asserted-Identity.
> > > > > > So the indication that this is a authorised user is
> > > > > included by a network entity like it is done for the 
> > > > > P-Asserted-Identiy.
> > > > > > So the network entity knows it via a database that this
> > > > > registered user is a authorised one.
> > > > > 
> > > > > Either I don't understand you, or you don't understand me.
> > > > > 
> > > > > RFC3325 is a way for some trusted element of the network that 
> > > > > knows the source of the request to assert a trusted identity 
> > > > > for the source of the message. It doesn't provide any 
> > > > > authorization for anything.
> > > > For the Marking of a call with a bypass allowance a network 
> > > > element must include on behalf of the user this element so that 
> > > > a Police-call is really a police call.
> > > > I will try it with some flows:
> > > > 
> > > > 
> > > > Police
> > > >   UA:A        Proxy            ACR          UA:B
> > > >    ------------->  ----------->   -----------> 
> > > >    F1:INVITE         F2:INVITE     F3:INVITE
> > > > 
> > > > 
> > > > F1: INVITE
> > > > No indications
> > > > From: Anonymous
> > > > 
> > > > F2: INVITE
> > > > A indication is added indicating that this communication comes 
> > > > from a official authority (Police)
> > > > From: Anonymous
> > > > P-Asserted-Identity with privacy Id
> > > > 
> > > > 
> > > > F3: INVITE
> > > > ACR server forwards the communication due to the  bypass
> > indication
> > > > From: Anonymous
> > > > 
> > > > PSTN         PSTN/ISDN
> > > >   User A         GW           ACR          UA:B
> > > >    ------------->  ----------->   -----------> 
> > > >    F1:IAM           F2:INVITE     F3:INVITE
> > > > 
> > > > F1: IAM:
> > > > No Calling Party number is included Call is marked as restricted 
> > > > by the network
> > > > 
> > > > F2: INVITE
> > > > A indication is included that points to the fact that the call 
> > > > is Anonymous because of a network restriction
> > > >  From: Anonymous
> > > > P-Asserted-Identity absent
> > > > 
> > > > F3: INVITE
> > > > ACR server forwards the communication due to the  indication 
> > > > that the communication is anonymous because of network
> restriction
> > > > From: Anonymous
> > > > 
> > > > Untrusted    my network
> > > >  ProxyA       Proxy B            ACR          UA:B
> > > >    ------------->  ----------->   
> > > >    F1:INVITE         F2:INVITE     
> > > > 
> > > > 
> > > > F1: INVITE
> > > > No indications
> > > > From: Anonymous
> > > > No P-Asserted-Identity
> > > > 
> > > > F2: INVITE
> > > > No indication will be added because the request comes from an 
> > > > untrusted proxy
> > > > From: Anonymous
> > > > No Privacy
> > > > 
> > > > ACR rejects the communication
> > > > 
> > > > 
> > > > > 
> > > > > Ultimately, the ACR service must be implemented near and on
> > > > behalf of
> > > > > the recipient of the message. It isn't until there that it is 
> > > > > known that there is any service to authorize. At that point, 
> > > > > the
> > > P-Asserted-ID
> > > > > header may be present, but that just says who the caller
> > > > is, not what
> > > > > role the caller is playing. It seems that you want to do
> > > role based
> > > > > authorization, where the role is "entitled-to-override-ACR".
> > > > > 
> > > > > So how is this role determined? Surely the recipient can't 
> > > > > have a DB of all values of P-Asserted-ID that are authorized. 
> > > > > The alternative seems to be that the source inserts not just a 
> > > > > simple
> > > > P-Asserted-ID with a
> > > > > name, but rather also inserts some kind of role
> identification.
> > > > 
> > > > That could be the way out. That such a indication shall be bind 
> > > > to the P-Asserted identity and is included by the originating 
> > > > network-entity.
> > > > Because we bind the ACR service to the P-Asserted-Identity.
> > > > 
> > > > We reject the communication if a P-Asserted-Identity is included 
> > > > and the priv value is "Id", "user","header" and /or ""critical" 
> > > > and if the P-Asserted-Identity is absent.
> > > > 
> > > > > 
> > > > > I'm looking for more indication of what the expectations
> > > > are in this
> > > > > regard. Is it the expectation that the source will annotate 
> > > > > every call with an indication that the caller is permitted to 
> > > > > override ACR?
> > > > 
> > > > Yes.
> > > > 
> > > > >Or with
> > > > > some other more generic categorization of caller type? 
> > > > 
> > > > That could be also a possibility. For solving the police 
> > > > communications but it makes it not easy with the ISDN/PSTN 
> > > > interworking. Because if we have such a caller type (What is 
> > > > also another requirement) than we have to distinguish at the 
> > > > Interworking Unit. Because some caller types can be mapped to 
> > > > the Calling parties category and others must be mapped to the 
> > > > network restriction indication.
> > > > 
> > > > >Or what?
> > > > 
> > > > 
> > > > > 
> > > > > > With regard to the PSTN/ISDN this was solved via a
> > > > > indication that the Calling Party Number is restricted by the 
> > > > > network. The network included this indication in three cases:
> > > > > > 1. The call was originated within a network that cannot
> > > > > provide a originating number (e.G.) analogue.
> > > > > > 2. The call has no originated number due to interworking
> > > > > with international networks
> > > > > > 3. The call was send from a authorised user (e.G. police). 
> > > > > This indication was then set by the network. This feature is 
> > > > > especially used in UK.
> > > > > 
> > > > > So you are looking for some kind of enhancement to
> > Privacy, that
> > > > > indicates *why* privacy is requested?
> > > > 
> > > > >From my point of view YES.
> > > > 
> > > > First Idea was to have a privacy value that says "network 
> > > > restricted" (as it is in the PSTN/ISDN) to express that the Id 
> > > > is missing because of some network restrictions (like 
> > > > interworking, Analogue originating or such police calls).
> > > > Because to add such value to the privacy header would be easy.
> > > > But people had the opinion that this has nothing to do with 
> > > > privacy. So we looked fore some other possibility. That is what 
> > > > I have showed you above.
> > > > 
> > > > I hope that this was better that we can come together and you 
> > > > understand me.
> > > > 
> > > > Roland
> > > > 
> > > > 
> > > > > 
> > > > > 	Paul
> > > > > 
> > > > > > So with the requirement proposed by Miguel we hope to find
> > > > > a solution to cover the 3 above mentioned cases.
> > > > > > 
> > > > > > With regard to trust we want to have such a indication bind
> > > > > to a trust relationship as it is described within RFC3325.
> > > > > > So trust for interconnection to an other network is based
> > > > > on bilateral agreement.
> > > > > > 
> > > > > > 
> > > > > > Best Regards
> > > > > > 
> > > > > > Roland
> > > > > > 
> > > > > > 
> > > > > >>-----Ursprüngliche Nachricht-----
> > > > > >>Von: [e-mail] 
> > > > > >>[mailto:[e-mail]] Im Auftrag von
> > > > Paul Kyzivat
> > > > > >>Gesendet: Mittwoch, 24. August 2005 05:07
> > > > > >>An: Miguel Garcia
> > > > > >>Cc: [e-mail]; Alexeitsev, Denis
> > > > > >>Betreff: Re: [Sipping-tispan] TISPAN requirements, first
> > > > requiements
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>Miguel Garcia wrote:
> > > > > >>
> > > > > >>>Folks:
> > > > > >>>
> > > > > >>>Since we are tasked to re-draft the TISPAN requirements
> > > > > >>
> > > > > >>adding as much
> > > > > >>
> > > > > >>>clarifications as possible, we would like to start
> checking
> > > > > >>
> > > > > >>with you if
> > > > > >>
> > > > > >>>the requirements related to the Annonymous Communication
> > > > > >>
> > > > > >>Rejection (ACR)
> > > > > >>
> > > > > >>>service is OK and understandable by everyone.
> > > > > >>>
> > > > > >>>So please take a look at the first version of the (much
> > > > > >>
> > > > > >>incomplete and
> > > > > >>
> > > > > >>>short) draft in either text or HTML:
> > > > > >>>
> > > > > >>>
> > > > > >>
> > > > > 
> >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sippin
> > > > > > 
> > > > > > g-tispan-requirements-02a.txt
> > > > > > 
> > > > > >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
> > > > ing-tispan-requirements-02a.html
> > > > >>
> > > > >>
> > > > >>The document is fairly short at the moment. Please post
> > > > your comments here.
> > > > > 
> > > > > 
> > > > > Regarding REQ-ACR-2:
> > > > > 
> > > > > 
> > > > >>   REQ-ACR-2: It must be possible that authorized
> > callers are not
> > > > >>              subject to the ACR service, thus, allowing
> > > > the callee to
> > > > >>              receive anonymous requests from authorized
> > > > callers.  This
> > > > >>              effectively requires a mechanism to
> > override the ACR
> > > > >>              service depending on the identity and
> > > > authorization of the
> > > > >>              caller.  This is needed, e.g., when a police
> > > > officer or
> > > > >>              any other authority is anonymously
> > calling to a user
> > > > >>              having the ACR simulation service activated.
> > > > > 
> > > > > 
> > > > > How is a caller authorized? Is the mechanism for
> > determining and
> > > > > conveying this authorization in scope for this service? 
> > > > There is mention
> > > > > specifically of Police Officers, among others, as being
> > > > authorized. Are
> > > > > there a list of attributes like that which must be used to
> > > > characterize
> > > > > a caller and that are used to determine the authorization?
> > > > > 
> > > > > How is this affected by peering and PSTN interconnect? Is an 
> > > > > authorization on one side to be conveyed to the other
> > > side and then
> > > > > trusted their?
> > > > > 
> > > > > 	Thanks,
> > > > > 	Paul
> > > > > 
> > > > > _______________________________________________
> > > > > 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

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