- FreeSWITCH-users - FreeSWITCH Mailing Lists

FreeSWITCH Friday BugHunt Reminder!
by Ken Rice 20 Jun '14

20 Jun '14

FreeSWITCHers, Do not forget to join us at 2PM CST for the FreeSWITCH Friday BugHunt Call sip:888@conference.freeswitch.org or see http://ift.tt/1prwIZL for access info! -- Ken http://ift.tt/vGSsGm http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH @ClueCon

1 0

From header in SIP DID calls
by Bruckner Andreas (OeRK-W) 20 Jun '14

20 Jun '14

Hey guys, we have two freeswitch instances running, connected to each other via a gateway configuration (without registering). The scenario is the following: [ SIP phone 1 ] <==> [ freeswitch1 ] extension 1000 ^ | v [ SIP phone 2 ] <==> [ freeswitch2 ] extension 1000 The gateway config looks as follows: <gateway name="freeswitch2"> <param name="username" value="1005"/> <param name="password" value="1234"/> <param name="realm" value="<IP of freeswitch 2>"/> <param name="register" value="false"/> <param name="caller-id-in-from" value="true"/> </gateway> For phone 1, to reach phone 2 there is an extension 881000, forwarding the call via the gateway to freeswitch 2. Phone 2 can reach phone 1 via 991000. The extension configuration is <extension name="freeswitch2-outbound"> <condition field="destination_number" expression="^88(\d{4})$"> <action application="set" data="effective_caller_id_number=99${caller_id_number}"/> <action application="set" data="effective_caller_id_name=FS1 ${caller_id_number}"/> <action application="bridge" data="sofia/gateway/freeswitch2/$1"/> </condition> </extension> On the opposite side, the extension in the public context is <extension name="public_extensions"> <condition field="destination_number" expression="^(10[01][0-9])$"> <action application="transfer" data="$1 XML default"/> </condition> </extension> and the extension bridging the call to the phone in the default context is <extension name="extension1000"> <condition field="destination_number" expression="^1000$"> <action application="info" /> <action application="bridge" data="user/1000"/> </condition> </extension> What we want to achieve is that when 1000@freeswitch1 calls 1000@freeswitch2 (by dialing extension 881000), phone 2 should display "FS1 1000" and calling back shoud call 991000@freeswitch1. However, phone 2 displays "Extension 1005" and the SIP From field contains 1005@<IP of freeswitch 1> instead of the expected 991000@<IP of freeswitch 1> We captured the network traffic between the gateways and between freeswitch2 and phone 2 and discovered that the SIP From field is set correctly between freeswitch1 and freeswitch2 (991000@<IP of freeswitch 1>), but is set to 1005@<IP of freeswitch2> between freeswitch2 and phone 2. Where does this happen and what do we have to change in the configuration in order to prevent freeswitch2 from changing this? Thanks in advance Andreas

1 0

Freeswitch Week in Review(Master Branch) June 1st-14th
by Kathleen King 20 Jun '14

20 Jun '14

Hello, again. This passed two weeks in the FreeSWITCH master branch we had 65 commits. These passed two weeks some new features have been added! A new log-uuid-short option was added to fs_cli, added stereo capabilities of Freeswitch, and this week saw the addition of a new module called mod_verto! You can test the new module and stereo capabilities by using headphones to play with the sound and following the link below using Chrome. Make a call into a conference at 3500, hear some funny prompts at 9386, or 3d1 to hear a 3D sound demo! https://webrtc.freeswitch.org/verto/verto.html#page-main Mod_verto is a signaling protocol that is used to simplify coding and implementing calls from web browsers and various devices to Freeswitch. More information about this new module can be found here: https://confluence.freeswitch.org/display/FREESWITCH/mod_verto And the stereo capabilities can be seen in the commits 928a989 and 4e5ecdf. The following bugs were squashed: 3ab1044 FS-6562 --resolve fixed event not firing for SIP message username prefixed with '+' in mod_sofia Jira: http://jira.freeswitch.org/browse/FS-6562 3549488 Fixed a problem in FAX where a received handshake, delayed so much it is received as we queue a retry, causes the retry frame to remain queued in the HDLC entity. 0685027 fixed a bug that was causing WSS to disconnect randomly in libsofia Jira: http://jira.freeswitch.org/browse/FS-6574 280e816 FS-6590 fixed stereo files audio issue in mod_shout Jira: http://jira.freeswitch.org/browse/FS-6590 c82ac3a FS-6535 fix double lock on speech detection failure in mod_rayo Jira: http://jira.freeswitch.org/browse/FS-6535 bb6869b FS-6535 allow multiple grammars (including dtmf) when using unimrcp in mod_rayo Jira: http://jira.freeswitch.org/browse/FS-6535 9e600ec FS-6591 --resolve If you are still using spidermonkey you should migrate to v8 Jira: http://jira.freeswitch.org/browse/FS-6591 New features that were added: 49ee678 FS-6540 Adding proxy refer replaces please test Jira: http://jira.freeswitch.org/browse/FS-6540 c015013 Add log-uuid-short option to fs_cli 928a989 the first pass for adding stereo support for FS 1ffb1ee WIP on the addition of a new module called mod_verto c0e7e7b add reset function to clear some state data in the rtp session in switch_rtp 94ab52c Improved FAX disconnect handling in spandsp 33541dc add logging to mod_verto 4e5ecdf setting plc to only run on mono channels 9108a08 fixing the build for mod_verto 31a181a implement digit timeout for dialing in mod_skinny 12da85e Check for execv(3) errors when reincarnating 7f36607 verto default config for mod_verto bfaf20c fix install for mod_verto Improvements in cross platform build supports: ab5278c stereo: fix mod_flite, mod_ssml, mod_unimrcp compile errors 97cc089 fix compile errs in mod_conference 09ae3a9 don't require more libs than we really need when linking embedded perl modules a607c20 Windows fix for commit a0e9ddf58943171a9031159919e99ef20147a11e in esl_config 9aa5102 FS-6535 fixed a compiler error in mod_rayo Jira: http://jira.freeswitch.org/browse/FS-6535 43770aa fixed the building of libldns in Windows Jira: http://jira.freeswitch.org/browse/FS-6583 In terms of stability these were the use cases that were fixed: fc7a749 Various little memory leak possibilities in spandsp sorts, and the spandsp test suite is now mostly OK with valgrind 148c21c FS-477 fix leaked lock in mod_skinny Jira: http://jira.freeswitch.org/browse/FS-477 Feedback is welcome at kathleen.king(a)quentustech.com and the commits for this week are in the attached file along with the corresponding Jira links. -- Kathleen King Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (877) 211-9337 Cell: (703) 859-3757 kathleen.king(a)quentustech.com

2 2

Re: [Freeswitch-users] Freeswitch seems to be giving conflicting timestamps - what's the deal here?
by Phil Quesinberry 19 Jun '14

19 Jun '14

