July 2011 - FreeSWITCH-users - FreeSWITCH Mailing Lists

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

Pizza Demo Grammar
by Bryan Smart 22 Jul '11

22 Jul '11

Hi. Trying to install the Pizza demo. The Wiki says to download the grammar from www.bkw.org, but that entire site seems to be down. Are these files available somewhere else? I tried to find them with Google, but only found references to the Wiki page and references to it in FS updates. Thanks Bryan

4 3

DTMF conversion / regeneration with bind_digit_action ?
by Dmitry Sytchev 22 Jul '11

22 Jul '11

Hi All DTMF troubles again :( We are trying to use Linksys PAP2T / SPA8000 with FS on internal profile and Audiocodes Mediant 2000 as gateway on external. When ATAs set to RFC2833 and proxy media is set on both profiles, everything works fine. We get RFC2833 on both sides. If we turn proxy media off to use freeswitch DTMF features like attended transfer by *7 or another in-call DTMF features, things go worse. PAP2T/SPA8000 convert inband DTMF from phone to RFC2833, but there are some inband clips still coming into audio channel. Freeswitch processes RFC2833 as dtmf-type set to 2833 in internal profile, but since we use bind_digit_action, little inband clip of DTMF gets to other side earlier than regenerated 2833, which is delayed by FS in bind_digit_action / bind_meta_app. BTW, bind_meta_app introduces less delay than bind_digit_action. As the result, after media goes through mediant2000, on PSTN side we have double DTMF - little inband clip and generated RFC2833 with really big gap between them. If some local transfers has been done via internal sip profile, more channels are linked in chain, so delay gets even bigger. When we set DTMF to inband on ATAs and internal profile dtmf-type is set to inband, freeswitch detects inband and in-call features work, but after passing inband DTMF through, FS for some reason also generates RFC2833 on external profile, and then Mediant passes inband part and re-generates rfc2833 DTMF part to PSTN. Again, double DTMF on PSTN side :( Can inband <-> rfc2833 conversion be done on FS side with inband DTMF suppression? And what can be done with in-call DTMF detection functions to make FS pass rfc2833 through as fast as it receives it without delay to make no gap between inband clips and regenerated DTMF? I really appreciate any help. I'm trying to handle this in different ways for two month with no result :( -- Best regards, Dmitry Sytchev, IT Engineer

2 1

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> Any help would be appreciated. Darcy Primrose The VoIP Highway

1 0

Complete wholesale app in freeswitch
by David Villasmil 21 Jul '11

21 Jul '11

Hello Guys, I'm finishing a "complete" wholesale application created on freeswitch and I was wondering whether it would be a good idea to put it up on the wiki. I just don't know how. Features include all the following parameters configurable via web interface: - Profile creation based on server IP where traffic is received. You can have multiple IPs, system will create multiple profiles/diaplans so it can differentiate. - i.e. offer to the same customer a "gold" routing on IP1 and cheap routing on IP2 - Customer add/modify/delete - IP source - Rates for client routes based on areacode - Prepaid or postpaid. - When cutomer balance is 0, no more calls are allowed. - limit max channels - Media by-pass - When by-passed, customer and provider will exchange RTPs directly. Else, server will be in the middle. - Provider add/modify/delete - costs for provider routes based on areacode - limit max channels - Routing based on areacode, gives great granularity. - Routes can be assigned multiple gateways/providers which can in turn be distributed based on weigth. Includes overflow to next configured GW. - Basic financial report generation (totals) by customer/provider - Basic traffic ASR/ACD report (totals) by cutomer/provider - Basic user administration. (No access level, only total access) - CDR export to csv file. I also have a prepaid card app... no web interface on that one though... Thanks all David

22 55