March 2014 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] Mistified by a registration issue
by Clive Lansink 18 Mar '14

18 Mar '14

Hello Brian and others. You ask some interesting questions which perhaps go beyond my level of knowledge. Freeswitch is running on Windows 7 and Windows Firewall is running. The only firewall rule I have set up for Freeswitch is that for public network addresses it will only accept packets from the IP address of our provider. We've never been actually hijacked by people looking for SIP servers to take advantage of, but at some stage I became aware from the logs that we were being bombarded by frequent registration and call attempts from the public internet. These attempts were all failing but this activity was chewing up a lot of our monthly data. So I put the firewall rule in to shield us from any such attempts other than from our VOIP provider. I'm pretty sure that is working correctly. People looking for SIP servers just don't see ours now - it is no longer visible. The only other player in this I think is the router itself. Routers can often act in misterious ways and I can't be sure that it isn't doing some sort of port translation. The only rule in place on the router is to forward UDP port 5060 to Freeswitch. After doing some further reading, it has occurred to me that my NAT settings are probably wrong. The registration packets I am sending to the provider reference our private 192.168 address and not our public IP address. The router must be manipulating that information in the register packet or the provider might not be able to respond. Having said that, I am aware that providers also get up to tricks to deal with NAT when it is clear the packet has come from an address different from the addresses in the packet headers. I'm afraid my brain starts to fry at this point. OK so what are the NAT settings? In the SIP profile external.xml, I think they are at their default settings, ie I don't think I have ever changed them. The parameter aggressive-nat-detection is commented out. ext-rtp-ip and ext-sip-ip are both set to auto-nat. Cheers. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 Fax: +64 21 789-150 -----Original message----- From: Brian West <brian(a)freeswitch.org> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Subject: Re: [Freeswitch-users] Mistified by a registration issue Reply-to: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Date: Sat, 15 Mar 2014 19:59:41 -0500 Firewall uname -a what CPU? What nat settings have you tried? Because youll notice on both the remote is receiving you from 5061 not 5060 as it should if your firewall is correctly configured. -- Brian West brian(a)freeswitch.org FreeSWITCH Solutions, LLC PO BOX 2531 Brookfield, WI 53008-2531 Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Mar 15, 2014, at 4:21 PM, Clive Lansink <clive(a)lansink.co.nz> wrote: > Hello listers. > > I have had Freeswitch running for quite some time now with few issues. But recently I installed a new router and came across this problem while configuring it. I have my Sofia external profile set to use port 5060 and my internal profile uses another port. So I followed my previous practice and set the router to forward UDP port 5060 to Freeswitch and that works properly. > I decided on this occasion that itmight be a good idea to also open up ports 16384-32768 so these are also forwarded to Freeswitch, as these are the RTP ports Freeswitch is set to use. I quickly found to my surprise that Freeswitch would fail to register with the external provider once I did this, but as soon as I stopped forwarding ports 16384-32768, Freeswitch would again register as it should. > > This seems really weird since I don't see how ports 16384-32768 can have any impact on the registration process on port 5060, and in any case whatever might be happening on these ports only involves Freeswitch so how can setting up such a port forwarding impact on registration. > > I would be pleased if anyone out there can answer this. > > I have included two SIP traces from the log. The first, trace1.txt, is the registration sequence when the ports are not forwarded. You can see Freeswitch sends a register, and the provider responds with an unauthorised which I think is the usual way it works. Freeswitch then responds with a register again and the provider responds with an ok. There are also some options packets in the sequence. So this is the regular pattern I see when Freeswitch is registered and remains registered. > > The second, trace2.txt, shows what happens when the ports 16384-32768 are set in the router to be forwarded to Freeswitch. Here we see Freeswitch sends a register packet, though it doesn't have the authentication information. I presume this is because at this point the gateway knows that it is not registered so this is like the first step in registering from scratch. Then we see the provider respond with an unauthorised message including (as before) the instruction for how to authenticate. But then Freeswitch doesn't respond with a follow-up attempt to register and eventually we see that it just reports that it timed out trying to register. > > I'm not a SIP expert but I don't see anything in the second dialog to explain why Freeswitch doesn't follow up to complete the registration even though it clearly does receive the unauthorised message with the authentication information. > > It would be great if someone could suggest what might be going on here. > > Thank you. > > > Clive Lansink > Email: Clive(a)Lansink.Co.NZ > Phone: +64 9 520-4242 > Mobile: +64 21 663-999 > Fax: +64 21 789-150 > <trace1.txt><trace2.txt>_________________________________________________________________________ > Professional FreeSWITCH Consulting Services: > consulting(a)freeswitch.org > http://www.freeswitchsolutions.com > > FreeSWITCH-powered IP PBX: The CudaTel Communication Server > http://www.cudatel.com > > Official FreeSWITCH Sites > http://www.freeswitch.org > http://wiki.freeswitch.org > http://www.cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