I have no idea how to reply to these messages and have them come up in the same thread, I was using Nabble to do it but they don't appear to be getting updated messages now... Thanks for clearing that up! I hadn't seen that before, the server had recently been rebooted so I'm guessing that it pulled the BIOS time before NTP had a chance to update the clock. - Phil _____________________________________________ From: Phil Quesinberry Sent: Tuesday, June 17, 2014 1:11 PM To: 'freeswitch-users(a)lists.freeswitch.org' Subject: Freeswitch seems to be giving conflicting timestamps - what's the deal here? Looking into an intermittent problem that we're having with one of our DIDs, I just noticed that some of the logged timestamps don't seem to make sense, it's like there are two different clocks at work here. What's interesting is that I'm seeing this wrong time in received contact header info as well but I'm guessing that's coming back to us from our own NTP timestamp in the SDP we send back to them after the initial invite. The system time is set correctly. Here is a short excerpt of the console log with siptrace enabled on the external profile demonstrating this behavior: recv 939 bytes from udp/[209.216.2.202]:5060 at 16:10:58.987966: ------------------------------------------------------------------------ INVITE sip:1410xxx7612@173.59.xxx.xxx:5080;transport=udp SIP/2.0 Via: SIP/2.0/UDP 209.216.2.202:5060;branch=z9hG4bK68239f89;rport From: "+1410xxx3048" <sip:+1410xxx3048@209.216.2.202>;tag=as0e92c0c82014-06-17 12:07:58.767052 [DEBUG] switch_core_session.c:1034 Send signal sofia/external/+1410xxx3048(a)209.216.2.202 [BREAK] To: <sip:1410xxx7612@voip.ourdomain.com:5080>;tag=Hj722eXX0yj8S Contact: <sip:+1410xxx3048@209.216.2.202>2014-06-17 12:07:58.767052 [DEBUG] switch_core_session.c:1034 Send signal sofia/external/+1410xxx3048(a)209.216.2.202 [BREAK] Call-ID: 63cd75ae5caa77be67d5a6944e86f5fe(a)209.216.2.202 CSeq: 103 INVITE User-Agent: DidForSale-GW Max-Forwards: 70 Remote-Party-ID: "+1410xxx3048" <sip:+1410xxx3048@209.216.2.202>;privacy=off;screen=no Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 289 v=0 o=root 2802 2803 IN IP4 207.223.69.137 s=session c=IN IP4 207.223.69.137 t=0 0 m=audio 51480 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - ------------------------------------------------------------------------ send 405 bytes to udp/[209.216.2.202]:5060 at 16:10:58.988281: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 209.216.2.202:5060;branch=z9hG4bK68239f89;rport=5060 From: "+1410xxx3048" <sip:+1410xxx3048@209.216.2.202>;tag=as0e92c0c8 To: <sip:1410xxx7612@voip.ourdomain.com:5080>;tag=Hj722eXX0yj8S Call-ID: 63cd75ae5caa77be67d5a6944e86f5fe(a)209.216.2.202 CSeq: 103 INVITE User-Agent: FreeSWITCH-mod_sofia/1.5.6b+git~20131022T212715Z~20a55d3cc6 Content-Length: 0 ------------------------------------------------------------------------ 2014-06-17 12:07:58.787035 [DEBUG] sofia.c:5863 Channel sofia/external/+1410xxx3048(a)209.216.2.202 entering state [ready][200] 2014-06-17 12:07:58.787035 [DEBUG] sofia.c:5863 Channel sofia/external/+1410xxx3048(a)209.216.2.202 entering state [received][100] 2014-06-17 12:07:58.787035 [DEBUG] sofia.c:5873 Remote SDP: v=0 o=root 2802 2803 IN IP4 207.223.69.137 s=session c=IN IP4 207.223.69.137 t=0 0 m=audio 51480 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - 2014-06-17 12:07:58.787035 [DEBUG] switch_core_media.c:2990 Audio Codec Compare [PCMU:0:8000:20:64000]/[PCMU:0:8000:20:64000] 2014-06-17 12:07:58.787035 [DEBUG] switch_core_media.c:1879 Already using PCMU 2014-06-17 12:07:58.787035 [DEBUG] switch_core_media.c:3161 Set 2833 dtmf send/recv payload to 101 Is this expected behavior or is this a bug in the version we're using? Thanks. Phil Quesinberry Q Systems Engineering, Inc. Embedded Hardware and Software Development (410) 969-8002 http://www.qsystemsengineering.com <http://www.qsystemsengineering.com/>

1 0

SIP 500 overlappting requests
by Phil Quesinberry 19 Jun '14

19 Jun '14

