January 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] Mod LCR SQL sub-query for better routing
by DP . 14 Jan '15

14 Jan '15

Victor, I take back my initial response on this old email. We ran into a couple of cases with some carriers and multiple matching prefixes. After actually trying your sub query (modified for Mysql), it actually does return the true lowest rate from a carrier while importantly respecting the longest match per carrier. Unlike the reorder_by_rate function that does not respect the longest match per carrier. That function simply returns the lowest rate, period. So thanks! From: hi-tecc(a)hotmail.com To: freeswitch-users(a)lists.freeswitch.org Subject: RE: [Freeswitch-users] Mod LCR SQL sub-query for better routing Date: Mon, 16 Dec 2013 18:36:06 -0500 I agree. This definitely sounds like he simply needed the "reorder_by_rate" param. It will reorder the initial sql results strictly by rate: reorder_by_rate - Forces the LCR module to re-order the query strictly on rate basis. By default this is turned off, but enabling this will always prefer rate over anything else. Beware this may have an adverse effect! I initially had this turned on then quickly realized it would sometimes try to route ALL calls by the lowest rate found. Ex: flowroute lists all calls for the US with a default NPA of "1" at .0098. Now a user trying to call Jamaica with "1876" at a rate of 0.19 (or whatever) will get both flowroute rates returned. The reorder by rate will assume 0.0098 is a valid rate since it will now be the "cheapest" in the list and send the call along its way to flowroute, whom will now bill you at 0.19. Now if you have another carrier in your list with 1876 at 0.15 you can see why this would be a problem. In this case you will always want the longest matched NPANXX rate. Date: Fri, 13 Dec 2013 15:58:54 -0500 From: intralanman(a)freeswitch.org To: freeswitch-users(a)lists.freeswitch.org Subject: Re: [Freeswitch-users] Mod LCR SQL sub-query for better routing On 12/12/2013 02:42 PM, Victor Chukalovskiy wrote: Hello, For those interested, I added a piece to mod lcr wiki. It makes sorting / routing logic better than default logic: http://wiki.freeswitch.org/wiki/Mod_lcr#Custom_SQL_with_sub-query_-_for_rea… Why it helps: Rates rates can often be given both on per-NPA or per-NPANXX level depending on the carrier and on the NPA. Moreover, some carriers may have NPANXX rate lower than the corresponding NPA rate, while others will have it inverse. Neither simple ORDER BY rate, prefix; nor ORDER BY prefix, rate; give the truly cheapest route. The LCR logic should be two-step process to accommodate this. Cheers, -Victor Unless I misunderstand what you're saying, this is what the reorder_by_rate param does. You'll always want to pick the longest digit match per carrier. Then you probably want to grab the cheapest overall rate of the matches you got back. -Ray _________________________________________________________________________ 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

3 2

Re: [Freeswitch-users] Security Issue
by Ahmed Habiba 14 Jan '15

14 Jan '15

