- FreeSWITCH-users - FreeSWITCH Mailing Lists

Using chat command in a dialplan
by Kurtis Heimerl 23 Jul '11

23 Jul '11

I feel somewhat embarrassed, but I can't figure out how to cause a chat event to go off from the dialplan. I've tried: <action application="chat" data="sip|${username}|${destination_number}@${domain_name}|${msg_body}"/> and <action application="eval" data="chat sip|${username}|${destination_number}@${domain_name}|${msg_body}"/> and neither worked. The wiki says it's part of the API (http://wiki.freeswitch.org/wiki/Mod_dptools) but I'm pretty sure that's just a command-line API. Is there a way to run a command-line call from the dialplan? Any direction would be appreciated.

3 9

Call disconnect after transfer
by Mike Burlingame 23 Jul '11

23 Jul '11

I am having a small issue with calls getting disconnected after transfer from a customer signaling is posted at http://pastebin.freeswitch.org/16869 but basic call flow is call is sent to user - user answers - user transfer the call to another user - invite is sent to Freeswitch with out SDP - 200 OK provided to customer with SDP - ACK received from customer with SDP - Freeswitch disconnects call with [INCOMPATIBLE_DESTINATION] I have 3PCC enabled in FreeSwitch via sofia.conf.xml <param name="enable-3pcc" value="true"/>

1 1

ftmod_libPRI outgoing calls channel selection
by Michal Zubáč 23 Jul '11

23 Jul '11

Hi. I've noticed that outgoing call channels in freetdm/ftmod_libpri are not selected exclusively in Q.931 SETUP messages. Channel identification "exclusive" bit is 0 so it only means "preferred". In some cases freeswitch selected channel which was not ready for dialing yet and ISDN operator answered with another channel in PROGRESS message. So actual call state messages were passed trough another channel and it resulted with lots of VETO and consecutive RESET messages, because of channel state confusion in FreeSwitch. I think that it's better to force channel selection and in some cases choose wrong channel and get info about it. It's definitely better, then choose something, assume that it is correct although actual communication is done on another channel and such calls are "doomed"... I've attached patch, in which we force selection of ISDN channel. Maybe better solution will be some configuration variable, which will control this behaviour. Consider. Does anybody have similar experience and if so, how do you deal with it? Or am I mistaken in some of my conclusions? -- Michal Zubac ComGate Interactive s.r.o. Prague Marina Office Center Jankovcova 1596/14a 17000 Praha 7, Czech Republic

2 1

Can't get fax working
by Boris Kovalenko 23 Jul '11

23 Jul '11

Hello! I need help with fax configuration. My network is: PSTN E1 --- Cisco AS5350 -- Freeswitch -- Audiocodes MP-114 -- Fax FS version: FreeSWITCH Version 1.0.head (git-062f07f 2011-07-16 12-35-25 +0200) Audiocodes firmware: 6.00A.038.004 I can't get faxes working :( In FS profiles there is a parameter <param name="t38-passthru" value="true"/> Cisco DP fax settings: fax-relay ecm disable fax rate 9600 fax protocol t38 ls-redundancy 2 hs-redundancy 1 fallback pass-through g711alaw no vad On Audiocodes there is also T38 enabled (as I think) but there is no T38. There are messages on MP-114: ErrMgs=16 T38Decoder received Non-T38 Packet and || Modem Relay Is Not Supported! Forcing Bypass Mode Please, help! What information I need to collect to help solve the problem? -- Regards, Boris

5 13

SIP re-invite issue with session timers
by David Bolen 22 Jul '11

22 Jul '11

