June 2014 - FreeSWITCH-users - FreeSWITCH Mailing Lists

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

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