Methods
GetHoldState | () | → | u: HoldState, u: Reason | |
RequestHold | (b: Hold) | → | nothing |
Signals
HoldStateChanged | (u: HoldState, u: Reason) |
Types
Local_Hold_State | Enum | u | |
Local_Hold_State_Reason | Enum | u |
Description
Interface for channels where you may put the channel on hold. This only makes sense for channels where you are streaming media to or from the members. (To see whether the other participant has put you on hold, see CallState.)
If you place a channel on hold, this indicates that you do not wish to be sent media streams by any of its members and will be ignoring any media streams you continue to receive. It also requests that the connection manager free up any resources that are only needed for an actively used channel (e.g. in a GSM or PBX call, it will be necessary to place an active call on hold before you can start another call).
This can also be used for putting a single Content on hold, if the protocol supports it (This interface is in the Channel namespace for historical reasons).
Methods
GetHoldState () → u: HoldState, u: Reason
Returns
- HoldState — u (Local_Hold_State)
- Reason — u (Local_Hold_State_Reason)
RequestHold (b: Hold) → nothing
Parameters
- Hold — b
Request that the channel be put on hold (be instructed not to send any media streams to you) or be taken off hold.
If the connection manager can immediately tell that the requested state change could not possibly succeed, this method SHOULD return the NotAvailable error. If the requested state is the same as the current state, this method SHOULD return successfully without doing anything.
Otherwise, this method SHOULD immediately set the hold state to Local_Hold_State_Pending_Hold or Local_Hold_State_Pending_Unhold (as appropriate), emitting HoldStateChanged if this is a change, and return successfully.
The eventual success or failure of the request is indicated by a subsequent HoldStateChanged signal, changing the hold state to Local_Hold_State_Held or Local_Hold_State_Unheld.
If the channel has multiple streams, and the connection manager succeeds in changing the hold state of one stream but fails to change the hold state of another, it SHOULD attempt to revert all streams to their previous hold states.
The following state transitions SHOULD be used, where appropriate:
- Successful hold: (Unheld, any reason) → (Pending_Hold, Requested) → (Held, Requested)
- Successful unhold: (Held, any reason) → (Pending_Unhold, Requested) → (Unheld, Requested)
- Attempting to unhold fails at the first attempt to acquire a resource: (Held, any reason) → (Pending_Unhold, Requested) → (Held, Resource_Not_Available)
- Attempting to unhold acquires one resource, but fails to acquire a second, and takes time to release the first: (Held, any reason) → (Pending_Unhold, Requested) → (Pending_Hold, Resource_Not_Available) → (Held, Resource_Not_Available)
Possible Errors
- Disconnected
- Network Error
- Not Available
Rationale:
Signals
HoldStateChanged (u: HoldState, u: Reason)
Parameters
- HoldState — u (Local_Hold_State)
- Reason — u (Local_Hold_State_Reason)
Types
Local_Hold_State — u
- Unheld (0)
- Held (1)
- Pending_Hold (2)
- Pending_Unhold (3)
Local_Hold_State_Reason — u
- None (0)
- Requested (1)
- Resource_Not_Available (2)