1 0

Re: [Freeswitch-users] Mistified by a registration issue
by Clive Lansink 18 Mar '14

18 Mar '14

Hello Sean and others. I am absolutely sure that all I have changed is the router setting that forwards UDP ports 16384-32768 to Freeswitch. The first SIP trace was without the port forwarding when Freeswitch happily remained registered to the provider. Then I just turned on the port forwarding and confirmed that within a few minutes the gateway had failed to register. Then I took the second trace from the log. In fact I didn't even restart Freeswitch. Then after taking the second trace, I turned off the port forwarding and noticed that within a few minutes the gateway had registered again. I changed nothing in Freeswitch in that time and in fact I didn't even restart it. You are right that the registration that fails does not include the authorisation information in the register packet. But I think that is normal behaviour when a user agent registers from scratch. Remember that at this point, the gateway has previously failed registration so is now not registered. But the "401 unauthorized" reply from the provider includes the header: WWW-Authenticate: Digest algorithm=MD5, realm="voip", nonce="3bf589ea" Freeswitch should immediately reply with another registration attempt that includes the authorization information, ie the provider has issued a challenge and Freeswitch should respond. But it doesn't respond. Instead what we see in the log is: 2014-03-16 08:10:10.197842 [NOTICE] sofia_reg.c:418 Registering outbound2 2014-03-16 08:11:11.197331 [WARNING] sofia_reg.c:454 Timeout Registering outbound2 2014-03-16 08:11:12.197388 [WARNING] sofia_reg.c:473 outbound2 Failed Registration [908], setting retry to 30 seconds. I can assure you both traces come from the same gateway (called outbound2) running in the same instance of Freeswitch with no configuration change and not even restarting Freeswitch in the interim. It is interesting to look at the first trace which is when Freeswitch registers correctly. You will see that the first register packet does include authorization information, but the provider responds with a "401 unauthorized" response. I presume this is because the authorization information provided in the first packet was valid for the previous registration but is now no longer vallid. So then we see Freeswitch immediately respond with a second register packet and then the provider sends back an OK response. The question is why does this not happen in the second trace when all I have done is forwarded UDP ports 16384-32768 to Freeswitch. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 Fax: +64 21 789-150 -----Original message----- From: Sean Devoy <sdevoy(a)bizfocused.com> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Subject: Re: [Freeswitch-users] Mistified by a registration issue Reply-to: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Date: Sat, 15 Mar 2014 23:59:02 +0000 Clive, Are you sure that is all that you are changing? Clearly the one that authorizes successfully has Authorization: Digest username="095290110", realm="voip", nonce="60f381b0", algorithm=MD5, uri="sip:sip.kiwilink.co.nz;transport=udp", response="a00513b45bea998c2f5dcdc89e9d8194" in the first sip packet. The one that fails does not include the "Authorization" information in the initial packet. Without knowing anything else, I would have guessed that the one that fails has the gateway configured with <param name="register" value="false"/> I realized you have basically indicated that is not changing, but if there is ANY chance you are using separate configurations, I would check your sipinterfaces.xml Hth, Sean -----Original Message----- From: freeswitch-users-bounces(a)lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Clive Lansink Sent: Saturday, March 15, 2014 5:21 PM To: Freeswitch users list Subject: [Freeswitch-users] Mistified by a registration issue Hello listers. I have had Freeswitch running for quite some time now with few issues. But recently I installed a new router and came across this problem while configuring it. I have my Sofia external profile set to use port 5060 and my internal profile uses another port. So I followed my previous practice and set the router to forward UDP port 5060 to Freeswitch and that works properly. I decided on this occasion that itmight be a good idea to also open up ports 16384-32768 so these are also forwarded to Freeswitch, as these are the RTP ports Freeswitch is set to use. I quickly found to my surprise that Freeswitch would fail to register with the external provider once I did this, but as soon as I stopped forwarding ports 16384-32768, Freeswitch would again register as it should. This seems really weird since I don't see how ports 16384-32768 can have any impact on the registration process on port 5060, and in any case whatever might be happening on these ports only involves Freeswitch so how can setting up such a port forwarding impact on registration. I would be pleased if anyone out there can answer this. I have included two SIP traces from the log. The first, trace1.txt, is the registration sequence when the ports are not forwarded. You can see Freeswitch sends a register, and the provider responds with an unauthorised which I think is the usual way it works. Freeswitch then responds with a register again and the provider responds with an ok. There are also some options packets in the sequence. So this is the regular pattern I see when Freeswitch is registered and remains registered. The second, trace2.txt, shows what happens when the ports 16384-32768 are set in the router to be forwarded to Freeswitch. Here we see Freeswitch sends a register packet, though it doesn't have the authentication information. I presume this is because at this point the gateway knows that it is not registered so this is like the first step in registering from scratch. Then we see the provider respond with an unauthorised message including (as before) the instruction for how to authenticate. But then Freeswitch doesn't respond with a follow-up attempt to register and eventually we see that it just reports that it timed out trying to register. I'm not a SIP expert but I don't see anything in the second dialog to explain why Freeswitch doesn't follow up to complete the registration even though it clearly does receive the unauthorised message with the authentication information. It would be great if someone could suggest what might be going on here. Thank you. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 Fax: +64 21 789-150 _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org http://www.freeswitchsolutions.com FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

