[asterisk-dev] Manager event for early media

[Olle E. Johansson]

15 apr 2011 kl. 16.37 skrev Russell Bryant:

> On 04/15/2011 08:04 AM, Olle E. Johansson wrote:
>> 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.
> 
> res/snmp/agent.c reads it, but no code sets it.
Oh, I did not grep that far down... Good catch.

>  It can be removed.  I
> can't remember it ever being used.  I bet it has been there since the
> dawn of (Asterisk) time and whoever knew what it was used for has since
> forgotten.  :-)
> 
> There is a whole bunch of code that reads the state directly.  If any
> flags were used, a bunch of stuff would break.  I think we should remove
> AST_STATE_MUTE and not use any flags in that field.
Agree.
> 
> Good point about call hold.  That could have been a channel state, I
> guess.  I don't know what the reasoning is there ... I think the
> introduction of HOLD was before my time.
I think you're wrong ;-) If I remember correctly, hold was added when someone wrote the SLA stuff in meetme. I remember helping this guy with some SIP signalling stuff for HOLD in a NOTIFY...

> 
> Early media is a generic enough telephony concept that I do believe that
> it makes sense to capture it on ast_channel.  I can't think of a better
> place for it than channel state.
Before making a decision here, I want to check how ISDN handles this - if it's a call state or just an attribute. In SIP it's not a call state and would mess stuff up. It is more of a media state. Do we have any media in the early states of the call or not? The same goes for MUTE, HOLD. They all indicate the state of the media stream. Maybe we should implement a media state in the channel structure.

/O