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

"Tom-PT Taylor" <taylor@nortel.com> Mon, 29 August 2005 20:15 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9q24-0002wK-RT; Mon, 29 Aug 2005 16:15:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9q23-0002vV-33 for sipping-tispan@megatron.ietf.org; Mon, 29 Aug 2005 16:15:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03964 for <sipping-tispan@ietf.org>; Mon, 29 Aug 2005 16:15:01 -0400 (EDT)
Received: from zctfs063.nortelnetworks.com ([47.164.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9q3Q-0003w7-V0 for sipping-tispan@ietf.org; Mon, 29 Aug 2005 16:16:30 -0400
Received: from zctfhxm0.corp.nortel.com (zctfhxm0.corp.nortel.com [47.164.129.155]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7TKEGA03542; Mon, 29 Aug 2005 22:14:16 +0200 (MEST)
Received: from zcarhxp0.corp.nortel.com ([47.129.230.91]) by zctfhxm0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 22:14:16 +0200
Received: from [127.0.0.1] ([47.130.16.2] RDNS failed) by zcarhxp0.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 16:14:14 -0400
Message-ID: <43136C90.10801@nortel.com>
Date: Mon, 29 Aug 2005 16:14:08 -0400
From: "Tom-PT Taylor" <taylor@nortel.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>
Subject: Re: AW: AW: AW: [Sipping-tispan] TISPAN requirements, first requiements
References: <072C5B76F7CEAB488172C6F64B30B5E382D98D@xmb-rtp-20b.amer.cisco.com> <43135A54.4090400@nokia.com>
In-Reply-To: <43135A54.4090400@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 29 Aug 2005 20:14:14.0420 (UTC) FILETIME=[39E4C540:01C5ACD6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Below.

Miguel Garcia wrote:
> Hi Michael:
> 
> Inline answers.
> 
> Michael Hammer (mhammer) wrote:
> 
>> Miguel,
>>
>> Does it matter that an "anonymous" call is showing up at the phone?  How
>> long do you think before the recipient figures out that only an
>> "authority" could force such calls to him despite anonymous call
>> blocking?
>>
> 
> As I understand the regulatory service, it does not matter if 
> "anonymous" is shown at the phone.
> 
> I agree that it can be easily derived, but the service does not intend 
> to address this issue.
> 
> This is the same situation we have today when someone calls me 
> anonymous. Actually, there is only one person who typically calls me 
> anonymously, so when he calls, I always answer the phone with "Hello 
> Jim" (Jim is not actually his name). But you get the idea, right?
> 
> 
>> That lead me to wonder whether the call had to assert a bogus calling
>> party number?  And if so, wouldn't it be better to assert an identity
>> controlled from the original domain of the call?  And if so, why even
>> bother follow-on networks with additional work to do to manipulate
>> headers for override, when the originating network could construct a
>> perfectly "non-anonymous" call?  Seems like this could be simpler.
> 
> 
> Well, I am not sure if that will work at all. Essentially this requires 
> to allocate a bunch of bogus identities to those authorities that can 
> bypass ACR. Anonymity will be achieved by having a large number of bogus 
> identities, and having the UAC software able to change the identity on 
> every call to the same callee (otherwise, the callee will know who is 
> ringing the second time).
> 
> Still it won't solve the issue of what happens if that authority selects 
> the "anonymity" button in his UAC, and does an anonymous call? If you 
> read the european privacy act (referred to in this list a few days ago), 
>  the call will not go through if the calle has ACR activated, and most 
> likely, the operatore will be responsible for it. Perhaps something that 
> we shouldn't be taking a risk on.
>
[PTT] I still don't understand.  Why would a bunch of bogus identities 
have to be allocated?  Why can't the common identity: "Official" be 
used, for instance?

...


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan