March 2010 - FreeSWITCH-users - FreeSWITCH Mailing Lists

ESL and application "break" (to stop file playback) - timing issues.
by Peter Olsson 16 Mar '10

16 Mar '10

I'm not sure if this belongs in Jira, or if it's possible to do it another way - so I try the list first :) I'm using ESL to do some IVR functions. Basically I play some sound files, wait for DTMF, and then do something, like record a message, transfer the call to a mobile phone etc. Quite basic and simple. I've noticed one problem with this, and it's when I want to stop playback using command "break". In 99% of the time everything works as expected, but sometimes I get this problem - and the problem is that the current file doesn't stop playing. And I think I know why this is happening. Lets say I first send playback(tone_stream://%(1500, 3500, 440.0, 0.0);loops=100) to the channel. This will play a ring-tone (swedish) and loop through it 100 times. When I want to stop this tone I send the break command, and directly after this a new playback command. Maybe 1 time in 100 tries the tone_stream doesn't stop playing. I think this is becuase how break works. From what I understand from the source it just sets the CF_BREAK flag on the channel, and then the playback application will detect this and stop the playback. However, when I send a new playback command immediately after break it will reset the CF_BREAK-flag again, to make sure it won't cause any problems for the new playback. So if the original playback (tone_stream) didn't check the flag before it was reset, it won't known that it was supposed to stop playing. I guess I could wait 50ms before sending the new playback message, but I can really never be sure that it was handled properly. Is there any other way around this? How about "break <uuid> all", will it make any difference in this case? Or should this just be treated as a timing bug, and filed to Jira? Any help on this would be greatly appreciated. These are the messages I'm sending; SendMsg <uuid> call-command: execute execute-app-name: playback execute-app-arg: tone_stream://%(1500, 3500, 440.0, 0.0);loops=100 When I don't want this to play anymore I send a break; SendMsg <uuid> call-command: execute execute-app-name: break And immediately after this I want to play another file; SendMsg <uuid> call-command: execute execute-app-name: playback execute-app-arg: file/to/play.wav Regards, Peter Olsson

2 8

SIP to PRI RECOVERY_ON_TIMER_EXPIRE error using Sangoma (sangoma_prid)
by Tzury Bar Yochay 16 Mar '10

16 Mar '10

Hi, This is my setup FreeSWITCH: Version 1.0.trunk (16992M) Sangoma: wanpipe-3.5.10.3.smg_pri-v1.58 I have finally managed to set up the environment coping many hick-ups reported in this mailing list recently. However, I am still encountering problems when trying to perform call from SIP to PRI. I have configured my dialplan to bridge all numbers which are not pastebin for all configuration files is available at: http://pastebin.freeswitch.org/12437 pastebin for CLI output is available at: http://pastebin.freeswitch.org/12436

3 9

ICE related sdp headers forwarding
by RobertT 16 Mar '10

16 Mar '10

Hi guys! In my installation I have a public FS being connected by lots of clients and being used to connect them with each other. Some of them might be backed by various NATs. And though they all use STUN to discover their public IP address, sometimes it's just not enough to provide two-way sound. These clients all have ICE and TURN support, but it is useless, since FS doesn't support ICE (at least that's what I know), and there are no ICE-related headers in FS's originating SDP for b-leg. Currently, all calls are being connected by means of bridge app with proxy_media mode enabled. For now, I can only think of couple of ways to enable ICE negotiation between a and b: 1. Redirect a directly to b. But to accomplish this I've to know b's IP, that it was registered with, which is being stored in sip_registrations db. Can I obtain it with db app in dialplan and substitute as a parameter to deflect app? 2. Force FS to copy remote SDP headers, or at least a part of them, to it's local SDP. 3. I feel I might be missing something important... Please help me to find a best solution to enable ICE negotiation. Best regards, RobertT.

1 1

Re: [Freeswitch-users] IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds
by William Traenkle 16 Mar '10

16 Mar '10

Michael, Thanks for your help. I was able to get it work, however, I would like your opinion as how to do this correctly as I have a hunch I may have opened up some security risks or have gone against freeswitch best practices. If not, just let me know and I will leave it as is. I modified the public.xml file under /conf/dialplan/ I uncommented the following:  I added the following:  <extension name="send_to_voicemail"> <condition field="destination_number" expression="^\*99(\d{3,6})$"> <action application="answer"/> <action application="sleep" data="1000"/> <action application="set" data="dialed_extension=$1"/> <action application="export" data="dialed_extension=$1"/> <action application="voicemail" data="default ${domain_name} ${dialed_extension}"/> </condition> </extension>  <X-PRE-PROCESS cmd="include" data="default/*.xml"/> ________________________________ From: Michael Collins <msc(a)freeswitch.org> To: William Traenkle <will.traenkle(a)yahoo.com> Sent: Mon, March 15, 2010 5:11:57 PM Subject: Re: IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds On Mon, Mar 15, 2010 at 4:22 PM, William Traenkle <will.traenkle(a)yahoo.com> wrote: When a hunt group is accessed from the main IVR, the hunt group dials >an internal extension via correctly but when trying to dial an >external number such a cell phone via sip uri it is unable to connect >or ring the cell phone and it waits the correct timeout period before it >goes to voicemail. > >However, if you dial the hunt group directly without going through the main IVR, the external number such as cell phone that uses sip uri to connect to it work perfect. > > > >>There is only an issue when the hunt group is accessed from the main IVR when dialing an external number using sip uri. > >>1) fs_cli output for successful call scenario directly to x7000 hunt group: http://pastebin.com/Q1ayXkNR > >>2) fs_cli output for failed call scenario x5002 IVR to x7000 hunt group: http://pastebin.com/FaxuGdJ3 In #2 your call to 7000 is hitting the public context. Most likely this isn't what you were anticipating. Try handling 7000 in the public context. Find the public_extensions dp entry and update your regex there: <condition field="destination_number" expression="^(10[01][0-9]|7000)$"> reloadxml and try again. If it works then consider creating a public context extension that specifically handles these calls, perhaps checking the IP address of the source of the call. -MC > >>3) autoattendant_5002.js script: http://pastebin.com/FaxuGdJ3 > >>4) huntgroup_7000.js script: http://pastebin.com/wNX9K7Ab > > >5) Dialplan default.xml: >http://pastebin.com/iAbNSW9E > >If you require additional information or have any other >questions, please let me know. > >>Thanks, > >>-Will > ________________________________ From: Michael Collins <msc(a)freeswitch.org> >To: freeswitch-users(a)lists.freeswitch.org >Sent: Tue, March 9, 2010 11:00:53 PM >Subject: Re: [Freeswitch-users] IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds > > > > >On Tue, Mar 9, 2010 at 9:55 PM, William Traenkle <will.traenkle(a)yahoo.com> wrote: > >When a hunt group is accessed from the main IVR, the hunt group dials an internal extension via transfer correctly but when trying to dial an external number such a cell phone via sip uri it is unable to connect or ring the phone but it waits the correct timeout period before it goes to voicemail. >> >>However, if you access the hunt group directly without going through the main IVR, all works perfectly. >> >>Any ideas where I should look and what line of code I might be missing? >> >> > >Start by capturing the fs_cli debug output for the IVR call. Look through the debug lines for clues as to what is happening with your call. The symptom "unable to connect" has many possible causes, so try to locate the debug lines leading up to the attempt to bridge the SIP URI. If you want community help then pastebin the full debug log plus the relevant XML: the dialplan extension and the IVR definition. >> >-MC > > >

2 1

Re: [Freeswitch-users] IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds
by William Traenkle 16 Mar '10

16 Mar '10

Michael, Last question, what dictates when a call uses the public.xml or the default.xml dial plan? Thanks, ________________________________ From: William Traenkle <will.traenkle(a)yahoo.com> To: Michael Collins <msc(a)freeswitch.org>; freeswitch-users(a)lists.freeswitch.org Sent: Tue, March 16, 2010 1:03:32 AM Subject: Re: IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds Michael, Thanks for your help. I was able to get it work, however, I would like your opinion as how to do this correctly as I have a hunch I may have opened up some security risks or have gone against freeswitch best practices. If not, just let me know and I will leave it as is. I modified the public.xml file under /conf/dialplan/ I uncommented the following:  I added the following:  <extension name="send_to_voicemail"> <condition field="destination_number" expression="^\*99(\d{3,6})$"> <action application="answer"/> <action application="sleep" data="1000"/> <action application="set" data="dialed_extension=$1"/> <action application="export" data="dialed_extension=$1"/> <action application="voicemail" data="default ${domain_name} ${dialed_extension}"/> </condition> </extension>  <X-PRE-PROCESS cmd="include" data="default/*.xml"/> ________________________________ From: Michael Collins <msc(a)freeswitch.org> To: William Traenkle <will.traenkle(a)yahoo.com> Sent: Mon, March 15, 2010 5:11:57 PM Subject: Re: IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds On Mon, Mar 15, 2010 at 4:22 PM, William Traenkle <will.traenkle(a)yahoo.com> wrote: When a hunt group is accessed from the main IVR, the hunt group dials >an internal extension via correctly but when trying to dial an >external number such a cell phone via sip uri it is unable to connect >or ring the cell phone and it waits the correct timeout period before it >goes to voicemail. > >However, if you dial the hunt group directly without going through the main IVR, the external number such as cell phone that uses sip uri to connect to it work perfect. > > > >>There is only an issue when the hunt group is accessed from the main IVR when dialing an external number using sip uri. > >>1) fs_cli output for successful call scenario directly to x7000 hunt group: http://pastebin.com/Q1ayXkNR > >>2) fs_cli output for failed call scenario x5002 IVR to x7000 hunt group: http://pastebin.com/FaxuGdJ3 In #2 your call to 7000 is hitting the public context. Most likely this isn't what you were anticipating. Try handling 7000 in the public context. Find the public_extensions dp entry and update your regex there: <condition field="destination_number" expression="^(10[01][0-9]|7000)$"> reloadxml and try again. If it works then consider creating a public context extension that specifically handles these calls, perhaps checking the IP address of the source of the call. -MC > >>3) autoattendant_5002.js script: http://pastebin.com/FaxuGdJ3 > >>4) huntgroup_7000.js script: http://pastebin.com/wNX9K7Ab > > >5) Dialplan default.xml: >http://pastebin.com/iAbNSW9E > >If you require additional information or have any other >questions, please let me know. > >>Thanks, > >>-Will > ________________________________ From: Michael Collins <msc(a)freeswitch.org> >To: freeswitch-users(a)lists.freeswitch.org >Sent: Tue, March 9, 2010 11:00:53 PM >Subject: Re: [Freeswitch-users] IVR to hunt group to external destination fails // direct to hunt group to external desitnation succeeds > > > > >On Tue, Mar 9, 2010 at 9:55 PM, William Traenkle <will.traenkle(a)yahoo.com> wrote: > >When a hunt group is accessed from the main IVR, the hunt group dials an internal extension via transfer correctly but when trying to dial an external number such a cell phone via sip uri it is unable to connect or ring the phone but it waits the correct timeout period before it goes to voicemail. >> >>However, if you access the hunt group directly without going through the main IVR, all works perfectly. >> >>Any ideas where I should look and what line of code I might be missing? >> >> > >Start by capturing the fs_cli debug output for the IVR call. Look through the debug lines for clues as to what is happening with your call. The symptom "unable to connect" has many possible causes, so try to locate the debug lines leading up to the attempt to bridge the SIP URI. If you want community help then pastebin the full debug log plus the relevant XML: the dialplan extension and the IVR definition. >> >-MC > > >

