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

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

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