Frank,

according to the general design principle of H450 series, H.450.2 (call transfer) functionality by default resides in the endpoint. Thus the determination of user C's address becomes a local matter outside the scope of H.450.2. It could be collected from key strokes, retrieved from a directory or data base, or whatever. In the first case the call transfer functionality at user A's endpoint should prevent any digits to get out on the line (otherwise these would be treated as DTMF signals since the primary call is already in active state).

If the call transfer functionality resides in a proxy or GK rather than in endpoint A, the interface between endpoint and proxy/GK is outside the scope of H.450.2 (e.g. stimulus according to annex L). Again the call transfer functionality should take care of collecting digits entered over that interface.

So there should never be a need for "overlap sending" as part of call transfer operations.

Ernst Horvath Siemens AG

-----Ursprüngliche Nachricht----- Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] Gesendet am: Mittwoch, 22. August 2001 13:37 An: ITU-SG16@mailbag.cps.INTEL.COM Betreff: H.450.2 and overlap sending?

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

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