At 15:06 01/09/98 +0100, you wrote:

Santo,

Enclosed are my responses to your comments. Hopefully this will help

clarify my

meaning in the areas where the proposal was unclear.

Regards,

Andy

--

Andrew Draper - Principal Development Engineer - WAVE Software

Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks.

mailto:adraper@dev.madge.com phone:+44 1753 661329

pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

Extracted from the doicument:

...

...

...

<excerpt>In order to have a chance of success the SETUP message must contain authentication and payment tokens as specified by the recipient in the LCF message. Examples of these tokens would be "this is e-cash which will be redeemed by bank X" / "here is my account number with you" / "here is my credit card number (account number with third party).

Consider the way this is solved in the PSTN world today: the customer usually has a choice whose network resources to use. E.g., in the US, one can dial 1.800.CALL.ATT and then s/he will be prompted with authentication queries. My question is whether in this situation we can push the authentication and billing issues to a higher level protocol, or even to the user and IVR systems/operators?

We need an authentication/billing protocol. I expect this to result in a token which can be attached to the SETUP message (although other messages may need to be sent beforehand in order to obtain the token).

If the call is gateway-ed several hops, how do you envision this will work? Would every gateway return back its specific charges for the call to the endpoint or to the gateway one hop up stream?

If the call is passed through several hops then I expect each hop to reflect the charges for the next hop back to the previous hop. This doesn't require any changes to the protocol. I don't really see any need for calls going through multiple gatekeepers/gateways, however providing that whatever we come up with doesn't exclude them then I think we will be OK.

Billing is a real-world problem, the method I am familiar with (and therefore am comfortable with), is done at the user level passing credit card/calling card information. For example, I would be less comfortable with my credit card information within the Setup message traversing the Internet to systems that was "automatically" chosen for me to accept my call.}

I will oppose any authentication scheme which involves credit card numbers being sent unencrypted. I hope we can work out some sort of secure mechanism for sending them (probably using some sort of encryption)

The question of automatically sending credit card numbers is more a user interface one than anything else. A reasonable endpoints might decide to put up a dialogue box when it is about to send the users (encrypted) credit card number to a foreign BE. An originating BE might have a list of systems which it will send encrypted credit card/account numbers to and use only those for SETUP messages. These are local policy issues which need discussing but I don't want to include here for fear of delaying a first step towards appendix G.

</excerpt><<<<<<<<

From my POV, this underscores the need for thought on the Back End

Services, both in terms of the services to be offered, and the protocol(s) to support those services.

Here, it is fairly clear that authentication and billing is a Back End Service. The available destinations for a call may be dependent on the (authenticated) identity of the caller. The "token" to be included in the Setup message is produced by the Back End Service and may well be destination sensitive. Which raises the possibility of address translation also being a back end service.

Back-End Services (may) include:

o caller identification, authentication, and authorisation;

o address translation, gateway location;

o call pricing;

o call detail recording, billing, and settlement;

which are all interrelated and, in total, outside the scope of the gatekeeper to gatekeeper communications.

Douglas