- FreeSWITCH-users - FreeSWITCH Mailing Lists

upnp sending M-SEARCH to wan, as opposed to lan ethernet interface
by Bill Ross 22 Jun '14

22 Jun '14

Hi; I am getting NAT detection errors: fs_cli: freeswitch@internal> nat_map status Nat Type: UNKNOWN, ExtIP: NAT port mapping enabled. freeswitch.log 2014-06-21 07:55:56.415860 [INFO] switch_nat.c:420 Scanning for NAT 2014-06-21 07:55:56.415860 [DEBUG] switch_nat.c:170 Checking for PMP 1/5 2014-06-21 07:55:56.415860 [ERR] switch_nat.c:201 Error checking for PMP [general error] 2014-06-21 07:55:56.415860 [DEBUG] switch_nat.c:425 Checking for UPnP 2014-06-21 07:56:08.415906 [INFO] switch_nat.c:441 No PMP or UPnP NAT devices detected! Network topology: LAN / eth0 = 192.168.1.1 WAN /eth1 = 192.0.xxx.xxx (dynamic IP) I have tracked this down to upnp M-SEARCH is being sent using the WAN, as opposed to LAN interface. From: autoload_configs/acl.conf.xml <list name="lan" default="allow"> <node type="deny" cidr="192.168.1.1/32"/>  <node type="allow" cidr="192.168.1.1/16"/>  </list> root@OpenWrt:/usr/local/freeswitch/conf# tcpdump -i eth1 | grep 1900: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 07:55:56.431306 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 137 07:55:59.431423 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 132 07:56:02.431512 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 133 07:56:05.431642 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 101 Questions: Q1: How do I coerece upnp to broadcast using eth0 (LAN), as opposed to eth1 (WAN)? Q2: What is the algorithm upnp uses to determine multicast interface? Thanks; Bill Ross

2 7

Re: [Freeswitch-users] Why a call hangs up without warning during recording
by Anthony Minessale 22 Jun '14

22 Jun '14

try setting record_waste_resources=true on the channel On Sat, Jun 21, 2014 at 8:09 PM, Clive Lansink <clive(a)lansink.co.nz> wrote: > Hello. > > I've noticed in a Freeswitch IVR application I've been working on that > when the customer phones in to record a message, the call is hung up > without warning after about five minutes. This does not happen when I call > in locally. When this happens, the log just shows there was a hangup with > normal clearing. But the customer didn't hang up. The customer just notices > visually that their phone hangs up so the hangup seems to be caused > somewhere between the two systems. > > I figured that during a recording, Freeswitch is not generating any audio > at all, and it could be that something in the public phone system times out > after absolutely no audio for a period of time. I have come up with a work > around by getting Freeswitch to generate a short tone repeatedly during > recording, like 50Hz at -30dB so it is basically inaudible, every thirty > seconds or so. This seems to have solved the problem and now the customer > can record for as long as he wants. > > But I suspect this is really a work-around and not the recommended > approach. I did play with the suppress cng parameter in the sofia > configuration but didn't find any setting that would solve the problem. > > Thankfully my work-around has got me home in the meantime but I would > appreciate any comments on this. Does nobody make long recordings these > days? > > Cheers. > > > 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 > -- Anthony Minessale II ♬ @anthmfs ♬ @FreeSWITCH ♬ ☞ http://freeswitch.org/ ☞ http://cluecon.com/ ☞ http://twitter.com/FreeSWITCH ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+ <http://freeswitch.org/g+>* ClueCon Weekly Development Call ☎ sip:888@conference.freeswitch.org ☎ +19193869900

1 0

Why a call hangs up without warning during recording
by Clive Lansink 22 Jun '14

22 Jun '14