Dear Brian, Thank you really for your feedback, what you mentioned is correct, however I understand that any call to comes from external system to public context to processed , the external system IP shall be allowed via ACL, accordingly we shouldn't expect any traffic to processed from a server/IP that is not defined in the ACL, am I correct? Thanks, Ahmed Habiba. From: Brian West <brian(a)freeswitch.org <mailto:brian@freeswitch.org>> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Date: January 14, 2015 at 7:29:28 PM GMT+3 Reply-To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org <mailto:freeswitch-users@lists.freeswitch.org>> Subject: Re: [Freeswitch-users] Security Issue You have some learning to do about VoIP and various security models. See comments inline. On Wed, Jan 14, 2015 at 10:08 AM, Ahmed Habiba <ahabiba(a)gmail.com <mailto:ahabiba@gmail.com>> wrote: Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: The IP was 142.54.179.218... thats the real IP we received the request from. freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE <>sip:9009972599796504@177.31.245.177:5080 <sip:9009972599796504@177.31.245.177:5080> SIP/2.0 To: 9009972599796504< <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> From: 1000< <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: < <>sip:1000@142.54.179.218:5070 <sip:1000@142.54.179.218:5070>> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally As it should, Its hitting the external profile which doesn't have authentication on it. ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000< <>sip:1000@177.31.245.177 <sip:1000@177.31.245.177>>;tag=e8473b10 To: 9009972599796504< <>sip:9009972599796504@177.31.245.177 <sip:9009972599796504@177.31.245.177>> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) No thats false, This is just a channel named thats formed from various bits of data, Its meaningless data and can be set, overridden or changed. This has no bearing on what freeswitch thinks. Most likely its using the host element from the From header. 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 <mailto:1000@177.31.245.177> [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> receiving invite from 142.54.179.218:5070 <http://142.54.179.218:5070/> version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177>) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 <mailto:sofia/external/1000@177.31.245.177> Standard ROUTING This is someone from outside calling in to your system, the public context is a sandbox to allow you to isolate and route non-authenticated traffic to your internal contexts via the transfer app, per the vanilla config examples. This is also whey you need to understand how to secure FreeSWITCH. 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting(a)freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> -- Brian West brian(a)freeswitch.org <mailto:brian@freeswitch.org> Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com <http://www.freeswitchbook.com/> http://www.freeswitchcookbook.com <http://www.freeswitchcookbook.com/> T:+19184209001 <tel:%2B19184209001> | F:+19184209002 <tel:%2B19184209002> | M:+1918424WEST (9378) iNUM:+883 5100 1420 9001 | ISN:410*543 | Skype: <skype:briankwest>briankwest <skype:briankwest>

2 1

Security Issue
by Ahmed Habiba 14 Jan '15

14 Jan '15

Dears, Kindly I noticed a very strange behaviour on Freeswitch that may allow non authorised users to make call through the system below is the log and my notice highlighted, you help will be appreciated. 1-Below is a request coming from not authored IP. 2-However the originating IP is “142.54.179.218” the from is as below as if it is from the same server: freeswitch@internal> recv 770 bytes from udp/[142.54.179.218]:5070 at 16:41:34.211099: ------------------------------------------------------------------------ INVITE sip:9009972599796504@177.31.245.177:5080 SIP/2.0 To: 9009972599796504<sip:9009972599796504@177.31.245.177> From: 1000<sip:1000@177.31.245.177>;tag=e8473b10 Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Contact: <sip:1000@142.54.179.218:5070> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, BYE User-Agent: sipcli/v1.8 Content-Type: application/sdp Content-Length: 285 v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=ptime:20 a=sendrecv 3-Accordingly Freeswitch start to deal with the call normally ------------------------------------------------------------------------ send 333 bytes to udp/[142.54.179.218]:5070 at 16:41:34.211442: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 142.54.179.218:5070;branch=z9hG4bK-d6e1ddab827448435f49ecaf6e613e2e;rport=5070 From: 1000<sip:1000@177.31.245.177>;tag=e8473b10 To: 9009972599796504<sip:9009972599796504@177.31.245.177> Call-ID: d6e1ddab827448435f49ecaf6e613e2e CSeq: 1 INVITE Content-Length: 0 ———————————————————————————————————— 4-as we can see below Freeswitch consider the call coming from my server IP not from the remote IP(My server IP = 177.31.245.177) 2015-01-14 16:41:34.203196 [NOTICE] switch_channel.c:1055 New Channel sofia/external/1000(a)177.31.245.177 [d1879400-9c03-11e4-8cd6-2f1eb174d7b4] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1053 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_NEW 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:8812 sofia/external/1000(a)177.31.245.177 receiving invite from 142.54.179.218:5070 version: 1.4.13 git b942d0f 2014-11-03 19:53:00Z 64bit 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6606 Channel sofia/external/1000(a)177.31.245.177 entering state [received][100] 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6616 Remote SDP: v=0 o=sipcli-Session 1883669566 1798766211 IN IP4 142.54.179.218 s=sipcli c=IN IP4 142.54.179.218 t=0 0 m=audio 5072 RTP/AVP 18 0 8 101 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 2015-01-14 16:41:34.203196 [DEBUG] sofia.c:6868 (sofia/external/1000(a)177.31.245.177) State Change CS_NEW -> CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:491 (sofia/external/1000(a)177.31.245.177) State NEW 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177) State INIT 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:87 sofia/external/1000(a)177.31.245.177 SOFIA INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:40 sofia/external/1000(a)177.31.245.177 Standard INIT 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:48 (sofia/external/1000(a)177.31.245.177) State Change CS_INIT -> CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_session.c:1388 Send signal sofia/external/1000(a)177.31.245.177 [BREAK] 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:512 (sofia/external/1000(a)177.31.245.177) State INIT going to sleep 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:472 (sofia/external/1000(a)177.31.245.177) Running State Change CS_ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_channel.c:2184 (sofia/external/1000(a)177.31.245.177) Callstate Change DOWN -> RINGING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:528 (sofia/external/1000(a)177.31.245.177) State ROUTING 2015-01-14 16:41:34.203196 [DEBUG] mod_sofia.c:123 sofia/external/1000(a)177.31.245.177 SOFIA ROUTING 2015-01-14 16:41:34.203196 [DEBUG] switch_core_state_machine.c:166 sofia/external/1000(a)177.31.245.177 Standard ROUTING 2015-01-14 16:41:34.203196 [INFO] mod_dialplan_xml.c:558 Processing 1000 <1000>->9009972599796504 in context public

2 1

Current FreeSWITCH licensing page?
by Craig Stevenson 14 Jan '15

14 Jan '15

I am trying to track down current FreeSWITCH licensing information. I found http://wiki.freeswitch.org/wiki/Licensing but that was last updated two years ago and is in the obsolete wiki. I suspect there are a few additional components added over the past few years. I'm sure it is there somewhere on the new site. But searching for "License" or "Licensing" on freeswtich.org page doesn't find it for me. Thanks, Craig

