[Freeswitch-dev] Bug with variable_endpoint_disposition and Answer-State event parameters

[Mark Sobkow]

Never mind.  What's actually happening is now that I've got the Erlang 
events firing, the timeout on the originate command doesn't seem to be 
working.  I had a timeout of 5 seconds set, but Freeswitch kept ringing 
until our voice mail system answered my phone (30 seconds.)

*sigh*

Not that it's any better a result, as we DO need to timeout calls that 
aren't being answered.

Mark Sobkow wrote:
> I think I may have found a bug in Freeswitch, as both answered and 
> ringing calls have an "Answer-State" "answered" and 
> variable_endpoint_disposition ANSWER, though in one case the call has 
> NOT been answered.
>
> For a normally answered call, the following Freeswitch events are 
> propagated to Erlang:
>
> CHANNEL_DATA
> CHANNEL_PARK
> CHANNEL_HANGUP
> CHANNEL_UNPARK
> CHANNEL_EXECUTE_COMPLETE
> CHANNEL_STATE
> CHANNEL_HANGUP_COMPLETE
> CHANNEL_STATE
> CHANNEL_DESTROY
> CHANNEL_STATE
>
> For an unanswered call, the events are:
>
> CHANNEL_DATA
> CHANNEL_EXECUTE
> CHANNEL_PARK
> CHANNEL_HANGUP
> CHANNEL_UNPARK
> CHANNEL_EXECUTE_COMPLETE
> CHANNEL_STATE
> CHANNEL_HANGUP_COMPLETE
> CHANNEL_STATE
> CHANNEL_DESTROY
> CHANNEL_STATE
>
> This is going to make the call processing a little complex, as both 
> variants produce a CHANNEL_PARK early in the call processing, and 
> later produce the HANGUP event.
>
> The problem is that with an answered call, I have to uuid_bridge the 
> operator on the CHANNEL_PARK event within 2 seconds to meet legal 
> requirements, while with an unanswered call it's another 30 seconds 
> (configurable) before the CHANNEL_HANGUP event propagates to let me 
> know that the call went unanswered.
>


-- 
Mark Sobkow
Senior Developer
MarkeTel Multi-Line Dialing Systems LTD.
428 Victoria Ave
Regina, SK S4N-0P6
Toll-Free: 800-289-8616-X533
Local: 306-359-6893-X533
Fax: 306-359-6879
Email: m.sobkow at marketelsystems.com
Web: http://www.marketelsystems.com