Hello. I've noticed in a Freeswitch IVR application I've been working on that when the customer phones in to record a message, the call is hung up without warning after about five minutes. This does not happen when I call in locally. When this happens, the log just shows there was a hangup with normal clearing. But the customer didn't hang up. The customer just notices visually that their phone hangs up so the hangup seems to be caused somewhere between the two systems. I figured that during a recording, Freeswitch is not generating any audio at all, and it could be that something in the public phone system times out after absolutely no audio for a period of time. I have come up with a work around by getting Freeswitch to generate a short tone repeatedly during recording, like 50Hz at -30dB so it is basically inaudible, every thirty seconds or so. This seems to have solved the problem and now the customer can record for as long as he wants. But I suspect this is really a work-around and not the recommended approach. I did play with the suppress cng parameter in the sofia configuration but didn't find any setting that would solve the problem. Thankfully my work-around has got me home in the meantime but I would appreciate any comments on this. Does nobody make long recordings these days? Cheers. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 Fax: +64 21 789-150

1 0

IPV6 addr change killed sofia profile internal
by Mario G 21 Jun '14

21 Jun '14

I have a mix of native IPV4/6. A mac runs FreeSWITCH using a static IP4 address and has IPV6 addresses. For some reason (I am not an IPV6 expert) the IPV6 address changes once or twice a day. Everything on the mac runs fine except FreeSWITCH stops all the profiles then restarts them, it then loses the internal profile. The sequence is below, If anyone knows of a FS param or something I can use to workaround this please let me know. BTW, I am not using IPV6 to the external ITSPs, but the Yealink phones have it on, I could turn it off but was hoping for a real solution. Thanks, Mario G 1 - Log shows: [INFO] mod_sofia.c:5286 IP change detected []->[] [2601:9….. 2 - FreeSWITCH stops all 7 external profiles and the internal profile. 3 - All profiles are restarted, but only the external ones start successfully. The internal does not start because the port has not been freed by OS X yet. And FreeSWITCH never attempts to restart it again. I am sure this is related to Jira http://jira.freeswitch.org:8080/browse/FS-5223 but is a bigger problem since I have to turn off IPV6 to stop it. 4 - I have to "sofia profile internal start” to get it going again. PS: Would love to find a way to get FS to keep trying to restart internal rather than give up, would help both problems.

5 13

WebRTC: Receiving local IP in SDP
by Miguel Oyarzo 21 Jun '14

21 Jun '14

Hi, I cannot manage to send the right SDP into the INVITE message from FS to my WebRTC client registered on it. The scenario is: WebClient<---wss/srtp---->FS<--rtp-->SIP_Endpoint - FS run in a EC2 instance. - FS/application="bridge" - WebClient run on Internet. Calls from WebClient to SIP_Endpoint works well and FS manages to reply a 200 OK response, after INVITE from WebClient, with a public IP into SDP. Audio is bi-directional, all looks good. However, calls originated on SIP_Endpoint to WebClient makes FS to include its private IP into the DSP for any INVITE toward WebClient (B-leg). I have updated 'tried ext-rtp-ip' to - Public IP address of the instance - private and public STUN services - auto-nat No matter what I do, I always get o=FreeSWITCH 1403050916 1403050917 IN IP4 10.10.1.120 c=IN IP4 10.10.1.120 At the WebClient side (INVITE). The weird is, using the same profiles in FS, calls from WebClient to SIP_Endpoint have no issues. Trace in FS (SIP_Endpoint -> WebClient) ---------------------------------------------------------------------------- 2014-06-18 13:09:50.318354 [NOTICE] switch_channel.c:1053 New Channel sofia/inboundbrowser/61370000000 [02c48e60-f696-11e3-b962-2703af7256ae] 2014-06-18 13:09:50.318354 [DEBUG] mod_sofia.c:4446 (sofia/inboundbrowser/61370000000) State Change CS_NEW -> CS_INIT 2014-06-18 13:09:50.318354 [DEBUG] switch_core_session.c:1384 Send signal sofia/inboundbrowser/61370000000 [BREAK] 2014-06-18 13:09:50.318354 [DEBUG] mod_sofia.c:4516 [zrtp_passthru] Setting a-leg inherit_codec=true 2014-06-18 13:09:50.318354 [DEBUG] mod_sofia.c:4519 [zrtp_passthru] Setting b-leg absolute_codec_string='PCMA@8000h@20i@64000b' 2014-06-18 13:09:50.318354 [DEBUG] switch_core_state_machine.c:467 (sofia/inboundbrowser/61370000000) Running State Change CS_INIT 2014-06-18 13:09:50.318354 [DEBUG] switch_core_state_machine.c:507 (sofia/inboundbrowser/61370000000) State INIT 2014-06-18 13:09:50.318354 [DEBUG] mod_sofia.c:87 sofia/inboundbrowser/61370000000 SOFIA INIT 2014-06-18 13:09:50.318354 [DEBUG] switch_core_media.c:865 Set Local Key [1 AES_CM_128_HMAC_SHA1_80 inline:4hCK5K0NEWULvEWlyp6LEmcPVDwqTu2AUhbh7jqV] 2014-06-18 13:09:50.318354 [DEBUG] switch_core_media.c:865 Set Local Key [1 AES_CM_128_HMAC_SHA1_80 inline:6TEOHAvn7aga7PA7GvEsm/QBsztoMyov4Jv8vvGg] 2014-06-18 13:09:50.318354 [DEBUG] sofia_glue.c:1196 sip:10.10.1.120:5064;transport=udp;lr;ovid=aa2aa1e2 Setting proxy route to sofia/inboundbrowser/61370000000 2014-06-18 13:09:50.318354 [DEBUG] sofia_glue.c:1225 sofia/inboundbrowser/61370000000 sending invite version: 1.5.8b git 68e1a56 2014-02-23 23:59:01Z 64bit Local SDP: v=0 o=FreeSWITCH 1403050916 1403050917 IN IP4 10.10.1.120 s=FreeSWITCH c=IN IP4 10.10.1.120 t=0 0 a=msid-semantic: WMS pulb3IfP3ufkGKJf4haQDJ15jmDs4syk m=audio 10074 RTP/SAVPF 8 101 13 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fingerprint:sha-256 6D:40:E1:C3:73:9F:F1:33:DA:7B:4B:1A:F1:2B:74:C7:42:24:EF:3D:84:6A:3B:1A:F9:9D:8B:3B:09:AB:33:AF a=rtcp-mux a=rtcp:10074 IN IP4 10.10.1.120 a=ssrc:3489368462 cname:NKlGirlcLrmh1WnW a=ssrc:3489368462 msid:pulb3IfP3ufkGKJf4haQDJ15jmDs4syk a0 a=ssrc:3489368462 mslabel:pulb3IfP3ufkGKJf4haQDJ15jmDs4syk a=ssrc:3489368462 label:pulb3IfP3ufkGKJf4haQDJ15jmDs4syka0 a=ice-ufrag:4oCxXtt6GWoBfNLT a=ice-pwd:nXpveByQTLXLybxs a=candidate:1887505845 1 udp 659136 10.10.1.120 10074 typ host generation 0 a=candidate:1887505845 2 udp 659136 10.10.1.120 10074 typ host generation 0 a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4hCK5K0NEWULvEWlyp6LEmcPVDwqTu2AUhbh7jqV a=ptime:20 a=sendrecv ---------------------------------------------------------------------------- What's is wrong here is c=IN IP4 10.10.1.120 (must be public for RTP traffic between WebClient and FS) and a=candidate for public IP is missing (STUN is enabled in FS's profile) Any idea? -- "Efficiency is doing things right; effectiveness is doing the right things (Peter Drucker)" Miguel Oyarzo DevOps & VoIP Engineer Linux User: # 483188 - counter.li.org http://au.linkedin.com/in/mikeaustralia Melbourne, Australia

