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

[Miguel Garcia <[e-mail]>]

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.



> 
> Perhaps, I didn't understand the fundamental purpose here.

I am sure you did. Thanks for your comments.

/Miguel


> 
> Mike
> 
> 
>>-----Original Message-----
>>From: Miguel Garcia [mailto:[e-mail]] 
>>Sent: Monday, August 29, 2005 2:50 AM
>>To: Michael Hammer (mhammer)
>>Cc: Jesske, R; [e-mail]; Alexeitsev, D
>>Subject: 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
>>> 
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail] 
>>>>[mailto:[e-mail]] On Behalf Of Miguel Garcia
>>>>Sent: Friday, August 26, 2005 7:44 AM
>>>>To: Jesske, R
>>>>Cc: [e-mail]; Alexeitsev, D
>>>>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
>>>>>
>>>>>_______________________________________________
>>>>>Sipping-tispan mailing list
>>>>>[e-mail]
>>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>>
>>>>-- 
>>>>Miguel A. Garcia           tel:[phone]
>>>>sip:[e-mail]
>>>>Nokia Research Center      Helsinki, Finland
>>>>
>>>>
>>>>_______________________________________________
>>>>Sipping-tispan mailing list
>>>>[e-mail]
>>>>https://www1.ietf.org/mailman/listinfo/sipping-tispan
>>>
>>>
>>-- 
>>Miguel A. Garcia           tel:[phone]
>>sip:[e-mail]
>>Nokia Research Center      Helsinki, Finland
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-tispan