March 2014 - FreeSWITCH-dev - FreeSWITCH Mailing Lists

Eavesdrop with WebRTC clients - part 2
by Yan Brenman 28 Mar '14

28 Mar '14

Dear FreeSWITCH gurus, with the sigh of relief I am happy to acknowledge that I got the "eavesdrop" working with WebRTC clients - both video and audio. The solution is definitely not permanent, but provides good enough workaround to move forward with my project. Also, quality of audio is a bit questionable, but this is something I can deal with later. Here is an immediate problem I ran into and would like to ask your help with. For some reason eavesdropping on the call only starts working after 2 - 2.5 minutes after the outbound call leg (the one which is eavesdropping) has been established. Another words, only after anywhere between 2 and 2.5 minutes I start seeing video and hear audio from the channel I am eavesdropping on. Any piece of advice is greatly appreciated. If not the definite answer - at very least please tell me what to suspect and where to look. Although I am pretty sure you already know the answer. Greatly appreciate your help Yan

2 2

Allow a PSTN user to call another PSTN user via dialpad
by Parimal Muli 27 Mar '14

27 Mar '14

Following is the use case that I want to achive using FS: 1. FS makes an outbound call to a PSTN user A. 2. A picks up the call and is greeted with a welcome message. 3. A then dials another PSTN number (that of user B) using the dialpad. 4. FS captures the number and calls B. 5. B picks up the call and FS joins A and B. --

2 1

ClueCon Tickets Are Live!
by Ken Rice 26 Mar '14

26 Mar '14

Hey FreeSWITCHers, ClueCon Ticket ordering is Live! Visit ClueCon.com and hit the registration link to get your tickets ordered today! ClueCon is Aug 4-7, 2014 at the Intercontinental Hotel in the heart of Chicago. What is ClueCon you ask? ClueCon is an an annual telephony and voice over IP developers conference started in 2005 by the FreeSWITCH core developer team. In fact FreeSWITCH itself was conceived at the first ClueCon as part of a large discussion between several open source leaders on how to improve the state of existing Internet Telephony options. Since then, every year ClueCon brings Telephony developers face to face with each other and with interesting new start-up and enthusiasts alike. It¹s a perfect blend of technical and business-oriented discussions from the leaders in the industry. The motto of the conference is ³A conference for developers, by developers² We focus on communication and getting people talking and sharing ideas. We have open discussions at the end of each presentation and a hearty lunch each day with plenty of time for meeting and speaking with the attendees and presenters. Each day is filled with interesting presentations in a relaxed atmosphere. You can watch a demo on the latest and greatest innovation in VoIP, or take a break and chat with your favorite open source developer or all of your friends that you usually only see online. ClueCon is the very best opportunity to get under the hood of many telephone related products and learning from the actual developers who made them possible. -- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch Twitter: @FreeSWITCH

1 0

Eavesdrop application doesn't work for the WebRTC clients
by Yan Brenman 25 Mar '14

25 Mar '14

Hello, I was trying to get the eavesdrop application work on the 1.4.beta branch for the WebRTC clients (works great for all other types of clients) and could not. Neither audio nor video (I merged the code from the video-media-bug branch for the video) is going through. For the client I tried both - sipml5 and jssip clients. Please let me know if there is any other piece of information I can provide. I will be more then happy to do any kind of code changes and testing - just need some starting points. Especially considering that I am very new to the WebRTC. Every piece of advice is greatly appreciated. Thanks Yan

4 11

Eavesdrop doesn't work for WebRTC calls
by Yan Brenman 21 Mar '14

21 Mar '14

Hello, I have been running the 1.4.beta branch of the FreeSWITCH to do some WebRTC related testing. And I noticed that "eavesdrop" application, although working nicely for the any other types of clients, doesn't work for the WebRTC. I am not getting neither video nor audio (I did merge changes from the video-media-bug branch and do get video "eavesdropped" nicely using jitsi clients) using SIPML5 clients. I will be more than happy to do any code modifications and testing required, just need some initial input as I am relatively new to WebRTC. I looked at the current implementation of "eavesdrop" and everything seems to make perfect sense. Why it doesn't work for the WebRTC then? Please let me know if there is anything I can provide. Any help is greatly appreciated. Thanks

3 3

To everyone testing git master...
by Brian West 21 Mar '14

21 Mar '14

With all the changes going in to the build system over the next week or two we’ll need everyone to assist in building and reporting issues back to us. Thanks, -- 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)

2 1

inline applications
by daemonserj TVC 20 Mar '14

20 Mar '14

Hello Why among language applications inline is permitted only for LUA ? I've found it switched on/off by SAF_ROUTING_EXEC flag. Is it not safe for something ? I'm concretely intrested in java . Regards

1 0

Video of the WebRTC client gets locked up
by Yan Brenman 13 Mar '14

13 Mar '14

