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

[Anthony Minessale]

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 at 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 at rats.marketel '&erlang( pbx_called_cust
> pursuit at 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 at marketelsystems.com
> Web: http://www.marketelsystems.com
>
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at 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 at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20100302/1f23c326/attachment-0001.html