2 4

Re: [Freeswitch-users] SIP 500 overlapping requests
by Phil Quesinberry 20 Jun '14

20 Jun '14

Correction: I meant to say "if FreeSWITCH could be configured to either wait up to x milliseconds for an ACKNOWLEDGEMENT to arrive." ___________________________________ From: Phil Quesinberry Sent: Friday, June 20, 2014 3:36 PM To: 'freeswitch-users(a)lists.freeswitch.org' Subject: RE: SIP 500 overlapping requests As it turns out, my assumption was correct. We were not receiving an acknowledge before the second invite from the carrier. One of their support engineers determined that they had recently enabled acknowledgement logging on their proxy/SBC, which apparently delayed transmission of the acknowledgement by a millisecond or two, which was enough to cause the invite from the server handling the media/call to arrive just slightly before the acknowledgement, so FreeSWITCH would tear down the call. The problem was intermittent since the acknowledgement would sometimes arrive first. They disabled acknowledgement logging and the problem went away. With this and UDP in mind, it would likely reduce the incidence of dropped calls if FreeSWITCH could be configured to either wait up to x milliseconds for an invite to arrive, or allow x number of overlapping requests before throwing an error. I saw a post where Tony mentioned that a patch had already been crafted to allow overlapping requests in the past, so it seems that most of the work has been done. __________________________________ From: Phil Quesinberry Sent: Thursday, June 19, 2014 11:08 AM To: 'freeswitch-users(a)lists.freeswitch.org' Subject: SIP 500 overlappting requests 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