While testing some outbound T.38 fax calls, they were getting quickly disconnected, and I found that I was running into problems related to the session timer during the re-invite process. I was wondering if anyone else has run into anything similar? I'm not sure if it's just T.38 related, or would have occurred on any re-invite scenario. In the trace below, I think my gateway (Flowroute) reacts a little strangely since it appears to refuse a session timer that it itself chose during the initial invite process (instead seeming to want to flip who handles the refresh), but while odd, that's not necessarily invalid, is it? I also noticed that FreeSWITCH promoted the timer to a requirement during the re-invite. But the eventual call disconnect seems due to FreeSWITCH never completing renegotiation - the last thing it transmits is a 100 response. Disabling session timers (enable-timer=false) in the profile gets around the problem, but it seems like keeping the timers, if possible, is preferable in terms of an additional safety net. Any thoughts or suggestions would be welcome. Does this appear strictly a gateway side issue, or is something also not working properly on the FreeSWITCH side? -- David Note: git-b1d1beb is the same as f1de377 from 7/16 plus one local change to mod_conference. The dialed number has been replaced by 11111111111, my public switch address with 111.111.111.111, and I've excluded the Proxy-Authorization header throughout. The initial call setup seems ok: - - - - - - - - - - - - - - - - - - - - - - - - - send 1390 bytes to udp/[216.115.69.144]:5060 at 21:29:19.155730: ------------------------------------------------------------------------ INVITE sip:11111111111@sip.flowroute.com SIP/2.0 Via: SIP/2.0/UDP 111.111.111.111:5080;rport;branch=z9hG4bKK8mr3pcre4a2j Max-Forwards: 70 From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com> Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349016 INVITE Contact: <sip:gw+flowroute@111.111.111.111:5080;transport=udp;gw=flowroute> Expires: 600 User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-b1d1beb 2011-07-18 23-08-16 -0400 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 213 X-FS-Support: update_display Remote-Party-ID: <sip:0000000000@sip.flowroute.com>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1311342219 1311342220 IN IP4 111.111.111.111 s=FreeSWITCH c=IN IP4 111.111.111.111 t=0 0 m=audio 27940 RTP/AVP 9 0 8 3 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 ------------------------------------------------------------------------ recv 305 bytes from udp/[216.115.69.144]:5060 at 21:29:19.194573: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 111.111.111.111:5080;rport=5080;branch=z9hG4bKK8mr3pcre4a2j From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com> Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349016 INVITE Content-Length: 0 ------------------------------------------------------------------------ recv 687 bytes from udp/[216.115.69.144]:5060 at 21:29:19.839258: ------------------------------------------------------------------------ SIP/2.0 180 Ringing From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Via: SIP/2.0/UDP 111.111.111.111:5080;rport=5080;branch=z9hG4bKK8mr3pcre4a2j Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349016 INVITE Record-Route: <sip:216.115.69.133;lr> Record-Route: <sip:216.115.69.144;lr> Contact: <sip:+11111111111@67.16.125.60:5060;transport=udp> Content-Length: 184 Content-Type: application/sdp v=0 o=- 3829 19246 IN IP4 67.16.125.60 s=- c=IN IP4 67.16.125.60 t=0 0 m=audio 50330 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=maxptime:20 ------------------------------------------------------------------------ recv 850 bytes from udp/[216.115.69.144]:5060 at 21:29:21.587130: ------------------------------------------------------------------------ SIP/2.0 200 OK From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Via: SIP/2.0/UDP 111.111.111.111:5080;rport=5080;branch=z9hG4bKK8mr3pcre4a2j Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349016 INVITE Record-Route: <sip:216.115.69.133;lr> Record-Route: <sip:216.115.69.144;lr> Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: <sip:+11111111111@67.16.125.60:5060;transport=udp> Supported: timer,replaces Session-Expires: 10800;refresher=uas Content-Length: 184 Content-Type: application/sdp v=0 o=- 3829 19246 IN IP4 67.16.125.60 s=- c=IN IP4 67.16.125.60 t=0 0 m=audio 50330 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=maxptime:20 ------------------------------------------------------------------------ send 826 bytes to udp/[216.115.69.144]:5060 at 21:29:21.587678: ------------------------------------------------------------------------ ACK sip:+11111111111@67.16.125.60:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 111.111.111.111:5080;rport;branch=z9hG4bKmHeH5HXUBD1me Route: <sip:216.115.69.144;lr> Route: <sip:216.115.69.133;lr> Max-Forwards: 70 From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349016 ACK Contact: <sip:gw+flowroute@111.111.111.111:5080;transport=udp;gw=flowroute> Content-Length: 0 ------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - - - - - - - - - The gateway appears to have specified a uas-refreshed session timer in its 200 message. Below, the re-invite happens for T.38. Here I noticed the new Require: timer option (with the session-expires from before), which is rejected, then oddly the gateway re-invites but apparently with a uac-refreshed timer. FreeSWITCH then sends a 100, and nothing else. - - - - - - - - - - - - - - - - - - - - - - - - - send 1638 bytes to udp/[216.115.69.144]:5060 at 21:29:22.108341: ------------------------------------------------------------------------ INVITE sip:+11111111111@67.16.125.60:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 111.111.111.111:5080;rport;branch=z9hG4bKNt796ceZ8NQ7S Route: <sip:216.115.69.144;lr> Route: <sip:216.115.69.133;lr> Max-Forwards: 70 From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349017 INVITE Contact: <sip:gw+flowroute@111.111.111.111:5080;transport=udp;gw=flowroute> User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-b1d1beb 2011-07-18 23-08-16 -0400 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Require: timer Supported: timer, precondition, path, replaces Session-Expires: 10800;refresher=uas Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 322 X-FS-Support: update_display Remote-Party-ID: <sip:0000000000@sip.flowroute.com>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1311342219 1311342221 IN IP4 111.111.111.111 s=FreeSWITCH c=IN IP4 111.111.111.111 t=0 0 m=image 27940 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:2000 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ recv 330 bytes from udp/[216.115.69.144]:5060 at 21:29:22.147343: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 111.111.111.111:5080;rport=5080;branch=z9hG4bKNt796ceZ8NQ7S From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349017 INVITE Content-Length: 0 ------------------------------------------------------------------------ recv 338 bytes from udp/[216.115.69.144]:5060 at 21:29:22.170802: ------------------------------------------------------------------------ SIP/2.0 420 Bad Extension From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Via: SIP/2.0/UDP 111.111.111.111:5080;rport=5080;branch=z9hG4bKNt796ceZ8NQ7S Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349017 INVITE Unsupported: timer ------------------------------------------------------------------------ send 446 bytes to udp/[216.115.69.144]:5060 at 21:29:22.171034: ------------------------------------------------------------------------ ACK sip:+11111111111@67.16.125.60:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 111.111.111.111:5080;rport;branch=z9hG4bKNt796ceZ8NQ7S Route: <sip:216.115.69.144;lr> Route: <sip:216.115.69.133;lr> Max-Forwards: 70 From: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS To: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 15349017 ACK Content-Length: 0 ------------------------------------------------------------------------ recv 1160 bytes from udp/[216.115.69.144]:5060 at 21:29:26.533911: ------------------------------------------------------------------------ INVITE sip:gw+flowroute@111.111.111.111:5080;transport=udp;gw=flowroute SIP/2.0 Record-Route: <sip:216.115.69.144;lr> Record-Route: <sip:216.115.69.133;lr> From: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821;tag=SDvtmh399-gK0a9c4821 To: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK1dbe.2add7494aaa097ffa4b75892aba82f61.0 Via: SIP/2.0/UDP 216.115.69.133;branch=z9hG4bK1dbe.bbcd1cf6f99ecd7a297b5dc33dd676dd.0 Via: SIP/2.0/UDP 67.16.125.60:5060;branch=z9hG4bKmthalp308g505g83r340sb0000hc3.1 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 4313 INVITE Max-Forwards: 67 Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed Contact: <sip:+11111111111@67.16.125.60:5060;transport=udp> Supported: timer,replaces Session-Expires: 10800;refresher=uac Min-SE: 90 Content-Length: 172 Content-Type: application/sdp v=0 o=- 3829 19247 IN IP4 67.16.125.60 s=- c=IN IP4 67.16.125.60 t=0 0 m=image 50330 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ------------------------------------------------------------------------ send 688 bytes to udp/[216.115.69.144]:5060 at 21:29:26.534587: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bK1dbe.2add7494aaa097ffa4b75892aba82f61.0 Via: SIP/2.0/UDP 216.115.69.133;branch=z9hG4bK1dbe.bbcd1cf6f99ecd7a297b5dc33dd676dd.0 Via: SIP/2.0/UDP 67.16.125.60:5060;branch=z9hG4bKmthalp308g505g83r340sb0000hc3.1 Record-Route: <sip:216.115.69.144;lr> Record-Route: <sip:216.115.69.133;lr> From: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821;tag=SDvtmh399-gK0a9c4821 To: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 4313 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-b1d1beb 2011-07-18 23-08-16 -0400 Content-Length: 0 ------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - - - - - - - - - At this point the fax actually proceeds for a few seconds, but I get a BYE after about 10 seconds: - - - - - - - - - - - - - - - - - - - - - - - - - recv 708 bytes from udp/[216.115.69.144]:5060 at 21:29:36.285179: ------------------------------------------------------------------------ BYE sip:gw+flowroute@111.111.111.111:5080;transport=udp;gw=flowroute SIP/2.0 Record-Route: <sip:216.115.69.144;lr> Record-Route: <sip:216.115.69.133;lr> From: <sip:11111111111@sip.flowroute.com>;tag=SDvtmh399-gK0a9c4821;tag=SDvtmh399-gK0a9c4821 To: "" <sip:XXXX@sip.flowroute.com;transport=udp>;tag=KcKN11gj6arQS Via: SIP/2.0/UDP 216.115.69.144;branch=z9hG4bKecbe.d96adce16997b042396d38106987a638.0 Via: SIP/2.0/UDP 216.115.69.133;branch=z9hG4bKecbe.75fcc1a3bc1f3a68e4c0241e8b6b0298.0 Via: SIP/2.0/UDP 67.16.125.60:5060;branch=z9hG4bKmthalp308g505g83r340sd00001d3.1 Call-ID: 7fe743c9-2f4c-122f-9790-f23c91931894 CSeq: 4314 BYE Max-Forwards: 67 Content-Length: 0 ------------------------------------------------------------------------ - - - - - - - - - - - - - - - - - - - - - - - - -

