Subject: Correspondence from ITU-T SG 11

From: [email-masked] (Lawrence Conroy)
Date: Sat, 27 Mar 1999 13:57:37 +0100

First, many thanks to the SoI experts for reviewing the latest PINT draft,
and to Jay Hilton for clarifying the relationship with the ITU.

There were a number of points that were relevent to PINT in the note posted
to the list for Mr. Kenyoshi. I'll attempt to address those here.
Initially, however, I would like to clear up an apparent misunderstanding.
PINT is NOT concerned with VoIP; instead, it exists to deliver service
requests from the Internet to the PSTN/IN, and potentially to receive
responses from the I.N. on the disposition of the service requested.

Re. Validation of User-supplied PSTN addresses:
Where the "PINT services" specify numbers that will be delivered to the
PSTN, the situation with current PSTN services that specify phone numbers
by user input would seem to apply. My understanding is that the receiving
PSTN/IN entity will validate these user supplied PSTN addresses. There are
special circumstances in which the user-supplied number is accepted, but
outside of these one would expect the numbers to be validated in the normal
way (cf. Q.763, sub-clause 3.1.1.4, (f) screening indicator).

Whilst it is not strictly applicable to PINT as it forms part of a SETUP
(i.e. call control rather than SERVICE control) message, the Q.931
information element coding shown in Q.931 sub-clause 3.1.1.4 and sub-clause
4.5.10 for an ISDT to deliver a user specified number along with its setup
request gives an example of the delivery of user-specified numbers within
the ISDN.

As is usual, the recipient PSTN entity is perfectly free to re-validate the
received PSTN addresses, and may ignore any parameters passed in a request.
I understand that this is the case for call setup requests delivered over
Q.931 signalling systems; we do not specify any variation as we assume that
similar procedures would apply.

Presentation Restriction:
If a PINT service request indicates presentation restriction is requested,
then the Executive System (SCF) would be expected by the requesting user to
honour that request. Again, this is no different from current PSTN and I.N.
procedures, and reflects our understanding of default PSTN entity
behaviour.

We use the term "presentation restriction" within the PINT document to mean
just that; the parties to any resulting service call are requested to not
have their correspondent's line identiy presented. It does NOT mean that
the identity of the parties cannot be used whilst processing a service
request; how would the Executive System be able to fulfil a request if it
didn't know the party addresses to be used in a service call?

I (for one) don't understand how "presentation restriction" could be taken
to mean anything other than restriction of the presentation of
corresponding party addresses; that's what is described in the PINT
documents, and that is what I understand to be standard meaning within the
PSTN.

Re. authentication and authorization:
the PINT documents have discussed these; the standard mechanisms for
authentication and encryption/signing of requests are taken from the SIP
document (RFC2543). In addition, the "opaque reference" mechanism described
in the PINT document may be used to carry data within a request that can be
used to convince the recipient system to carry out the service requested.

As this is a private matter between the requesting user and the recipient
Operator of the Executive System that processes the request, specification
of the data and its treatment is outside of the scope of an Internet
Protocol. We merely provide a mechanism for rejecting unauthenticated or
unauthorized requests, and for carrying identifying and authorizing data.
Both these are mentioned within RFC2543 and the PINT document.

I hope this is helpful, and will be interested to see other postings on
this list; these topics reflect an interest in the way that PINT service
processing will be used in the "Real World" and as such complement the
development of the PINT profile of SIP and SDP (i.e. the Internet Protocol
work).

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------
This message came from the IETF PINT Working Group Mailing List.