Re: [Freeswitch-users] SIP 500 overlapping requests
by Phil Quesinberry 20 Jun '14

20 Jun '14

As it turns out, my assumption was correct. We were not receiving an acknowledge before the second invite from the carrier. One of their support engineers determined that they had recently enabled acknowledgement logging on their proxy/SBC, which apparently delayed transmission of the acknowledgement by a millisecond or two, which was enough to cause the invite from the server handling the media/call to arrive just slightly before the acknowledgement, so FreeSWITCH would tear down the call. The problem was intermittent since the acknowledgement would sometimes arrive first. They disabled acknowledgement logging and the problem went away. With this and UDP in mind, it would likely reduce the incidence of dropped calls if FreeSWITCH could be configured to either wait up to x milliseconds for an invite to arrive, or allow x number of overlapping requests before throwing an error. I saw a post where Tony mentioned that a patch had already been crafted to allow overlapping requests in the past, so it seems that most of the work has been done. __________________________________ From: Phil Quesinberry Sent: Thursday, June 19, 2014 11:08 AM To: 'freeswitch-users(a)lists.freeswitch.org' Subject: SIP 500 overlappting requests 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

PostgreSQL rapid XID incrementation
by Joel White 20 Jun '14

20 Jun '14

I was wondering why when I enabled PostgreSQL in Freeswitch, the PostgreSQL XID is incrementing at an extreme pace. I do not have hardly any transactions being inserted into the db. It looks like most all of the queries are SELECT statements. Is this normal? Or is there something that I need to tweak in freeswitch?

2 4

Effectiver Caller ID with Sipgate-Trunk
by Sconst Verbavoice 20 Jun '14

20 Jun '14

Hi everyone, I´m trying to change the sender number, It should depends on who ist making the call. At the moment it comes only the DID- number from Sipgate-Trunk. I have tried to change in the dialplan and in the directory the "Effectiver_caller_id" and the "outbound_caller_id" (Number and Name) without success. I also changed in the gateway the "caller-id-in-from" to "true", but with that Parameter, the gateway doesn´t work. I talked to Sipgate and they cannot help... Does someone know, what I´m missing? Thank you very much :) SC

4 5

ESL initial data format at connect
by Tim Meade 20 Jun '14

20 Jun '14

During the outbound ESL handshake, I am issuing the connect\n\n and receiving the initial CHANNEL_DATA event as key value pairs (plain). Is there any way to get this as json? If I issue the 'event json all' command prior, I'm getting everything after this initial data as json, but not the initial data. I'm hoping it's something simple in the xml.conf file or a default. Thanks Tim

2 2