Subject: RE: [Sipping] calling number blocking at sip/isup gateway

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 27 Jan 2002 15:54:35 -0600

What a long thread.

The SIP-ISUP mapping draft suggests that if a telephone number is not
available in the From field of an INVITE received by a gateway (either
because the address in the From field is a SIP URI without telephone number
syntax, or if some sort of 'Anonymous' value is present for privacy
reasons), then the Calling Party Number (CgPN) parameter in ISUP should be
excluded when a corresponding IAM is sent to the PSTN. This mapping is
recommended because the CgPN parameter is not a mandatory parameter in the
IAM. Similarly, an originating telephone number is not required to construct
a SIP message.

As Juha points out later in this thread, many nationalities require the
presence of the CgPN parameter in IAMs. In the USA, for example, the CgPN
must be sent over certain types of trunks - though not all, as it happens.
Important exceptions are made in the USA (and elsewhere, I'm sure) for cases
in which ISUP is interworking with another protocol (like old-school MF
signaling). International calls routinely do not provide any information
about the caller. Similar exceptions apply to certain PBXs that do not
possess detailed information about the originator of a call (this is
directly analogous to Dean's SIP gateway). In short, anyone reading this
thread who believes that an ISUP network is going to break if you send an
IAM without a CgPN from a gateway should really talk to some operations
people at a major carrier - or look at how many times 'unavailable' shows up
on their own Caller-ID screen.

I believe that it is perfectly reasonable to look at a SIP-ISUP gateway as
another case along these lines: SIP is substantially a different protocol,
and sometimes SIP requests just don't have a Calling Party's Number -
irregardless of any privacy concerns. No generic mechanism can assume that
there is some 'correct' telephone number that must be associated with a
client. Compensating for this fact by requiring gateways to insert some
'gateway number' in the CgPN is a hack that doesn't assist procedures like
malicious call trace in any obvious way, and it is a hack that is also
forbidden by some interconnection agreements in the USA on account of its
use in grey-legal arbitrage scams. 

So in short, at a protocol level I think it is reasonable for the user's
omission of a 'telephony' identity in the From field (either because they
don't have one or for privacy reasons) to be communicated directly to the
PSTN through the omission of the CgPN. At a policy level, I think gateway
operators would be well advised to cryptographically authenticate users, and
record session parameters in order to provide sufficient data for abuse and
fraud detection. I mean, gateway operators could, if they were so inclined,
reject requests that don't have an originating 'telephony' identity, or even
a specific telephone number in the From field. However, this is quite
plainly orthogonal to the SIP-ISUP mapping process.

The mapping described in the SIP-ISUP draft is designed to work regardless
of whether the call originated at a network-controlled gateway or a
user-controlled client. Note (following Matt Holdrege) that if the session
originates in the ISUP world, then RFC3204 can be used to carry the original
CgPN information with any necessary parameters regarding presentation so
that an IAM can be appropriately constructed when a request returns to the
PSTN. If a call originates and terminates in the PSTN, then I think callers
(and network operators) will expect that the PSTN privacy features will work
- and I believe SIP-T satisfies that expectation.

As a design goal, SIP-T does not require any extensions to SIP or ISUP - it
tries to explain how you map the two protocols, not how you turn one into
the other. Initiatives other than SIP-T have attempted to demonstrate how to
make SIP, with extensions, a functional superset of the PSTN (the
sip-privacy draft clearly comes from that line of thinking). I agree with a
number of the respondents (including Christian) that this is actually very
difficult to do, and I maintain that the more modest SIP-T practice is
sufficient to interwork with the PSTN as I understand it.

Finally, the SIP-ISUP mapping draft does explicitly note that implementers
could make use of a generic SIP privacy mechanism - however, as I've argued
in the past, I'm not sure that one is currently on the table. I do agree
that there should be one.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 10:14 AM
> To: [email-masked]
> Subject: [Sipping] calling number blocking at sip/isup gateway
> 
> 
> i didn't find from draft-ietf-sipping-isup-00.txt, how should sip
> originated invite look like in order to prevent the called pstn party
> from seeing the calling sip party's number in the from field of the
> invite.
> 
> can a proxy add something to the invite on behalf of the calling sip
> user in order to get the calling number blocked by the sip/isup gw?
> 
> -- juha
> 
> 
> _______________________________________________
> 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: Flemming Andreasen <[email-masked]>
Date: Mon, 28 Jan 2002 19:25:55 -0500

"Peterson, Jon" wrote:

> the other.

This is well understood, however it does not mean that SIP contains all
the
desired functionality for a communications service (of which telephony
as we
know it is admittedly one example).

> Initiatives other than SIP-T have attempted to demonstrate how to
> sip-privacy draft clearly comes from that line of thinking).

Not quite. While it is true that the original motivation for the privacy
draft
was to enable SIP to be used to provide telephony-like service, it goes
beyond
that. Network authenticated identity information can be used to drive a
number
of services, e.g. provide alternative billing information as Jonathan
pointed
out.

> I agree with a

Quite possibly true, but we are not just trying to interwork with the
PSTN.

> that there should be one.

If you could highlight the unfilfilled requirements, it would be
helpful. We can
then always debate if the current privacy draft should address those or
something else is needed.

-- Flemming

--
Flemming Andreasen
Cisco Systems