1 0

Dingaling/Gtalk hangup problem
by yahoo2003 22 Jul '11

22 Jul '11

We have been troubleshooting Dingaling/Gtalk hangup problem for a week, the problem is: If A using FS->Gtalk to make calls and hangup before B is answered, B will continue to ring until either B times out or Google times out in 2 minutes. If B is answered, A can hangup correctly (ACTIVE->HANGUP). The problem is only for RING->HANGUP. I tried Windows and Linux version of FS, they behaved the same way. Asterisk Gtalk hangs up correctly. The "client.xml" I used was: <include> <profile type="client"> </profile> </include> Any suggestions are appreciated. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Dingaling-Gtalk-hangup-proble… Sent from the freeswitch-users mailing list archive at Nabble.com.

1 0

bridge_answer_timeout with no audio
by Darcy 22 Jul '11

22 Jul '11

Hello, I am having a problem with bridge_answer_timeout, also having email problems, hope this isn’t duplicated I included the dial plan below. This does timeout and it does transfer but there is no audio when it goes to either voice mail or an ivr. If it goes to another extension or pstn number, there is audio. The trace shows messages being played. I did a wireshark trace and it did not show any rtp going out after the bridge_answer_timeout. In the dial plan, 8205 goes to a dial plan that is the voice mail for extension 205 and if I dial 8205 direct it works. I have installed the latest git. <include> <extension name="205"> <condition field="destination_number" expression="^(205)$"> <action application="set" data="proxy_media=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=false"/> <action application="bridge" data="{bridge_answer_timeout=5}sofia/${use_profile}/16133429652(a)toronto2.voip.ms"/> <action application="transfer" data="8205 XML office.voiphwy.com"/> </condition> </extension> </include> I get the following from the timeout: 2011-07-22 12:34:13.013195 [DEBUG] switch_ivr_bridge.c:409 Answer timeout hit on sofia/internal/16133429652(a)toronto2.voip.ms. 2011-07-22 12:34:13.013195 [DEBUG] switch_channel.c:2739 (sofia/internal/16133429652(a)toronto2.voip.ms) Callstate Change EARLY -> HANGUP 2011-07-22 12:34:13.013195 [NOTICE] switch_ivr_bridge.c:410 Hangup sofia/internal/16133429652(a)toronto2.voip.ms [CS_EXCHANGE_MEDIA] [ALLOTTED_TIMEOUT] I see this which indicates the message is playing 2011-07-22 12:34:13.025050 [NOTICE] mod_dptools.c:930 Channel [sofia/internal/200(a)office.voiphwy.com] has been answered EXECUTE sofia/internal/200(a)office.voiphwy.com sleep(1000) 2011-07-22 12:34:13.036856 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.036856 [DEBUG] sofia.c:5086 Channel sofia/internal/200(a)office.voiphwy.com entering state [completed][200] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] sofia.c:5086 Channel sofia/internal/200(a)office.voiphwy.com entering state [ready][200] EXECUTE sofia/internal/200(a)office.voiphwy.com voicemail(default office.voiphwy.com 205) 2011-07-22 12:34:14.166175 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2011-07-22 12:34:14.180219 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[voicemail/vm-person.wav] (en:en) 2011-07-22 12:34:14.180219 [DEBUG] switch_ivr_play_say.c:1279 Codec Activated L16@8000hz 1 channels 20ms /lo2011-07-22 12:34:15.530174 [DEBUG] switch_ivr_play_say.c:1649 done playing file g2011-07-22 12:34:15.650171 [DEBUG] switch_ivr_play_say.c:244 Handle say:[205] (en:en) 2011-07-22 12:34:15.650171 [DEBUG] switch_ivr_play_say.c:1279 Codec Activated L16@8000hz 1 channels 20ms Any help would be appreciated. Darcy Primrose The VoIP Highway

