Subject: Re: [Sip] calling number blocking at sip/isup gateway

From: [email-masked]
Date: Tue, 29 Jan 2002 08:27:57 EST

In a message dated 1/27/02 4:56:48 PM Eastern Standard Time, 
[email-masked] writes:

> What a long thread.

> etc.

Jon,

Great summary of what is needed and what is not. There have been a lot of 
protocol hacks mentioned in the last week, including putting a "bogus url" in 
the From header or having the gateway replace the real calling party number 
with some "gateway number". Also there have been suggestions that, somehow, 
encryption was part of the solution for privacy of calling party ID and that 
a "coded secret and a decoder ring" could be used. But encryption would only 
address the issue of preventing someone in the middle from seeing the ID, 
which is not the issue here. In the general case, we're talking about a 
calling line ID capability for which the calling and called party have 
nothing in common, certainly not a shared secret.

I agree, there is certainly the case in which there is simply no Calling 
party number in the signaling (e.g., From=anonymous in the INVITE) when one 
element doesn't trust the next to preserve privacy. But there is the other 
case in which it trusts the next network element and includes the ID (maybe 
because the law or the network policy requires it) and it also includes an 
indicator of what privacy procedures apply. If every network portion is 
trusted, the ID can be passed to the final "switch" which then doesn't 
deliver it to the called party. So just because you get "unavailable" on your 
Caller-ID screen doesn't mean that it wasn't in the IAM, but it could. Of 
course, the problem for SIP is the possible absence of any trusted device 
that functions as the final "switch".

However, because of other security concerns, a real IP telephone service 
provider would require that it knows the identity of the calling party and 
the model for this service must be based on a presumption that the calling 
party can trust the service provider. Therefore, in this case, the From must 
contain a correct number, and the gateway may remove it (after verifying it).

The case of the calling party leaving out the From can not be used in a 
"tariffed" (if I can use that term) telephone service. While the SIP protocol 
may allow it to be left out, the service provider may require it before 
allowing call setup.

I think this whole discussion should be taken to the SIPPING list until there 
is an agreement on the functional requirements.

Mike

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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 17:08:38 +0200

mike's summary we well reflects my thinking and the reasons why i brought
this up in the first place.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 10:57:14 -0600

On Tuesday 29 January 2002 07:27 am, [email-masked] wrote:
> However, because of other security concerns, a real IP telephone
> service provider would require that it knows the identity of the
> calling party and the model for this service must be based on a
> presumption that the calling party can trust the service provider.
> Therefore, in this case, the From must contain a correct number, and
> the gateway may remove it (after verifying it).
>
> The case of the calling party leaving out the From can not be used in
> a "tariffed" (if I can use that term) telephone service. While the
> SIP protocol may allow it to be left out, the service provider may
> require it before allowing call setup.

I run a real IP telephone service. Unknown parties may place calls over 
the Internet to my subscribers. My subscribers's profiles may result in 
forwarding those calls to a PSTN gateway. PSTN charges originating from 
this operation are charged back to the subscriber (the called party), 
not the calling party with whom I have no relationship outside the SIP 
used to set up the call.

It really doesn't matter what the calling party put in their From: 
field, I still need to complete the call. Now, if they were kind enough 
to put in a phone number, I can map that into the IAM. But if they 
didn't, I just can't. Now, there's an interesting question on 
"authenticating" the phone number that they might have included., but 
that's a different problem.

Even more interesting, I'm going to include any referenceable number 
from the INVITE in the IAM, regardless of any privacy indicator 
suggested by the SIP signaling, because that referencable number would 
have been included in the SIP signal delivered to my subscriber anyhow 
(The caller DID send it to him), and my job as a gateway oeprator is to 
get as much of the SIP experience as possible into the call being 
forwarded to the PSTN.

So, here we have a real phone service which conflicts with the 
behavioral requirements suggested by mpierce's  post, as well as a 
whole can of privacy and transitive trust worms.

--
Dean