Hello, I have been running 1.4.beta (WebRTC enabled) branch of the FreeSWTICH with SIPml5 clients and I am constantly getting client video freeze in about a minute after call is established and video shows up. Here is the relevant part of the log from the console: 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2577 Choose video Candidate cid: 1 proto: udp type: host addr:99.8.141.165:64234 <http://137.79.217.63:64234/> 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2577 Choose video Candidate cid: 2 proto: udp type: host addr:99.8.141.165:64234 <http://137.79.217.63:64234/> 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2582 Save video Candidate cid: 1 proto: udp type: host addr:192.168.239.1:64235 <http://192.168.239.1:64235/> 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2582 Save video Candidate cid: 2 proto: udp type: host addr:192.168.239.1:64235 <http://192.168.239.1:64235/> 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2706 setting remote video ice addr to99.8.141.165:64234 <http://137.79.217.63:64234/>based on candidate 2014-03-12 15:24:00.923640 [NOTICE] switch_core_media.c:2726 setting remote rtcp video addr to99.8.141.165:64234 <http://137.79.217.63:64234/>based on candidate 2014-03-12 15:24:00.923640 [INFO] switch_core_media.c:2745 RE-Activating video ICE 2014-03-12 15:24:00.923640 [NOTICE] switch_rtp.c:3775 Activating RTP video ICE: +Pz0ELVd4tEZygTU:ZGabdph1JK6l9boM99.8.141.165:64234 <http://137.79.217.63:64234/> 2014-03-12 15:24:00.923640 [INFO] switch_core_media.c:2794 Activating video RTCP PORT 64234 2014-03-12 15:24:00.923640 [INFO] switch_core_media.c:2802 Skipping video RTCP ICE (Same as RTP) 2014-03-12 15:24:00.923640 [INFO] switch_core_media.c:4703 RE-SETTING video DTLS 2014-03-12 15:24:00.923640 [INFO] switch_rtp.c:2878 Activate RTP/RTCP video DTLS server 2014-03-12 15:24:00.962458 [NOTICE] switch_rtp.c:1132 Auto Changing stun/rtp/dtls port from99.8.141.165:64234 <http://137.79.217.63:64234/>to192.168.239.1:64235 <http://192.168.239.1:64235/> 2014-03-12 15:24:01.003229 [NOTICE] switch_rtp.c:1132 Auto Changing stun/rtp/dtls port from99.8.141.165:64234 <http://137.79.217.63:64234/>to192.168.239.1:64235 <http://192.168.239.1:64235/> 2014-03-12 15:24:01.982369 [WARNING] switch_rtp.c:857 sofia/internal/1003(a)192.168.239.150 <mailto:1003@192.168.239.150>got stun binding response 487 Role Conflict 2014-03-12 15:24:01.982369 [WARNING] switch_rtp.c:868 Changing role to CONTROLLED 2014-03-12 15:24:01.982369 [WARNING] switch_rtp.c:857 sofia/internal/1003(a)192.168.239.150 <mailto:1003@192.168.239.150>got stun binding response 487 Role Conflict 2014-03-12 15:24:01.982369 [WARNING] switch_rtp.c:868 Changing role to CONTROLLED Just one more thing wanted to mention is that my clients are running on the same subnet as the FreeSWITCH and the FreeSWITCH is running inside of the Linux CentOS VM. Could the root of the problem be the fact that FreeSWICH is running in the VM and ICE tries to use the port on the VM interface (192.168.239.1 <http://192.168.239.1:64235/>)? I would greatly appreciate any piece of advise on the subject. Thanks Yan

1 0

Difference of behaviour between apply-acl profile parameters
by Florent Krieg 13 Mar '14

13 Mar '14

Hello all, While checking and tuning our FreeSWITCH configuration, I found out that there is big difference of behaviour between the apply-inbound-acl and apply-register-acl sofia sip profile parameters. => in the case of 'apply-inbound-acl', requests coming from an IP present in the acl profile list will be authentified as the matching account, which is OK. => in the case of 'apply-register-acl', register requests coming from an IP present in the acl profile list will be authorized (which is OK), while being 'authentified' as the user specified in the SIP request. I would have imagined that register requests would be identified as the matching account as well. We end up in getting crazy registrations (devices registered as user not existing in the directory for instance), when customers' hardware are not permissive enough to allow from (user@domain) field customisation (while outgoing calls are perfectly working). Is that behaviour wanted by the community? I checked the source code which I reckon I am not familiar with at all, and I found that: * apply-inbound-acl (sofia.c): if (profile->acl_count) { uint32_t x = 0; int ok = 1; char *last_acl = NULL; const char *token = NULL; for (x = 0; x < profile->acl_count; x++) { last_acl = profile->acl[x]; if ((ok = switch_check_network_list_ip_token(network_ip, last_acl, &token))) { if (profile->acl_pass_context[x]) { acl_context = profile->acl_pass_context[x]; } break; } if (profile->acl_fail_context[x]) { acl_context = profile->acl_fail_context[x]; } else { acl_context = NULL; } } if (ok) { if (token) { switch_set_string(acl_token, token); } if (sofia_test_pflag(profile, PFLAG_AUTH_CALLS)) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "IP %s Approved by acl \"%s[%s]\". Access Granted.\n", network_ip, switch_str_nil(last_acl), acl_token); switch_set_string(sip_acl_authed_by, last_acl); switch_set_string(sip_acl_token, acl_token); is_auth = 1; } * apply-register-acl (sofia_reg.c): if (profile->reg_acl_count) { uint32_t x = 0; int ok = 1; char *last_acl = NULL; for (x = 0; x < profile->reg_acl_count; x++) { last_acl = profile->reg_acl[x]; if (!(ok = switch_check_network_list_ip(network_ip, last_acl))) { break; } } if (ok && !sofia_test_pflag(profile, PFLAG_BLIND_REG)) { type = REG_AUTO_REGISTER; Is what I expect (similar behaviour in both cases) crazy to you? Or does it sound right? In the latter case, should I open a JIRA case for somebody to push a fix? I could try to 'fix' it myself (in case you consider it as a bug as I do) but I am not really familiar with C development as well. Thank for your points of view! Regards Florent

3 8

JIRA is now https
by Brian West 08 Mar '14

08 Mar '14

FreeSWITCHers, I would say if you have a problem report it on JIRA, But chances are if you had a problem with https you couldn’t report it on JIRA. So just let me know if you see anything or can’t see anything. :) FYI people are still in the Friday Call… drop by. -- 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)

2 1