1 0

bridge_answer_timeout problem
by VoIPHwy 22 Jul '11

22 Jul '11

Hello, I am having a problem with bridge_answer_timeout I included the dial plan below. This does timeout and it does transfer but there is no audio when it goes to either voice mail or an ivr. If it goes to another extension or pstn number, there is audio. The trace shows messages being played. I did a wireshark trace and it did not show any rtp going out after the bridge_answer_timeout. In the dial plan, 8205 goes to a dial plan that is the voice mail for extension 205 and if I dial 8205 direct it works. I have installed the latest git. <include> <extension name="205"> <condition field="destination_number" expression="^(205)$"> <action application="set" data="proxy_media=true"/> <action application="set" data="continue_on_fail=true"/> <action application="set" data="hangup_after_bridge=false"/> <action application="bridge" data="{bridge_answer_timeout=5}sofia/${use_profile}/16133429652(a)toronto2.voip.ms"/> <action application="transfer" data="8205 XML office.voiphwy.com"/> </condition> </extension> </include> I get the following from the timeout: 2011-07-22 12:34:13.013195 [DEBUG] switch_ivr_bridge.c:409 Answer timeout hit on sofia/internal/16133429652(a)toronto2.voip.ms. 2011-07-22 12:34:13.013195 [DEBUG] switch_channel.c:2739 (sofia/internal/16133429652(a)toronto2.voip.ms) Callstate Change EARLY -> HANGUP 2011-07-22 12:34:13.013195 [NOTICE] switch_ivr_bridge.c:410 Hangup sofia/internal/16133429652(a)toronto2.voip.ms [CS_EXCHANGE_MEDIA] [ALLOTTED_TIMEOUT] I see this which indicates the message is playing 2011-07-22 12:34:13.025050 [NOTICE] mod_dptools.c:930 Channel [sofia/internal/200(a)office.voiphwy.com] has been answered EXECUTE sofia/internal/200(a)office.voiphwy.com sleep(1000) 2011-07-22 12:34:13.036856 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.036856 [DEBUG] sofia.c:5086 Channel sofia/internal/200(a)office.voiphwy.com entering state [completed][200] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] switch_core_session.c:855 Send signal sofia/internal/200(a)office.voiphwy.com [BREAK] 2011-07-22 12:34:13.106193 [DEBUG] sofia.c:5086 Channel sofia/internal/200(a)office.voiphwy.com entering state [ready][200] EXECUTE sofia/internal/200(a)office.voiphwy.com voicemail(default office.voiphwy.com 205) 2011-07-22 12:34:14.166175 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2011-07-22 12:34:14.180219 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[voicemail/vm-person.wav] (en:en) 2011-07-22 12:34:14.180219 [DEBUG] switch_ivr_play_say.c:1279 Codec Activated L16@8000hz 1 channels 20ms /lo2011-07-22 12:34:15.530174 [DEBUG] switch_ivr_play_say.c:1649 done playing file g2011-07-22 12:34:15.650171 [DEBUG] switch_ivr_play_say.c:244 Handle say:[205] (en:en) 2011-07-22 12:34:15.650171 [DEBUG] switch_ivr_play_say.c:1279 Codec Activated L16@8000hz 1 channels 20ms Any help would be appreciated. Darcy Primrose The VoIP Highway

1 0

How to get call bridge status?
by Sam 22 Jul '11

22 Jul '11

I am writing a perl script that does a call bridge and I would like to know what is the status of the call bridge once the bridge application as finished execution. I am using the following but do not know if it is the correct way since on NO_ANSWER call states the sip code is blank, but shouldn't it return SIP:480 according to this http://wiki.freeswitch.org/wiki/Hangup_causes? $sipcode = $session->getVariable("proto_specific_hangup_cause");

2 2

rxfax on b-leg
by slash＠nat-tele.com 22 Jul '11

22 Jul '11

Hello guys! I wonder if there is a way to make rxfax recieve fax on outgoing call? The idea is that registered FS user dials out, than tone_detect is used to detect fax tone and start rxfax. The difference is that rxfax should be run on B-leg, instead of A-leg in incoming fax call scenario. I've tried to make a test config with outgoing call, rxfax & tone_detect, but when I dial out and remote user starts sending fax to me, FS detects a tone correctly, starts rxfax, but on my leg (A-leg, i hear fax tones) and B-leg (with real fax machine) is hanged up. Are there are solutions to explain somehow to rxfax that it should be run on B-leg, not on A-leg? Thanks in advance! With best regards, Kirill.

1 0