191 lines
6.4 KiB
Plaintext
191 lines
6.4 KiB
Plaintext
call state messages between epoint and port, call and endpoint objects:
|
|
-----------------------------------------------------------------------
|
|
|
|
MESSAGE_SETUP
|
|
- a new call is set up
|
|
|
|
MESSAGE_MORE
|
|
- more digits are needed
|
|
|
|
MESSAGE_PROCEEDING
|
|
- call proceeds, no more digits needed
|
|
|
|
MESSAGE_ALERTING
|
|
- call alerts, no more digits needed
|
|
|
|
MESSAGE_CONNECT
|
|
- call connects
|
|
|
|
MESSAGE_DISCONNECT
|
|
- call disconnects, but not yet released
|
|
|
|
MESSAGE_RELEASE
|
|
- call has been released
|
|
|
|
* other messages like dialing information, notifications and others
|
|
are processed by the objects and can cause other internal states to change
|
|
but will not change any call state. objects may analyze the given information
|
|
and process call state message. (e.g MESSAGE_DISCONNECT when dialing a wrong
|
|
number)
|
|
|
|
|
|
states of port object:
|
|
----------------------
|
|
|
|
PORT_STATE_IDLE
|
|
- port is just created, no setup yet
|
|
PORT_STATE_IN_SETUP
|
|
- a setup was received from isdn stack
|
|
PORT_STATE_OUT_SETUP
|
|
- a setup was sent to isdn stack
|
|
PORT_STATE_IN_MORE
|
|
- the endpoint object requires more digits to complete the call
|
|
PORT_STATE_OUT_MORE
|
|
- the port object requires more digits to complete the call
|
|
PORT_STATE_IN_PROCEEDING
|
|
- the incoming call proceeds, no more digits needed
|
|
PORT_STATE_OUT_PROCEEDING
|
|
- the outgoing call proceeds, no more digits needed
|
|
PORT_STATE_IN_ALERTING
|
|
- the incoming call alerts, no more digits needed
|
|
PORT_STATE_OUT_ALERTING
|
|
- the outgoing call alerts, no more digits needed
|
|
PORT_STATE_CONNECT
|
|
- the call is active
|
|
PORT_STATE_IN_DISCONNECT
|
|
- the call is disconnected from the incoming side
|
|
PORT_STATE_OUT_DISCONNECT
|
|
- the call is disconnected from the outgoing side
|
|
PORT_STATE_RELEASE
|
|
- the call is released, the port object waits for the l3-process to terminate
|
|
|
|
|
|
states of endpoint object:
|
|
--------------------------
|
|
|
|
EPOINT_STATE_IDLE
|
|
- endpoint is just created, no setup yet
|
|
EPOINT_STATE_OUT_SETUP
|
|
- a setup was received from call object
|
|
EPOINT_STATE_IN_MORE
|
|
- the port object requires more digits to complete the call
|
|
EPOINT_STATE_OUT_MORE
|
|
- the call object requires more digits to complete the call
|
|
EPOINT_STATE_IN_PROCEEDING
|
|
- the incoming call proceeds, no more digits needed
|
|
EPOINT_STATE_OUT_PROCEEDING
|
|
- the outgoing call proceeds, no more digits needed
|
|
EPOINT_STATE_IN_ALERTING
|
|
- the incoming call alerts, no more digits needed
|
|
EPOINT_STATE_OUT_ALERTING
|
|
- the outgoing call alerts, no more digits needed
|
|
EPOINT_STATE_CONNECT
|
|
- the call is active
|
|
EPOINT_STATE_IN_DISCONNECT
|
|
- the incoming call is disconnected
|
|
EPOINT_STATE_OUT_DISCONNECT
|
|
- the outgoing call is disconnected
|
|
|
|
|
|
states of call:
|
|
---------------
|
|
|
|
there are no call states.
|
|
|
|
|
|
procedure of messages between port and endpoint objects:
|
|
--------------------------------------------------------
|
|
|
|
INCOMING CALL (port->endpoint)
|
|
- the endpoint object is created by the port object.
|
|
- a MESSAGE_SETUP is sent as the first message port->endpoint.
|
|
the port goes into PORT_STATE_IN_SETUP state.
|
|
the endpoint goes into EPOINT_STATE_IN_MORE state or any other state after
|
|
processing the given dialing information.
|
|
- the endpoint MUST now respond with MESSAGE_MORE, MESSAGE_PROCEEDING,
|
|
MESSAGE_ALERTING, MESSAGE_CONNECT, MESSAGE_DISCONNECT.
|
|
the endpoint goes into the appropiate EPOINT_STATE_IN_* state.
|
|
the port goes into the appropiate PORT_STATE_IN_* state.
|
|
|
|
OUTGOING CALL (endpoint->port)
|
|
- the port object is created by the endpoint object.
|
|
- a MESSAGE_SETUP is sent as the first message endpoint->port.
|
|
the endpoint goes into EPOINT_STATE_OUT_SETUP state.
|
|
the port goes into PORT_STATE_OUT_SETUP state.
|
|
- the port may now respond with MESSAGE_MORE, MESSAGE_PROCEEDING,
|
|
MESSAGE_ALERTING, MESSAGE_CONNECT, MESSAGE_DISCONNECT.
|
|
the port goes into the appropiate PORT_STATE_OUT_* state.
|
|
the endpoint goes into the appropiate EPOINT_STATE_OUT_* state.
|
|
|
|
DISCONNECTING CALL (endpoint->port)
|
|
- the endpoint may disconnect the call at any state, except IDLE.
|
|
it sends MESSAGE_DISCONNECT.
|
|
the endpoint goes into EPOINT_STATE_OUT_DISCONNECT state.
|
|
the port goes into PORT_STATE_OUT_DISCONNECT state.
|
|
|
|
DISCONNECTING CALL (port->endpoint)
|
|
- the port may disconnect the call at any state, except IDLE.
|
|
it sends MESSAGE_DISCONNECT.
|
|
the port goes into PORT_STATE_IN_DISCONNECT state.
|
|
the endpoint goes into EPOINT_STATE_IN_DISCONNECT state.
|
|
|
|
RELEASING CALL (port->endpoint, endpoint->port)
|
|
- at any state, this message is possible
|
|
the object sends MESSAGE_RELEASE, the port will terminate soon.
|
|
the receiving object will unlink the relation to the sending object.
|
|
|
|
|
|
procedure of messages between endpoint and call objects:
|
|
|
|
CALL PROCEEDING (endpoint->call, call->endpoint)
|
|
- any message will be sent to the call and transfered to the other end
|
|
- any message will be received from the endpoint coming from the other end
|
|
- if more than two endpoints are connected in one call, the messages are
|
|
blocked.
|
|
- if only one endpoint exists after creation, the call will create another
|
|
endpoint and delivers the MESSAGE_SETUP
|
|
|
|
CALL RELEASE (endpoint->call, call->endpoint)
|
|
- the endpoint sends MESSAGE_RELEASE in order to be removed from the call.
|
|
the endpoint will soon terminate.
|
|
the call will remove the endpoint and if there is only one endpoint left,
|
|
it will send a MESSAGE_RELEASE to the endpoint and will release itself.
|
|
|
|
|
|
DISCONNECT and RELEASE
|
|
----------------------
|
|
|
|
the endpoint may receive MESSAGE_RELEASE from a call but may NOT send it
|
|
to the port. the port MUST get a MESSAGE_DISCONNECT instead.
|
|
|
|
|
|
REMOTE APPLICATION PROCEDURE
|
|
----------------------------
|
|
|
|
MESSAGE_NEWREF
|
|
- is sent before outgoing setup may be sent
|
|
- is received before outgoing setup may be sent
|
|
- is received before incoming call
|
|
|
|
MESSAGE_BCHANNEL
|
|
- type BCHANNEL_REQUEST is sent to get the bchannel stack
|
|
the ref is required to find the corresponding port class
|
|
- type BCHANNEL_ASSIGN is received, if channel is available, ACK must be sent
|
|
the ref is given with the bchannel stack.
|
|
- type BCHANNEL_ASSIGN_ACK must be sent to acknowledge channel
|
|
the ref is 0, the stack address must be set to find corresponding channel
|
|
- type BCHANNEL_REMOVE is received, if channel is not available anymore
|
|
the stack must then be release, the ACK must be sent.
|
|
the ref is given with the bchannel stack.
|
|
- type BCHANNEL_REMOVE_ACK must be sent after releasing stack.
|
|
the ref is 0, the stack address must be set to find corresponding channel
|
|
|
|
MESSAGE_RELEASE
|
|
- will be received or sent to release call and ref.
|
|
|
|
what happenes to channels that are not acked?
|
|
-> one solution may be: they are blocked until the port is unloaded/unblocked.
|
|
|
|
|
|
|