Subject: AW: [Sipping] Re: Question on draft-rosenberg-sipping-acr-code-00

From: "Jesske, R" <[email-masked]>
Date: Thu, 12 Jan 2006 13:50:59 +0100

That what we specified within ETSI is based on the PAI and the privacy header. When the user expresses his wish to anonymise it's public ID the ACR service will be invoked.
With regard to the from header there is no triggering for the ACR service.

That is the same behaviour as for the equivalent PSTN/ISDN service and the regarding requirements from regulation.

It is not the requirement to block calls where a PAI is absent due to network reasons like interworking with analogue networks.

The idea of an other response code for an untrusted identity could be the basis for a new service that is not defined yet. But thinkable.

Best Regards

Roland
> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Donnerstag, 12. Januar 2006 08:49
> An: Paul Kyzivat; Jonathan Rosenberg
> Cc: sipping
> Betreff: RE: [Sipping] Re: Question on 
> draft-rosenberg-sipping-acr-code-00
> 
> 
> The point that Paul makes about putting a fictitious or 
> meaningless caller
> ID in the From header was what I had in mind when I asked my original
> question. If I get an ACR response I just substitute a caller 
> ID at will,
> and if this gets through my own domain then it will also 
> avoid ACR. Without
> PAI, Identity or AIB, the called domain or UAS has no way of 
> detecting this.
> 
> John
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[email-masked]] 
> > Sent: 11 January 2006 22:45
> > To: Jonathan Rosenberg
> > Cc: Elwell, John; sipping
> > Subject: Re: [Sipping] Re: Question on 
> > draft-rosenberg-sipping-acr-code-00
> > 
> > 
> > 
> > Jonathan Rosenberg wrote:
> > > This is an old mail, my apologies for the really long time 
> > to respond. 
> > > This draft has started to get some attention again recently.
> > > 
> > > John raises an interesting point. This basic question has 
> > been discussed 
> > > almost endlessly in the SIMPLE/GEOPRIV groups as well. The 
> > issue there 
> > > was that the common policy/presence policy specs have had 
> > fields that 
> > > define an "anonymous" condition, and we've debated whether 
> > > unauthenticated counts as anonymous.
> > > 
> > > Unfortunately this never really concluded; we just got rid of the 
> > > anonymous condition :(
> > > 
> > > In this particular case, I don't think it helps to count 
> > unauthenticated 
> > > as anonymous. The reason is, the whole point of the 
> > resposne code is 
> > > that the caller can do something different in an attemtp to 
> > get the call 
> > > through. In this case, the caller has not actually TRIED to be 
> > > anonymous; its just that their service provider didn't do PAID or 
> > > sip-identity. So, if the call is rejected as anonymous, the 
> > caller will 
> > > be surprised, since it wasn't anonymous as far as they were 
> > concerned, 
> > > and there is nothing they can do about it to make it not 
> anonymous.
> > 
> > The problem is that there is no good way to tell the 
> > difference between 
> > blocked and unavailable. When using Privacy, the Privacy header is 
> > removed before the request gets to the UAS.
> > 
> > While responding to this I noticed something missing from 
> > draft-rosenberg-sipping-acr-code-00: it does not specify 
> > proxy behavior. 
> > This is significant because it is possible for the ACR 
> feature to be 
> > carried out by a proxy acting on behalf of the callee.
> > 
> > If that is happening, and the proxy is in the same trust 
> > domain with the 
> > caller, then the situation is a *little* different, because 
> > it can see 
> > the Privacy header. So some blocked cases are distinguishable from 
> > unavailable cases. But that is still only a limited set, 
> because the 
> > caller could be in a different trust domain. So again, it becomes 
> > necessary to fall back to reading the tea leaves to decide between 
> > blocked and unavailable. (Looking for Anonymous in the From header.)
> > 
> > Note that looking at From isn't reliable either. If I don't 
> > want to be 
> > blocked by ACR, I can just set my Privacy:id and set my From to 
> > something like: From: nobody <sip:[email-masked]>. Then the 
> > callee will treat me as having an unavailable address and let 
> > the call 
> > through.
> > 
> > I think the fundamental problem here is that distinguishing between 
> > unavailable and blocked can only work when all callers and 
> > callees are 
> > linked to a single trust domain.
> > 
> > 	Paul
> > 
> > 
> > > So, I'd suggest that we not include unauthenticated in the 
> > list of cases.
> > > 
> > > -Jonathan R.
> > > 
> > > Elwell, John wrote:
> > > 
> > >> What if a UAS receives a request containing an unauthenticated 
> > >> identity in the From header? If the UAS or user is not 
> prepared to 
> > >> trust the unauthenticated identity, the source of the request is 
> > >> basically anonymous. Is the new response code intended for 
> > use in this 
> > >> situation?
> > >>
> > >> John
> > >>
> > >>
> > >>
> > > 
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jan 2006 12:51:00 -0500

Jesske,

ACR is an impediment to some whose goal is to call you without their 
identity being divulged. Some of those (e.g. telemarketers) have a 
strong incentive to get around the ACR.

If they can get around it be calling from a different network, then that 
is what they will do. So while what you describe may be consistent with 
the requirements you have adopted, it may not be considered sufficient 
by users.

OTOH, I don't think this is a solvable problem with the current 
communications infrastructure. The concept of an ACR feature that can 
distinguish between blocked and unavailable may just be fatally flawed.

	Paul