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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 Aug 2005 09:33:22 -0400

Christian,

Concerning the "priority" of CCBS users.  Given that in SIP it could be possible that multiple calls can be presented to the user at the same time, I do not think that the caller's service should over-ride the called party's prerogative to choose which call to answer.  I believe that should be an acceptable variation.  Otherwise, the user will answer/put on hold/hangup, not the best experience for the caller.

It might also be possible to give any other calls in the same time frame busy call treatment, but I think that would be a step backwards (constraining to the limitations of the PSTN) for SIP users.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Schmidt, Christian
> Sent: Wednesday, August 24, 2005 6:54 AM
> To: Miguel Garcia
> Cc: [email-masked]; Alexeitsev, D
> Subject: AW: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> Hi Miguel,
> 
> some more comments inline.
> 
> Best Regards,
> Christian Schmidt
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Miguel Garcia [mailto:[email-masked]]
> Gesendet: Mittwoch, 24. August 2005 12:02
> An: Schmidt, Christian
> Cc: [email-masked]; Alexeitsev, D; [email-masked]
> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 
> Hi Christian:
> 
> Thansk for reading this document. Inline comments.
> 
> Schmidt, Christian wrote:
> 
> > Some comments:
> > 
> > 2. Overview
> > "small variations are expected when compared with the 
> equivalent ISTD/PSTN supplementary services"
> > Can you provide an example for such a variation?
> 
> I'll give you one example that came to my mind. Many of the 
> supplementary services in PSTN/ISDN assume that there is only one 
> line/terminal per user, so if the user is already busy from that 
> terminal/line, he won't be able to take a new call, thus, 
> services such 
> as Call Forwarding on Busy will apply.
> 
> This is not exactly the same in SIP, where a user can be 
> using several 
> terminal simultaneously, and there isn't a concept of a "line" or 
> "channel". Therefore, the fact that a user is busy from one terminal 
> does not necessarily imply anything with respect his busy condition. 
> This is a change with respect the PSTN/ISDN services.
> 
> Christian: This information should be added somehow, perhaps:
> "small variations are expected in some services (for example 
> CCBS, because of different busy definitions) are expected.....".
> 
> > 
> > 3.1 General Requirements
> > "the user should receive the service without any degradation"
> > This seems to be somehow in contradiction with the 
> "variation" passage in the overview section. Or do you mean 
> variation as addon only?
> 
> The requirement means that, if one user is in the NGN and the 
> other in 
> the PSTN, the NGN user should not receive a degradation with 
> respect the 
> NGN simulation service (read the "native network" in the text). 
> Similarly, the PSTN user should not receive a degradation 
> with respect 
> the PSTN/ISDN supplementary service provided in the PSTN.
> 
> I think this isn't in contradiction with the "variation" passage.
> 
> Christian: OK, now I understand. But I am still a little 
> concerned about the requirement. For example in case of CCBS. 
> When the called PSTN subscriber get free, the CCBS call will 
> be presented to the called subscriber with priority, to avoid 
> other terminating calls to come first. How do you want to 
> achieve this with SIP? Without this feature, this is a kind 
> of service degradation for CCBS. Perhaps, you should modify 
> to "without significant degradation".
> 
> 
> > There should also be a general requirement included:
> > GEN-3: "SIP UA not providing this simulation service should 
> not be influenced, they are simple not able to provide the 
> related service."
> 
> I agree with the idea, but I don't think it is a requirement, but a 
> property or expectation of the system. But I can add some 
> clarification 
> text indicating that we don't expect SIP UAs that do not 
> implement the 
> services to provide the service to the user.
> 
> Christian: It is a requirement for the selection of a proper 
> solution. Do not select a solution which is not backwards 
> compatible. And the statement
> should avoid discussions, that with introduction of this 
> services, all SIP UAs would have to be changed.
> 
> Best Regards
> Christian Schmidt
> 
> 
> _______________________________________________
> 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: Elwell John <[email-masked]>
Date: Thu, 25 Aug 2005 11:51:33 +0100

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

