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
- RE: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Michael Hammer (mhammer)
- Re: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Miguel Garcia
- RE: AW: AW: AW: [Sipping-tispan] TISPAN requireme… GARCIN Sebastien RD-CORE-ISS
- RE: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Michael Hammer (mhammer)
- Re: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Miguel Garcia
- Re: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Tom-PT Taylor
- Re: AW: AW: AW: [Sipping-tispan] TISPAN requireme… Miguel Garcia