2 1

voicemail options
by Madovsky 16 Mar '10

16 Mar '10

Hi all, is there any way to set the voicemail for leave a message without any option at the end ? like record or send the message by email once the caller hangs up or after N sec of silence. Thanks Franck

5 20

Re: [Freeswitch-users] Set/Export channel variable [SOLVED]
by Ahmed Ajmal 16 Mar '10

16 Mar '10

So it seems that the FS console by default only displays the 'a' leg vars which is why I couldn't see it (and it makes sense too since gateway is on the b leg side). I have the ESL script now display both the inbound/outbound after which I can see the sip_gateway_name var. -ahmed From: freeswitch-users-bounces(a)lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Ahmed Ajmal Sent: Tuesday, March 16, 2010 10:42 AM To: freeswitch-users(a)lists.freeswitch.org Subject: Re: [Freeswitch-users] Set/Export channel variable I am looking at the FS console after hangup is complete. I also have a ESL event hooked up for HANGUP_COMPLETE event. In both cases I am unable to see the sip_gateway_name variable. -ahmed From: freeswitch-users-bounces(a)lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Michael Collins Sent: Monday, March 15, 2010 11:29 PM To: freeswitch-users(a)lists.freeswitch.org Subject: Re: [Freeswitch-users] Set/Export channel variable On Mon, Mar 15, 2010 at 6:50 AM, Ahmed Ajmal <ahmed.ajmal(a)breezecom.ae> wrote: Hi I have now configured the gateways as suggested below but I am not able to see the sip_gateway_name variable when the call hangup event is complete. I am on Freeswitch 1.0.5. Where are you looking to find the variable? -MC

