AW: H.450.2 and overlap sending?

[Horvath Ernst]

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 at PHILIPS.COM]
> Gesendet am: Mittwoch, 22. August 2001 13:37
> An: ITU-SG16 at 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 at mailbag.intel.com
>

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