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.sob...@marketelsystems.com Web: http://www.marketelsystems.com _______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