1 0

Re: [Freeswitch-users] Set/Export channel variable
by Michael Collins 16 Mar '10

16 Mar '10

On Mon, Mar 15, 2010 at 6:50 AM, Ahmed Ajmal <ahmed.ajmal(a)breezecom.ae>wrote: > Hi > > > > I have now configured the gateways as suggested below but I am not able to > see the sip_gateway_name variable when the call hangup event is complete. I > am on Freeswitch 1.0.5. > > > Where are you looking to find the variable? -MC

2 1

voicemail message "saved" error
by Madovsky 16 Mar '10

16 Mar '10

Hi, 2010-03-16 00:44:27.878289 [WARNING] switch_ivr_play_say.c:339 Macro [voicemail_ack]: 'saved' did not match any patterns sh: line 1: 30667 Done /bin/cat /tmp/mail.126871466794cf 30668 Segmentation fault | sendmail -f infos(a)bibi.baba -t other(a)kiki.coco Thanks F

2 1

Switch with External SoftPhone
by Vladimir Elizarov 16 Mar '10

16 Mar '10

Hello. What are the ways connect external users to the fs there? In such a scheme: fs with real ip <-> internet <-> nat <-> sip-phone I read the topic http://wiki.freeswitch.org/wiki/External_profile # Switch_with_External_SoftPhone I did not understand several things: - That should be in exteranl5090.xml? Whole profile external.xml c changes in paragraphs 2,3? - Sofia/external5090 / <caller extension> @ xxxx: 5090 <- "What goes in xxxx? External UA IP? Domain?" I have the same question. that x.x.x.x should be? But this seems not quite what I need. Must be external to the subscriber is practically no different from internal. -- Best regards, Vladimir Elizarov

3 3