[Freeswitch-dev] No sound with Gizmo5 after transfer from a dial plan
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>
I suggest you look at the logs and compare the working call to 5002 from one carrier with the non working with gizmo and see what is different. Mike On Jan 22, 2010, at 1:30 AM, Paul Li 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.
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 <plite2012@gmail.com> 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>
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 <plite2012@gmail.com> 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 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
I believe so. I have logged a ticket with Gizmo5. I hope they could resolve this issue soon. On Sat Jan 23 11:18:39 PST 2010, Michael Jerris wrote:
That means they answered the call already. Is that accurate?
On Sat, Jan 23, 2010 at 1:10 AM, Paul Li <plite2012@gmail.com> 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].
participants (2)
-
Michael Jerris
-
Paul Li