[Freeswitch-dev] Bug with variable_endpoint_disposition and Answer-State event parameters
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@marketelsystems.com Web: http://www.marketelsystems.com
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@marketelsystems.com Web: http://www.marketelsystems.com
On Tue, Mar 02, 2010 at 12:39:18PM -0600, Mark Sobkow wrote:
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.
Which timeout variable(s) are you setting, there are several and they have different effects. See http://wiki.freeswitch.org/wiki/Channel_Variables for at least a partial list. Andrew
Clearly you used the originate timeout incorrectly. On Tue, Mar 2, 2010 at 12:39 PM, Mark Sobkow <m.sobkow@marketelsystems.com>wrote:
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@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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
I tried changing the answer timeout to 2 seconds, but Freeswitch "originate" is definitely not honouring that request. The originate command is: originate, sofia/external/533@rats.marketel '&erlang( pbx_called_cust pursuit@testsrv )' 5 Mark Sobkow wrote:
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@marketelsystems.com Web: http://www.marketelsystems.com
do you mean bridge_answer_timeout? if you see the wiki, that variable only pertains to bridged calls in early_media state. you probably want: http://wiki.freeswitch.org/wiki/Channel_Variables#originate_timeout On Tue, Mar 2, 2010 at 12:47 PM, Mark Sobkow <m.sobkow@marketelsystems.com>wrote:
I tried changing the answer timeout to 2 seconds, but Freeswitch "originate" is definitely not honouring that request. The originate command is:
originate, sofia/external/533@rats.marketel '&erlang( pbx_called_cust pursuit@testsrv )' 5
Mark Sobkow wrote:
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@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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
participants (3)
-
Andrew Thompson
-
Anthony Minessale
-
Mark Sobkow