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

From: "Dean Willis" <[email-masked]>
Date: Wed, 6 Feb 2002 12:11:59 -0600

I think we call that "authentication", and any UA or proxy MAY issue an
appropriate 401/407 to request authentication.

Bear in mind that there are at least four identies in every dialog:

1) The "From:' party
2) The "To:" party
3) The requesting party
4) The fiscally responsible party

Role 2 can be further subdivied into:
2a: the targeted party
2b: the responding party

in traditional telephone calls, #1, #3, and #4  are the same.

For collect calls, the caller has roles 1 and 3, and the called has roles 2
and 4.

In third-party control, you can get an even wider range of scenarios.

SIP, as we currently know it, allows declaration of roles 1 (From:), 2
(To:),  and 3 (authenticated identity). We don't have anything for role #4,
but let that be handled by applications.

There are proposed extensions to role #1 and controlling of disclosure of
the identity associated with that role (Privacy draft, which defines Remote
party ID). This draft also defines a partial solution for 2, essentially
what I called 2b. There is some discussion in 3GPP about the need to address
2a.

We may need to find a way to express transitive relationships between roles
3 and 1 -- "by Joe on behalf of Sally", but I don't believe there's been any
expression of that yet in IETF.

Some of the responses to your question are basically asking what the
mechanism for transitively expressing #3 is. Is that what you're asking? My
flip response to the question as originally worded would have been "I don't
know about the other guys, but I authenticate the requester." But I'm not
sure that's actually asnwering the question . . .

--
Dean

----- Original Message -----
From: "Tom-PT Taylor" <[email-masked]>
To: "'Michael Hammer'" <[email-masked]>
Cc: "'Juha Heinanen'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, January 29, 2002 2:43 PM
Subject: RE: [Sipping] RE: calling number blocking at sip/isup gateway

> "Subscriber" implies that the SIP user has subscribed to some service
> somewhere.  I suppose this is a reasonable assumption for SIP-ISUP
> interworking, though I could imagine scenarios where it might not apply.
> Very well, the first SIP requirement becomes:
>
> (1) SIP must provide a way for the gateway to determine the authenticated
> identity of the SIP subscriber in whose name the call is being made.
>
>
>
> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 2:09 PM
> To: Taylor, Tom-PT [CAR:B800:EXCH]
> Cc: 'Juha Heinanen'; [email-masked]'; [email-masked]
> Subject: RE: [Sipping] RE: calling number blocking at sip/isup gateway
>
>
> Tom,
>
> Given the wireless world and the possibility that there is a distinction
> between the host platform and the subscriber/user, wouldn't it be better
to
> identify the subscriber?  There is also technology that allows a user to
> log into and personalize terminals for their use.  Or in some cases, the
> user, the subscriber, and the terminal could all be different.
>
> Presumably, the SIP UA that originates the call has an identity and a
> subscription with a service provider that authorizes the call.  Could we
> focus terminology on the subscriber as that may be all that is known to
the
> network?
>
> Mike
>
>
> At 01:42 PM 1/29/2002 -0500, Tom-PT Taylor wrote:
> >Well, the overall requirement is clear, but I think it breaks down into
two
> >different sets of requirements, on SIP and on the SIP-PSTN gateway.
> >
> >For SIP:
> >
> >(1) A requirement to provide some means whereby a PSTN gateway can obtain
> >the authenticated identity of the SIP host.  I say host rather than user
> >because I can't see regulators requiring SIP to provide more than the
PSTN
> >does now.
> >
> >(2) Another requirement to provide the means whereby a PSTN gateway can
> >determine if the SIP user wishes to restrict the presentation of his/her
> SIP
> >identity.
> >
> >
> >At the gateway the requirements will be the same whether the signalling
> >protocol is SIP, H.323, or something else.
> >
> >(1) A requirement on the gateway to provide the information within the
PSTN
> >signalling which satisfies regulatory requirements.
> >
> >(2) A requirement to report the authenticated identity of the IP host in
> >specific cases e.g. for malicious call trace.
> >
> >(3) A requirement to support billing arrangements.
> >
> >(4) A requirement to extract appropriate display information and pass it
in
> >ISUP signalling if the user has not requested privacy.
> >
> >
> >
> >-----Original Message-----
> >From: Juha Heinanen [mailto:[email-masked]]
> >Sent: Tuesday, January 29, 2002 11:17 AM
> >To: Taylor, Tom-PT [CAR:B800:EXCH]
> >Cc: [email-masked]'; [email-masked]
> >Subject: [Sipping] RE: calling number blocking at sip/isup gateway
> >
> >
> >Tom-PT Taylor writes:
> >
> >  > What about UACs
> >  > which do not have telephone numbers assigned?  Will they be barred
from
> >PSTN
> >  > access, or should we mandate that the gateway assign some sort of
> number
> >  > which it alone can cross-correlate to the original user@domain if
need
> be
> >  > for malicious call trace, etc.?
> >
> >yes, either way.  in finland we are not allowed to gateway any call to
> >pstn unless it has a valid from number (either of the user or the
> >gateway) and if we place the gw's number there, we must be able to
> >answer the question, which of the gw's subscribers actually made the
> >call.  in addition, the law requires the gw to mark the presentation of
> >the from number of all calls from the subscriber as "restricted" if
> >asked so by the subscriber.
> >
> >if sip doesn't have means to implement the above, then there is no
> >gatewaying of sip calls to pstn in finland and there is no business case
> >for us until sip starts to take over the world, which will take a few
> >years at least.  all i want is for a proxy a way to mark the from number
> >of the invite as "restricted" without touching the from header AND i
> >want the chosen way to be clearly documented in the sip-isup i-d so that
> >i don't have to tell each sip/ss7/proxy vendor separately, how it is
> >done.
> >
> >what method you choose to do it, is not my business, since i'm just
> >a stupid user of the sip protocol.
> >
> >-- 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
>
>

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Feb 2002 09:17:36 -0500

Dean - I find your dissection of the issues interesting and useful.

You point out that sip doesn't deal explicitly with #4, and seem to find
that ok. I feel this is probably something that ought to be addressed
directly, because otherwise we will have a hodgepodge as bad or worse
than the old phone network.

- As you point out, a traditional call associates #4 with #1.

- Achieving anything else is a hack. The "collect" call,
  associating #4 with #2, can really only be set up via 3pcc 
  for arbitrary values of #2. The other way it is done is 
  via the "800 number" hack - certain forms of #2 result in
  #4 always associating with #2.

I think that ideally the fiscal responsibility for a call should be
negotiated. The caller may indicate either desire or reluctant
willingness to pay. Then the callee could either permit the caller to
pay, or take on the responsibility itself. In the end, the call should
complete if and only if somebody has accepted the responsibility. It is
also possible that the responsibility could be shared, but perhaps that
is too much to deal with.

Such a model would eliminate the ridiculous kludge of 800 numbers.
Instead, the caller would simply select the "collect" option when making
a call. But a negotiation of this sort requires something in the
protocol to handle the negotiation.

	Paul