3 2

SDP Renegotiation
by Jon Lederman 14 Jan '15

14 Jan '15

Hi, I am trying to get my client to work with Freeswitch in the following context to no avail. If I initiate a video call, the video works fine. However, if I start an audio call and then try to add video later in the call, no video is received. I tried adding this line to vars.xml: (<param name="renegotiate-codec-on-reinvite" value="true”/> That, however, did not fix the problem. Any help would be greatly appreciated. The SDP negotiation is indicated below. Thanks in advance. I do see in fs_cli that FS has received a new SDP and is trying to renegotiate as follows: INITIAL SDP (AUDIO ONLY): v=0 o=FreeSWITCH 1421171138 1421171140 IN IP4 146.148.54.28 s=FreeSWITCH c=IN IP4 146.148.54.28 t=0 0 m=audio 25746 RTP/AVP 124 101 a=rtpmap:124 opus/48000/2 a=fmtp:124 useinbandfec=1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv m=video 26852 RTP/AVP 98 a=rtpmap:98 VP8/90000 NEW SDP WITH ATTEMPT TO ADD VIDEO TO EXISTING SESSIOn: 2015-01-14 00:55:29.401667 [DEBUG] sofia.c:5828 Remote SDP: v=0 o=1000 3968 2153 IN IP4 10.1.10.10 s=Talk c=IN IP4 10.1.10.10 b=AS:380 t=0 0 a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics m=audio 53368 RTP/AVP 124 101 a=rtpmap:124 opus/48000/2 a=fmtp:124 useinbandfec=1; stereo=0; sprop-stereo=0 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=video 9078 RTP/AVP 103 a=rtpmap:103 VP8/90000

2 1

Multitenant subscription restriction
by Ricardo Barroetavena 14 Jan '15

14 Jan '15

Hi, In a multitenant environment, is there a way to restrict one tenant UA from subscribing to another tenant events? For example, if I've got bob@domain1 and alice@domain2, is there a way to prevent bob from subscribing to let's say alice message-summary events? Thanks for the hints

4 7

Database query from dialplan
by John Nash 14 Jan '15

14 Jan '15

I need to run a DB query (Postgresql) from dialplan and store results in variables. I came across this link https://wiki.freeswitch.org/wiki/Mod_odbc_query and looks like this is what I need. But I was wondering if I can use direct (without odbc) query to postgresql. Is there any such application available? P.S. I read some posts about postgresql native support but have not been able to figure out what do I need to do to run a postgresql query from dialplan and store results with out odbc

8 13

Cisco SPA + BLF behavior
by Gabriel Kuri 14 Jan '15

14 Jan '15

I noticed that on a Cisco SPA500 series phone, when configured to do BLF+SD+CP for an extension, the LED for that line on the SPA does not turn red when the line goes off-hook on another phone. It turns RED when the call is actually in progress (ie after the number has been dialed and it's ringing). This behavior is different than when the same line is configured as a shared line appearance on the SPA, the LED turns red immedialtely when the line goes off hook on another phone. It appears FreeSWITCH is sending the same SIP NOTIFY event in both cases with line showing seized (appearance-index=1;appearance-state=seized), so I'm think this might be a bug in the phone's firmware, which is running the latest version, 7.5.6a. I did try a couple older version and had the same results. Am I missing something or is this the behavior of this phone? Should I bother to open a TAC case with Cisco, the behavior seems buggy to me?

2 2

freeswitch reuses RTP port when bridging second call to user
by Dave Horton 14 Jan '15

14 Jan '15

I have a problem relating the handling of a second incoming call to same extension/user. The scenario is this: - call from PSTN comes to freeswitch; freeswitch bridges the call to the identified registered device; call is set up fine (two-way audio) - a second call from the PSTN to the same DID comes to freeswitch; freeswitch bridges the call to the same identified registered device; call has no audio In looking at the traces, the problem stems from the fact that for the second call freeswitch is sending an INVITE offering an SDP with the same source ip and port as the first call. This causes the subsequent INVITE on hold from the phone (which is accepted by the freeswitch) to cause the phone not to send any RTP; meanwhile, the RTP sent from the freeswitch to the phone for the second call is rejected with an ICMP port unreachable since the phone has successfully invited that port on hold. In other words, by re-using the same port for call 1 and call 2, when call 1 is invited on hold the result means no media for call 2. Is this known, or expected behavior? Is this a bug? Has this been fixed in a more recent release (I'm on a very old release) Dave

1 0

Freeswitch only records empty files
by bee 14 Jan '15

14 Jan '15

Hey, i got an script which makes a call to an outbound number (so only 1 channel is open) and then i want to record the input. But the record function only create empty 44kb files. When i join the channel over a softphone the recorded files have input. Any ideas? -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Freeswitch-only-records-empty… Sent from the freeswitch-users mailing list archive at Nabble.com.

4 3