We're having intermittent problems receiving calls from a particular DID. The basic scenario is as follows: Carrier sends invite w/SDP We respond w/OK and SDP when call is answered Carrier sends another invite with incremented sequence number and updated SDP (aren't they supposed to ACK/respond before doing this?) We send SIP 500 - overlapping requests Carrier sends BYE - terminating the call Sometimes (rarely) the call completes, most of the time FS sends a 500 and doesn't get the call. This just started happening recently and does not occur with any other DIDs, including other DIDs from the same carrier. I updated to the latest stable GIT to see if that might solve the problem but I'm pretty sure this is on the carrier's end. They're trying to blame it on us since we're sending the 500 and suggested that we allow overlapping requests. I'm assuming that their end needs to acknowledge our answer OK/SDP before sending their own but if that's the problem then it raises another question in my mind: since the SIP transport is generally UDP, what if we don't receive their ACK before receiving their subsequent invite/SDP? This could certainly happen and would cause the call to be rejected if the above is true. I updated to the latest stable GIT last night to rule that out as a possible cause of the problem. Is there a way to get FS to allow a limited number of overlapping requests as a possible workaround? If someone thinks this looks like it could be an FS bug, I'll file a Jira. Here is a trace which shows this happening: http://pastebin.freeswitch.org/22769 Thanks, Phil Quesinberry Q Systems Engineering, Inc. Embedded Hardware/Software Development (410) 969-8002 http://www.qsystemsengineering.com <http://www.qsystemsengineering.com/>

1 0

BLF no longer display actual registration status of phones
by Nandy Dagondon 19 Jun '14

19 Jun '14

We have a problem in BLF indicators - disconnected phones still show as registered (solid green) in the displays. It's an Atcom AT640P phone but it worked before. FS version 1.2.13 64-bit on CentOS 6 2.6.32. How can I trace the problem? ESL, databases, etc. Thanks for any help/hint. Note: Please ignore my earlier post re "BLF Troubleshooting" because this is the real issue. /Nandy

3 4

Can not find hangup log in the freeswitch logs
by rockxsj 19 Jun '14

19 Jun '14

Hi,I notice that the cdr is less than my expect.So I look up the logs of freeswitch,and I find some call did not get into CS_DESTROY state,the two legs of the call is below: fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.480500 [NOTICE] switch_channel.c:1053 New Channel sofia/internal/4000001234(a)sip.whoknowme.cn [4d57ac06-52fa-4ef5-956c-c1cc1db8ad40] fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.600479 [INFO] mod_dialplan_xml.c:558 Processing GY%B3%E0%C1%FA <4000001234>->018876590253 in context default fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [WARNING] switch_core_media.c:2548 NO candidate ACL defined, Defaulting to wan.auto fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 1 proto: udp type: host addr: 192.168.155.1:56436 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 2 proto: udp type: host addr: 192.168.155.1:56436 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 1 proto: udp type: host addr: 192.168.1.2:56437 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 2 proto: udp type: host addr: 192.168.1.2:56437 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2581 Choose audio Candidate cid: 1 proto: udp type: srflx addr: 120.32.104.13:9115 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2581 Choose audio Candidate cid: 2 proto: udp type: srflx addr: 120.32.104.13:9115 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 1 proto: udp type: srflx addr: 120.32.104.13:9117 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2586 Save audio Candidate cid: 2 proto: udp type: srflx addr: 120.32.104.13:9117 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2710 setting remote audio ice addr to 120.32.104.13:9115 based on candidate fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_core_media.c:2730 setting remote rtcp audio addr to 120.32.104.13:9115 based on candidate fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [INFO] switch_core_media.c:5016 Activating Audio ICE fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [NOTICE] switch_rtp.c:3775 Activating RTP audio ICE: gdzTwX2PR4YWwRvr:Qr3qnaiYtrc9YirV 120.32.104.13:9115 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [INFO] switch_core_media.c:5059 Activating RTCP PORT 9115 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.780497 [INFO] switch_core_media.c:5067 Skipping RTCP ICE (Same as RTP) fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.830486 [INFO] switch_rtp.c:3151 Activating Audio Secure RTP SEND fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.840496 [INFO] switch_rtp.c:3129 Activating Audio Secure RTP RECV fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:50.840496 [NOTICE] sofia_media.c:92 Pre-Answer sofia/internal/4000001234(a)sip.whoknowme.cn! fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:51.040498 [NOTICE] switch_rtp.c:1132 Auto Changing stun/rtp/dtls port from 120.32.104.13:9115 to 120.32.104.13:9117 fs.log.2014-05-28-00-00-01.1:4d57ac06-52fa-4ef5-956c-c1cc1db8ad40 2014-05-27 19:02:58.720594 [NOTICE] switch_ivr_bridge.c:496 Channel [sofia/internal/4000001234(a)sip.whoknowme.cn] has been answered fs.log.2014-05-28-00-00-01.1:2127f5f1-fa2d-469d-ad0a-8df709d484ec 2014-05-27 19:02:50.860494 [NOTICE] switch_channel.c:1053 New Channel sofia/internal/018876590253 [2127f5f1-fa2d-469d-ad0a-8df709d484ec] fs.log.2014-05-28-00-00-01.1:2127f5f1-fa2d-469d-ad0a-8df709d484ec 2014-05-27 19:02:51.570502 [NOTICE] sofia_media.c:92 Pre-Answer sofia/internal/018876590253! fs.log.2014-05-28-00-00-01.1:2127f5f1-fa2d-469d-ad0a-8df709d484ec 2014-05-27 19:02:58.700582 [NOTICE] sofia.c:6955 Channel [sofia/internal/018876590253] has been answered fs.log.2014-05-28-00-00-01.1:2127f5f1-fa2d-469d-ad0a-8df709d484ec 2014-05-27 19:04:32.330784 [WARNING] sofia.c:8096 IGNORE INFO DTMF(6) (This channel was not configured to use INFO DTMF!) Is this may be a bug?

