H.450.2 and overlap sending?

[Frank Derks]

In the case where no secondary call exists, an initiating endpoint
(the A-party) has the choice of first setting up a secondary call
and then transferring at some stage, or to simply start the transfer
(a "blind" transfer" through a FACILITY message containing a
ctInitiate.Invoke. In the latter case the reroutingNumber in the
CTInitiateArg contains the (whole) number of the "C-party".

What this implies is that the A-party must have some way of
collecting entered digits and deciding when the number is complete,
after which it sends the FACILITY message with the ctInitiate.Invoke
or the user interface of the A-party must be such that it allows
for entering a number for this purpose, after which transfer can
be interactively activated, resulting in the sending of a FACILITY
message with the ctInitiate.Invoke.

There does not seem to be an obvious (or even possible) way to
indicate to the receiving party that a transfer should be effected
(E.g. through a ctInitiate.Invoke with an empty reroutingNumber)
after sufficient number information has become available (E.g. in
INFORMATION messages). This means that endpoints that would
normally translate keypresses on the keypad to sending INFORMATION
messages, would have to have special provisions to deal with this
situation.

Is this a correct interpretation of the Reommendation?

Regards,

Frank

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com