Subject: INAP Messages triggered by PINT Requests, and what they need

From: [email-masked] (Lawrence Conroy)
Date: Sun, 29 Nov 1998 23:33:17 +0000

The identities of the parties to a requested PINT service are carried in a
combination of the SIP and SDP parts of a message. There are two formats
used for these (global or local phone numbers). These will then be passed
onwards to an Executive System that will carry out the service (or not, as
the case may be :).

The Charter states that this will be an Intelligent Network (I.N.) Service
Node, but this need not be the case; it could be a "full-blown" I.N. system
with separate components, or other GSTN systems. Ensuring that all of the
information needed by an I.N. system is available is important (otherwise
we'll deliver a request, but the I.N. system won't understand it), and so
I've been looking at INAP (it was a particularly boring weekend :) to check
this. As I understand it::

Called and Calling party addresses delivered to an Intelligent Network
system that will use INAP must be specified with all of the elements that
are defined in Q.763 (ISUP). This means that the telephone number should be
either validated (or verified) by the telephone network, its format should
be specified (as International, National, Local, Network-specific, or
other), and its network number plan should be identified and indicated.

These are aspects that must be dealt with by the PINT Gateway, in
conjunction with PSTN based entities to which it's connected. They can't
really be processed in this way be IP based components, as validation is
done traditionally by (PSTN) network-based resources, and it is extremely
unlikely that an entity that is "on the Internet" will be trusted. For
example, even if a telephone customer, connected via an ISDT, sends such
information, it will still be checked by the Local Exchange to which the
information is passed [see Q.931 for details, in particular section 4.5].
If the information checks out correctly, it is flagged as network verified;
if not then the network-supplied version is put into the call setup
information, and the customer supplied data is stored as "secondary"
information. Spoofing the source of a call is a little more difficult on
the PSTN than spoofing an email on the Internet!

Where the Executive System is going to use INAP, verification and format
adjustment is one of the jobs of the PINT Gateway (probably in conjunction
with a (PSTN) network-based "trusted" resource). If not, then the Service
Control Function (SCF) will receive requests that IT will have to process
before triggering the call part of a service. The INAP message sent from
the SCF to the Service Switching Function (SSF) to start up a call is
"Initiate Call Attempt", and this message requires the party addresses to
be in this "full" format. (There are very likely to be other INAP messages
sent along with this - notably createCallSegmentAssociation, as well as a
subsequent continue), but these are purely internal to the I.N. system).

[For the gory details of the required parameters, see clause 17.60 of
Q.1228 which has the detailed operation procedures for ICA.

BTW, if you've broken your leg skiing and have a lot of time to spend, the
entry for initiateCallAttempt and InitiateCallAttemptArgs within clause 5.1
of Q.1228 has syntax details, and then you can go back through that
document to clause 4.1 to find the specifications for the
callingPartyNumber and destinationRoutingAddress arguments, and there
you'll be referred to Q.763 for encoding. If by that point you haven't
fallen asleep, there's always Q.1224 to see what's meant to be going on in
the "functional plane", and the new Q.1229, and ...

Alternatively, can I interest anyone in a book by our esteemed co-chair
that tries to explain it all to people who don't have too much time on
their hands?]

Of course, if a Service Node is used (or any other GSTN peripheral) then
checking may be done when the call request is passed out to the PSTN. INAP
(or ISUP) is not used, so there may be no point in validating data that
will be re-validated as soon as the call setup is sent. However, as the
degree of trust of Service Nodes by the rest of the PSTN to which they're
connected is highly "network-specific", the behaviour of the PINT Gateway
may differ in each case.

In summary:

*   As well as the two party addresses, the INAP initiateCallAttempt
operation that will be triggered by an SCP processing PINT requests
requires a number of other arguments, but these SHOULD be possible to give
default values at the Gateway. Apart from party verification and getting
the party information into the correct format, the information passed with
PINT requests SEEMS to be enough.

*   The latest version (01) of the PINT draft has removed references to
Q763 parameters that might have been carried with a PINT request. These
COULD be re-instated if anyone can think of a situation in which they'll be
needed - I can't think of one off-hand, as the Gateway (or a Telephone
Network entity with which it's associated) will have to do format
conversion and verification anyway, and any data sent from the IP network
with the PINT request is likely to be treated as if it were suspect.

---------- If anyone has comments on this, PLEASE post to the list; I've
not looked at the "content transformation" services
("Request-to-Hear-Content" or "the service formally known as
Request-to-Fax-back") in much detail, so am unclear of the INAP messages
that will be sent to a PSTN based Intelligent Peripheral to execute these,
and what parameters will be needed. At present I can't see how this kind of
transfer "fits" within the current ITU I.N. scheme, so any help gratefully
received!

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.