1 0

Diversion header
by Chris Young 19 Jun '14

19 Jun '14

Hi all, We have a FreeSWITCH server connected to a Cisco UC560 which is using CUE for voicemail. We are experiencing problems with calls which are redirected to the voicemail system because the INVITE sent by FreeSWITCH does not contain the Diversion header present in the preceding 302 response. Is there something specific I need to configure to get this included? I've tried to set up manual redirection on the SIP profile, as per the wiki, so that I could export the header using sip_h_Diversion but it doesn't seem to be working - the call does not enter the 'redirected' context and continues to be processed internally. Is there another way of achieving this? Thanks, Chris Chris Young Software Engineer [cid:image737b08.PNG@6a440e0d.419a719a] t: +44 118 943 9249 e: Chris.Young(a)enghouse.com<mailto:Chris.Young@enghouse.com> w: www.enghouseinteractive.co.uk<http://www.enghouseinteractive.co.uk> [cid:image72f27b.PNG@7bde397e.49b56865]

2 2

Multiple SIP-registrations and leg-specific variables.
by Alex Lake 19 Jun '14

19 Jun '14

Got a situation where an extension has two phones registered, but my dialplan is a little too simplistic to handle: i.e my bridge string has something like this in it: [tenant_id=0024,b_ext=201,accept_mode=Direct,leg_timeout=15]${sofia_contact(0024312)}' But ${sofia_contact(0024312)} expands to "sofia/internal/sip:0024307@84.92.90.149:59031;transport=udp,sofia/internal/sip:0024307@37.157.38.162:51910" so the leg-specific parameters only affect the first registration. I suppose I could write something in Lua to work it all out properly, but it might be more elegant if there was something like this: [tenant_id=0024,b_ext=201,accept_mode=Direct,leg_timeout=15](${sofia_contact(0024312)}) Where the brackets mean to apply the [] parameters to anything that comes out of the expression. Is this available?!

2 3

freeswitch on wifi
by Shlomi Agiv 19 Jun '14

19 Jun '14

We intend to put freeswitch on an arm powered portable device, which will connect using a usb gsm stick and will serve as a wifi/gsm router so, a call will connect two endpoints - one to the sip client through wifi, the other through mod_gsmopen to the gsm. How will the voice quality be? which voice codec is most recommended?

4 5