[asterisk-dev] Manager event for early media

[Olle E. Johansson]

15 apr 2011 kl. 14.31 skrev Olle E. Johansson:

> 
> 15 apr 2011 kl. 14.23 skrev Russell Bryant:
> 
>> 
>> ----- Original Message -----
>>> I think that this fits into the Newstate event (I am against inventing
>>> a new manager event). About adding a new state to ast_channel_state, I
>>> am not qualified to suggest anything but it sounds logical to add it.
>>> Advertize a state via AMI and not having a different way to get that
>>> state by other means (ast cli, custom module, etc) is not good at all.
>> 
>> Agreed, the NewState event seems to make sense (which pretty much implies that we have to add a channel state).  That's a potentially tricky change to make.  We just have to look through places that care about channel state and make sure that the new state is accounted for.
> 
> Well, there are states and flags. MUTE is a flag, not a state. Maybe we should implement PROGRESS as a flag, since it's in the RING or RINGING state. Implementing a new state would be hard, as you say, but a flag might be easier. 
> 
> I haven't verified that all parts of the code filter out the flags though. How sure are we about the flags vs states in ast_channel_state ?
> 
Running GREP on the source code I realize that the AST_STATE_MUTE value is not used anywhere... Ouch.

agave:asterisk-trunk olle$ grep AST_STATE_MUTE */*.c
agave:asterisk-trunk olle$ grep AST_STATE_MUTE include/asterisk/*
include/asterisk/channelstate.h:	AST_STATE_MUTE = (1 << 16),	/*!< Do not transmit voice data */
agave:asterisk-trunk olle$ 


So I guess we have an open field here. The first question is: Would PROGRESS really be a new state or just an attribute to a state? Are we in PROGRESS STATE as opposed to RINGING or is it just a variant of RINGING?

Just to give other examples: HOLD is not a channel state, it's an extension state. The call is still in UP state. 

If it's a new state, we need to make sure that all channel state changes in the code can handle the new state properly. 
If it's an attribute, like MUTE, we need to make sure that every part of the code that handles ast_channel_state will not bother with these codes. AST_STATE_RINGING | AST_STATE_PROGRESS should be the same as RINGING for the parts of the code that doesn't care if we have early media or not.

MUTE should propably be removed from ast_channel_states since we have HOLD as an extension state.
/O