That means they answered the call already. Is that accurate? On Jan 23, 2010, at 2:10 AM, Paul Li wrote:
> By comparing the log from a working service provider (Working) to that > from Gizmo5, I have found out the problem might be Gizmo5 (service > provider). While FreeSWITCH was performing TRANSFER, > > Gizmo5: Channel sofia/softphone/001x...x entering state [completing][200] > Working: Channel sofia/softphone/001x...x entering state [proceeding][180] > > Gizmo5: Channel sofia/softphone/001x...x entering state [ready][200] > Working: Channel sofia/softphone/001x...x entering state [proceeding][180] > > Gizmo5: [Channel sofia/softphone/001x...x] has been answered > Working: Pre-Answer sofia/softphone/001x...x > > Both began "Running State Change CS_ROUTING". After routing was > successful, the working service provider finally enter [200] state. > > Working: Channel sofia/softphone/001x...x entering state [completing][200] > Working: Channel sofia/softphone/001x...x entering state [ready][200] > > At this point, the working service provider finally connects > sofia/softphone/001x...x to the playback channel. I am wondering what > response Gizmo5 sent to FreeSWITCH and led FreeSWITCH to think the > call prematurally entered state [completing][200] and [ready][200]. > > > On Fri, Jan 22, 2010 at 12:30 AM, Paul Li <[email protected]> wrote: >> It is a very interesting and challenging issue! What I am trying to >> achieve is playback a message (notice) to PSTN telephones with Gizmo5 >> as service provider with the originate command as follows: >> >> $ originate sofia/gateway/gizmo/0019876543210 5001 (Case 1) >> >> $ originate sofia/gateway/gizmo/0019876543210 5002 (Case 2) >> >> I can hear the playback from extension 5001 in the first case, while I >> could not hear anything from extension 5002 in the second case. The >> difference between them lies in that extension 5002 transfer the call >> when the PSTN phone is connected. Please see the dial plan below. Both >> dial plans are basically adapted from examples found in the online >> documents. Both 5001 and 5002 work for my two other voip service >> providers. On the surface, it appears to be Gizmo5's problem. But, I >> am wondering if there is any issue on the FreeSwitch side. >> >> My main goal is to delay playback until the end user has picked up the >> phone. I have been looking for a way to do this but ended up with >> nothing so far. I have tried setting {ignore_early_media=true}, but >> that did not help either. >> >> I am welcome any suggestion on how to achieve this. In the meanwhile, >> I would like point out this issue. >> >> <!-- a simple IVR demo with direct playback --> >> <extension name="direct_ivr_demo1"> >> <condition field="destination_number" expression="^5001$"> >> <action application="start_dtmf" /> >> <action application="playback" data="test.wav"/> >> </condition> >> </extension> >> >> <!-- a simple IVR demo with indirect playback --> >> <!-- use execute_on_answer to delay playing back until the bridge has >> been established --> >> <extension name="indirect_ivr_demo2"> >> <condition field="destination_number" expression="^5002$"> >> <action application="set" >> data="execute_on_answer=transfer >> ANSWERCALL XML default"/> >> <action application="sleep" data="60000"/> >> <action application="transfer" data="NOANS XML >> default"/> >> </condition> >> </extension> >> >> <!-- execute_on_answer: Call answered at far end --> >> <extension name="Call_Answered"> >> <condition field="destination_number" >> expression="^ANSWERCALL$"> >> <action application="start_dtmf" /> >> <action application="playback" data="test.wav"/> >> </condition> >> </extension> >> >> <!-- execute_on_answer: No answer at far end --> >> <extension name="Call_Not_Answered"> >> <condition field="destination_number" expression="^NOANS$"> >> <action application="hangup" data="NO_USER_RESPONSE"/> >> </condition> >> </extension> >> > > _______________________________________________ > FreeSWITCH-dev mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org _______________________________________________ FreeSWITCH-dev mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