> From: Jesske, R [mailto:[email-masked]] 
> Sent: 25 August 2005 09:52
> To: [email-masked]
> Paul,
> I hope we do understand in future. Next Try. See below.
> 
> 
> 
> > Von: Paul Kyzivat [mailto:[email-masked]] 
> > Gesendet: Donnerstag, 25. August 2005 05:31
> > An: Jesske, Roland
> > Cc: [email-masked]; [email-masked]; 
> > Alexeitsev, Denis
> > 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
> > > 
> > > 
> > >>Von: [email-masked] 
> > >>[mailto:[email-masked]] Im Auftrag von 
> Paul Kyzivat
> > >>Gesendet: Mittwoch, 24. August 2005 05:07
> > >>An: Miguel Garcia
> > >>Cc: [email-masked]; 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
> >

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 25 Aug 2005 12:58:52 +0200

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.

Best Regards

Roland

> Von: Elwell John [mailto:[email-masked]] 
> Gesendet: Donnerstag, 25. August 2005 12:52
> An: Jesske, Roland; [email-masked]
> Betreff: RE: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 
> Roland,
>

---

From: Elwell John <[email-masked]>
Date: Thu, 25 Aug 2005 12:10:01 +0100

Roland,

See below.

John

> Sent: 25 August 2005 11:59
> To: Elwell John; [email-masked]
> 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.
> 
[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?

---

From: "Jesske, R" <[email-masked]>
Date: Thu, 25 Aug 2005 13:16:22 +0200

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 

> Gesendet: Donnerstag, 25. August 2005 13:10

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 25 Aug 2005 13:26:46 +0200

Hello John

The reality is that our subscribers currently use something about 20 different UASs - Hard/Soft Phones, IADs, etc and non of them support anonymous call rejection right now. 

If we want to provide the ACR service in UAS we would have to make 20 change requests to 15 vendors, where we do not even have business relationship with most of them.

So even in the long term providing this ubiquitous service in the network is the only feasible solution to us, our subscribers and our regulator.

That is the practical reasoning. 

Greetings,
Denis Alexeitsev
Deutsche Telekom AG
T-Com Zentrale, TE332-5
Signalling, Gateways and Switching Systems
Am Kavalleriesand 3, D-64307,
Darmstadt, Germany 
Tel:  +49 6151 83-2130
Fax: +49 6151 83-4577
mailto:[email-masked]

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Thu, 25 Aug 2005 13:40:39 +0200

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 : [email-masked] [mailto:[email-masked]] De la part de Jesske, R
Envoyé : jeudi 25 août 2005 13:16
À : [email-masked]; [email-masked]
Cc : [email-masked]; Alexeitsev, D
Objet : AW: AW: [Sipping-tispan] TISPAN requirements, first requiements

John,

Roland 

> > 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.
> > 
> [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
> > 
> > 
> > 
> > > 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
> > > 
> > > > > 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.
> > > > element must include on behalf of the user this element so that 
> > > > a Police-call is really a police call.
> > > > A indication is added indicating that this communication comes 
> > > > from a official authority (Police)
> > > > From: Anonymous
> > > > 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
> > > > > known that there is any service to authorize. At that point, 
> > > > > the
> > > P-Asserted-ID
> > > > > 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
> > > > 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.
> > > > 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.
> > > > 
> > > > > 
> > > > > every call with an indication that the caller is permitted to 
> > > > > override ACR?
> > > > 
> > > > Yes.
> > > > 
> > > > >Or with
> > > > restricted" (as it is in the PSTN/ISDN) to express that the Id 
> > > > is missing because of some network restrictions (like 
> > > > privacy. So we looked fore some other possibility. That is what 
> > > > I have showed you above.
> > > >

---

From: "Jitender Arora" <[email-masked]>
Date: Thu, 25 Aug 2005 18:19:12 -0500

I am slightly confused here , Are we proposing the solution for this problem?

or Are we just trying to capture the requirements?

Because as people have pointed out that we already have the RFC3323/3325/ which talk about the privacy and how we can provide the privacy at the user/network level.

Rgds,
Jitender
----- Original Message -----
From: "Miguel Garcia" <[email-masked]>
To: "Tom-PT Taylor" <[email-masked]>
Subject: Re: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements
Date: Thu, 25 Aug 2005 16:41:02 +0300

> 
> So what is an anonymous user? An anonymous user is one for which 
> his identity is not determined. The reason why a user is anonymous 
> is another story (the user want, or the network can't provide an 
> identity), but they are anonymous in both cases.
> 
> /Miguel
> 
> Tom-PT Taylor wrote:
> 
> > I think your requirement is not quite accurate even at this level 
> > of abstraction.  Roland has identified two different cases.  One 
> > is your "certain anonymous users", but the other is the case 
> > where the user identity is unable due to the network's inability 
> > to provide it.
> >
> > I guess I can see your point about pushing too hastily to 
> > mechanism. Roland actually identified the information that might 
> > be used to resolve the issue at the rejection point: on the one 
> > hand, the identity of the caller if present in a P-A-Id, and on 
> > the other hand, the absence of a P-A-Id.  It may be that this is 
> > all that is needed, and no further discussion is required in 
> > SIPPING.  (Of course, that's assuming that the number of 
> > authorized caller identities any one rejection point has to keep 
> > track of is limited and provisionable.)
> >
> > Miguel Garcia wrote:
> >
> >> Tom:
> >>
> >> I agree with you in the essence, but you are referring to a 
> >> solution, not to a requirement. Essentially, whenever you need 
> >> to speak about an "indicator", it raises an alarm in my head 
> >> that you are speaking about a possible solution rather than a 
> >> requirement.
> >>
> >> So the requirement is tha there are certain anonymous users that 
> >> are not subject to be filtered by ACR. Then we can further 
> >> discuss the solution, which is probably going in the direction 
> >> you suggest.
> >>
> >> /Miguel
> >>
> >> Tom-PT Taylor wrote:
> >>
> >>> Let's just summarize the requirement.  You've tied it to other 
> >>> mechanism below.  I think it will be less confusing to abstract 
> >>> out the actual information that is needed.
> >>>
> >>> So: the requirement is that it be possible to include in SIP 
> >>> signalling an indicator that network-provided Anonymous Call 
> >>> Rejection should be overridden.  This is needed in two 
> >>> circumstances: when the caller identity is unavailable in the 
> >>> first place, and when Privacy is invoked.  There is an obvious 
> >>> ancillary requirement that this indicator be acted on only if 
> >>> it comes from a trusted source.
> >>>
> >>> Jesske, R wrote:
> >>>
> >>>> Paul,
> >>>>> Von: Paul Kyzivat [mailto:[email-masked]] Gesendet: 
> >>>>> Donnerstag, 25. August 2005 05:31
> >>>>> An: Jesske, Roland
> >>>>> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first requiements
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Jesske, R wrote:
> >>>>>
> >>>>>> Paul,
> >>>>> included by a network entity like it is done for the P-Asserted-Identiy.
> >>>>>
> >>>>    ------------->  ----------->   ----------->    F1:INVITE    
> >>>>      F2:INVITE     F3:INVITE
> >>>>
> >>>>
> >>>> F1: INVITE
> >>>> No indications From: Anonymous
> >>>>
> >>>> F2: INVITE
> >>>>    ------------->  ----------->   ----------->    F1:IAM       
> >>>>     F2:INVITE     F3:INVITE
> >>>>
> >>>> F1: IAM:
> >>>>    ------------->  ----------->      F1:INVITE         
> >>>> F2:INVITE   F1: INVITE
> >>>> No indications From: Anonymous
> >>>> No P-Asserted-Identity
> >>>>
> >>>> F2: INVITE
> >>>>> 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 
> >>>>> 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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> 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?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> So you are looking for some kind of enhancement to Privacy, 
> >>>>> that indicates *why* privacy is requested?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>>> Betreff: Re: [Sipping-tispan] TISPAN requirements, first requiements
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Miguel Garcia wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Folks:
> >>>>>>>>
> >>>>>> The document is fairly short at the moment. Please post your 
> >>>>>> comments here.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Regarding REQ-ACR-2:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>             subject to the ACR service, thus, allowing the callee to
> >>>>>>             receive anonymous requests from authorized callers.  This
> >>>>>>             service depending on the identity and authorization of the
> >>>>>>             caller.  This is needed, e.g., when a police officer or
> >>>>> 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?
> >>>>>
> >>>>> authorization on one side to be conveyed to the other side 
> >>>>> and then trusted their?
> >>>>>
> >>>>>     Thanks,
> >>>>>     Paul
> >>>>>
> -- Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 

-- 

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

---

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Mon, 29 Aug 2005 10:37:50 +0200

Hi, 

Yes, the call indeed does need to stay anonymous for the SIP end point. 

Also I think we shouldn' make too many assumption of which entity will be involved (proxy UAS, UAC...). This requirement is for one SIP entity to notify another SIP entity of that the call is anonymous and has an "ACR override" property.

The solution that Miguel described (adding a parameter to P-A-ID) is fine with me. 

Regards,
sebastien   

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Miguel Garcia
Envoyé : lundi 29 août 2005 08:50
À : Michael Hammer (mhammer)
Cc : [email-masked]; Alexeitsev, D
Objet : Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements,first requiements

But this solution of adding a parameter to the P-Asserted-Identity works. IMS supports from day one RFC 3325, so there are procedures to add/delete the P-Asserted-Identity when traversing a trust domain.

Now, if you add a parameter to that header field, proxies that do not support the extension will not act upon it, so they will forward it if present and if the P-Asserted-Identity header fiedl has to be forwarded. 
If the header field is stripped, it will include the parameter, which is, in my opinion, the correct behaviour.

/Miguel

Michael Hammer (mhammer) wrote:

> My concern over what gets put into the message, is that those 
> indicators could potentially be leaked to the UAS because some 
> intermediate node was not updated with the latest RFC, and according 
> to SIP merely passed on what it did not understand.
> 
> Mike
>  
> 
> 
>>[mailto:[email-masked]] On Behalf Of Miguel Garcia
>>Sent: Friday, August 26, 2005 7:44 AM
>>To: Jesske, R
>>Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first 
>>requiements
>>
>>Hi Roland:
>>
>>If you don't have a P-Asserted-Identity in the signalling, is because 
>>the trust relationship has been broken at some point, in which case, 
>>you shouldn't trust also the role parameter independently of the 
>>header where you put it.
>>
>>The nice property of adding a role parameter to the 
>>P-Asserted-Identity header is that you get the trust for free, which 
>>is the expected behaviour for this service.
>>
>>/Miguel
>>
>>Jesske, R wrote:
>>
>>
>>>>>I think it might be worth considering adding role parameters to 
>>>>>P-Asserted-ID.
>>>>
>>>>That is OK with me and solves most of the problems.
>>>>
>>>
>>>
>>>
>>>Paul,
>>>I have to revice my proposal. 
>>>I thought that is the solution to bind it to the
>>
>>P-Asserted-Id. But in the case were we have a anonymous communication 
>>restricted by the network. We usually have no Calling Party number. 
>>And therefore also no P-Asserted-Identity.
>>
>>>So we cannot bind this to the P-Asserted-Identity.
>>>
>>>Perhaps we can bind it to the privacy header?
>>>
>>>Or any other?
>>>
>>>Best Regards.
>>>
>>>Roalnd
>>>
>>Miguel A. Garcia           tel:+358-50-4804586

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland