After an application has acquired ownership of the call, ownership can be
transferred to another application. Why would this be necessary? Normally, to allow
the call's media mode to be changed. In this case, the highest priority
application for the new media mode should take and handle the call. Media mode
changing usually occurs because of one of the following causes.
. Through a user interface or through window messages, the application learns
that the local user wants to change media mode. For example, the user has told
the new target application (which is not yet an owner) to obtain an existing
voice call for transmitting data. The target application must now take control of
the call. In this case, the current owner notices the number of owners
increase, and then relinquishes its control of the call. Alternatively, the user could
instruct the current owner of the call to hand it off to an application that
can handle the new media mode.
Media mode change
. The service provider can detect a media mode change with lineMonitorMedia
. As an example of this, the local application is playing a recorded voice
message to the caller. During this message, the caller spontaneously decides to
transmit a fax calling tone, and the local application can respond accordingly by
changing the media mode to fax and, if necessary, handing the call off to a
fax application. Another way this can work is for a monitoring application to
enable media mode monitoring, and, when the media mode in which it is interested
is detected on a call, it can request ownership of the call. This mechanism
makes it unnecessary for every application to monitor every call for every media
Remote party command
. The remote party can interactively indicate a change in media modes during
an existing call. For example, the local application is using lineMonitorDigits
to monitor DTMF input by the remote caller. Through this monitoring, the
caller indicates, for example, that a fax is about to be sent. Other ways the
caller can control local applications is with commands received on other data
connections and through ISDN user-user information messages.
A call handoff will have one of these outcomes:
- The call is given to another application (SUCCESS),
- The handing-off application is itself the target (TARGETSELF),
- The handoff fails (TARGETNOTFOUND).
If the application that is receiving the handed-off call already has a call
handle to the call, this old call handle is used. Otherwise a new call handle is
created. In either case, the application ends up with owner privileges to the
call. Whenever the handing-off application is not the same as the target
application, the target is informed about the handoff in a LINE_CALLSTATE
message with dwParam3
set to LINECALLPRIVILEGE_OWNER, as if it were receiving a new call.
The LINE_CALLSTATE parameter dwParam3
is set to owner only if the LINE_CALLSTATE message is being sent to an
application that is the initial owner of a new call, is the target of a handoff, or
was previously a monitor or an owner of the call. The parameter dwParam3
can be set to monitor only if the LINE_CALLSTATE message is sent to the
application when it is presented a new call for monitoring. In all other cases (such
as when the application already has a handle to the call, and its ownership
state is not being changed), dwParam3
is set to 0.
If the current owner application is told to change modes, it does so by
handing off the call to an application used for the target media mode. The two types
of call handoffs are described in the following topics.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages