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@mailbag.intel.com