1 0

rtp_audio_in_skip_packet_count
by Richard Brady 18 Mar '14

18 Mar '14

Hi folks Can anyone enlighten me on the meaning of rtp_audio_in_skip_packet_count ? We have one way audio on the start of calls and it seems to coincide with the packet count in this variable. (We happen to be attaching an eavesdrop to the channel in question, I'm not sure if that is relevant). I've seen Mick Stevens' previous question is this but he never really got a conclusive answer. Is it packet loss? Jitter? (Would a jb help?). Any info appreciated. I'm trying to interpret the source for this and will report back if I find anything. Regards, Richard -- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady(a)gmail.com

2 2

presence_hosts
by Chris B. Ware 17 Mar '14

17 Mar '14

Simple question: what's the meaning of this parameter on sip profiles? Wiki is not so clear.

1 0

gateway registration failed
by Tushar Patekar 17 Mar '14

17 Mar '14

please help me with gateway of IDT express, any one have it, please do reply tried everything possible at at first the the error was 403 forbidden then i changed Register Transport to tcp and now the error is this 2014-03-17 20:21:55.047305 [ERR] sofia_reg.c:2110 228ffc0e-d106-40b2-b992-7bb0c616d7cf Registration Failed with status Request Timeout [408]. my specs are - freeswitch 1.2 stable latest Ubuntu 12.04 anyone who have configured for IDT Express , HELP !!!! thanks

1 0

Week in Review March 9th-15th
by Kathleen King 17 Mar '14

17 Mar '14

Hello, again. This week in the FreeSWITCH master branch we had a total of 88 commits submitted. Most of the commits went toward miscellaneous features and bug fixes, such as the support improvements for Cisco 7925G in mod_skinny, a new web UI called Portal, and FS-353 using system libraries instead of bundled libraries. The following bugs were squashed: 89f9490 add ability to parse named params out of P-Asserted-Identity header in mod_sofia Jira: http://jira.freeswitch.org/browse/FS-6350 9fd30a2 work toward improvements in PRACK support Jira: http://jira.freeswitch.org/browse/FS-6339 7a6e8f4 add realm to sofia::expires event Jira: http://jira.freeswitch.org/browse/FS-6354 1727213 fixed support for 7925G with mod_skinny 9f804d2 mod_skinny: remove unknown field from access_status for Cisco 7925g 0f93cc2 FS-6281 mod_rayo: don't add timestamp to presence event that already has one. Jira: http://jira.freeswitch.org/browse/FS-6281 New features that were added: 88fda8c upgrade Windows build to use curl 7.35.0 Jira: http://jira.freeswitch.org/browse/FS-6346 f80404c added experimental create user on portal 3055438 mod_skinny: wait up to 5 seconds for OpenRecvChannelAck for improved connection to WiFi phones such as the 7925G 69a65aa add create user and gateway lua scripts to Portal 40c56c6 adding ussd capabilities to mod_gsmopen, thanks Boris. Jira: http://jira.freeswitch.org/browse/FS-5078 Improvements in cross platform build supports: ce78c14 fix mod_dingaling build 87af4d3 fix mod_enum install 4ee5d1f don't automatically override CFLAGS when building spandsp Jira: http://jira.freeswitch.org/browse/FS-6293 df9256d update windows build to use downloaded pcre Jira: http://jira.freeswitch.org/browse/FS-6347 d755b34 added -fPIC flag to libapr when building with clang to fix the build of mod_lua In terms of stability these were the use cases that were fixed: db22d28 fixed deadlock in mod_rayo when creating input voice component Jira: http://jira.freeswitch.org/browse/FS-6334 Feedback welcome and the referenced commits are in the attached text file with 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

1 0

HA issue with Mysql backend
by Mickael Hubert 17 Mar '14

17 Mar '14

Hi list, I have an issue with HA configuration (Mysql Backend). When I crash master Freeswitch, I try to recover my call (2 legs) in the slave server (same behavior if I recover in the same server "master to master"). *TEST 1:* Master (crash) --> Slave (recovery) *TEST 2:* Master (crash) --> restart freeswitch in master --> Master (recovery) I can recover only one leg, but I can see two legs in recovery table's Mysql. *Before crash:* *Recovery table with one call:* mysql> select runtime_uuid, technology, profile_name, hostname, uuid from recovery; +--------------------------------------+------------+--------------+----------+--------------------------------------+ | runtime_uuid | technology | profile_name | hostname | uuid | +--------------------------------------+------------+--------------+----------+--------------------------------------+ | 8b5a6b6c-adbe-11e3-b273-e98376048298 | sofia | internal | asbc2 | 952054fe-adbe-11e3-b291-e98376048298 | | 8b5a6b6c-adbe-11e3-b273-e98376048298 | sofia | external | asbc2 | 951e4b64-adbe-11e3-b276-e98376048298 | +--------------------------------------+------------+--------------+----------+--------------------------------------+ *2 rows* in set (0.00 sec) *After crash:* *Linux screen:* [root@asbc2 conf]# /usr/local/freeswitch/bin/fs_cli -x 'sofia recover' Recovered 1 call(s) *fs_cli screen:* 2014-03-17 11:23:56.492759 [WARNING] switch_core_sqldb.c:2715 Invalid cdr data, call not recovered mysql> select runtime_uuid, technology, profile_name, hostname, uuid from recovery; +--------------------------------------+------------+--------------+----------+--------------------------------------+ | runtime_uuid | technology | profile_name | hostname | uuid | +--------------------------------------+------------+--------------+----------+--------------------------------------+ | acba00a6-adbe-11e3-8380-19442cf25656 | sofia | internal | asbc2 | 952054fe-adbe-11e3-b291-e98376048298 | +--------------------------------------+------------+--------------+----------+--------------------------------------+ *1 row* in set (0.00 sec) *Freeswitch's configuration:* *Version:* FreeSWITCH Version 1.5.8b+git~20140214T000311Z~fe2a4d6d47~64bit (git fe2a4d6 2014-02-14 00:03:11Z 64bit) *Both Profiles:* <param name="track-calls" value="true"/> <param name="odbc-dsn" value="freeswitch:u_freeswitch:XXXXXXXX"/> *Switch.conf.xml:* <param name="core-db-dsn" value="freeswitch:u_freeswitch:XXXXXXXXXXXX" /> <param name="core-recovery-db-dsn" value="odbc://freeswitch:u_freeswitch:XXXXXXXXXXXXX"/> *odbc.ini:* [freeswitch] Driver = /usr/lib64/libmyodbc5-5.1.5.so SERVER = localhost PORT = 3306 DATABASE = freeswitch OPTION = 67108864 USER = u_freeswitch PASSWORD = XXXXXXXXXX *odbcinst.ini:* # Driver from the mysql-connector-odbc package # Setup from the unixODBC package [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc5.so Setup = /usr/lib/libodbcmyS.so Driver64 = /usr/lib64/libmyodbc5.so Setup64 = /usr/lib64/libodbcmyS.so FileUsage = 1 UsageCount = 1 Threading = 0 Debug = 1 MaxLongVarcharSize = 65536 Have you an idea with this issue ? Issue is due to beta version ? Thanks in advance. -- Cordialement HUBERT Mickaël Ingénieur VOIP - Hexanet --

1 0

Fail2Ban filter
by Nandy Dagondon 17 Mar '14

17 Mar '14

Hi to all, I just encountered an attack. I was wondering why fail2ban didn't catch it. The attacker used alphabetic user name. The regex detects numeric digits only. As a quick fix I modified the filter portion: ^\.\d+ \[WARNING\] sofia_reg\.c:\d+ Can't find user \[\d+(a)\d+\.\d+\.\d+\.\d+\] from <HOST>$ TO: ... Can't find user \[.+(a)\d+\.\d+\.\d+\.\d+\] from <HOST>$ to catch all characters. Just sharing this.

2 1

Freeswitch Professional support
by Yigal Rachilevsky 17 Mar '14

17 Mar '14

Hello We are looking for Consultant / Professional support in Israel If anyone is interested, please reply me Thanks

1 0

Modifying SDPs for SIPREC
by Siri MM 17 Mar '14

17 Mar '14

Hi, I am trying to come up with a simplified SIPREC compliant client, which would playback an existing recorded file to a third party server. It is a requirement of SIP RFC that the INVITE message from the SIPREC client has SDP attributes such as a=sendonly, a=label and so on. Further Contact URI in the SIP header needs to be updated to include '+sip.src' feature tag, "siprec" option tag in the Require header etc. I was wondering if this is achievable in freeswitch in it's current state? Or am I required to come up with my own mod, such as mod_oreka, to send the INVITE with the required headers?

3 3