December 2009 - freeswitch-dev@lists.freeswitch.org

[Freeswitch-dev] When is 1.0.5 due out?
by Mark Sobkow 02 Mar '10

02 Mar '10

I've been advised that the Ubuntu/.deb packaging won't be getting updated until the 1.0.5 release (1.0.4 slipped through the cracks.) I need to know when 1.0.5 is scheduled for release, as we can't ship source builds to our customers, only .deb installations. (The boxes our customers run don't have space on them for doing source builds, and we don't have compilers and such installed on them by default.) Alternatively, if someone could point me to a repo with control files for 1.0.3 or 1.0.4, we could do our own source builds and packaging. I've no fear of tweaking and hacking control files; I just haven't done .deb builds before and starting off from scratch with a project as big as Freeswitch is a bit overwhelming (especially as a "proper" packaging needs to split out the mods, sound packagings, etc.)

5 4

[Freeswitch-dev] thesis on live sip calls migration
by stefano bossi 23 Jan '10

23 Jan '10

Hi all, as promised in #freeswitch-dev I'll try to explain better what I've done and I would like to achieve for my thesis. At the moment I successfully patched sofsip_cli and now it can do something near active call migration :) Thanks to the versatility of nua api I could achieve my objective with little effort. Basically I call someone, then I kill sofsip_cli and I restart it. I launch my "reinvite" command and the call can continue normally. The called client doesn't realize what happened. In this case I write call data in a file and when I launch the reinvite I read directly from this file. Sofsip_cli sends an INVITE message with some TAG appended to the nua_handle. So the called phone thinks to receive an in-session invite and simply refreshes the call, but Sofsip_cli instead allocates all the stuff for a new call. In this way I can avoid to modify directly the RTP part. It seems to be all simpler. I even wrote a little module for FS able to monitor(using the SIP OPTION message) the life of a specific sofia profile.. It's just a proof of concept but it can do failover(without live call migration) between 2 machines in about 50ms. This is possible with these actions: - registrations are shared with odbc - on the start of the module(present only on the backup machine): 1. I set an arp rule blocking the arp response for the virtual IP (set on the primary machine) 2. I set the virtual IP on the backup machine( but no one knows thanks to the arp rule and so I can bind to vIP) 3. I prepare and run the sip profile (on the backup)... loading here the profile permits to save a lot of time during reaction - on the reaction 1. I remove the arp rule 2. I send a gratuitous arp request As I said in about 50ms sip clients can call again. Maybe this time can decrease using NETLINK socket for the arp table. The union of these 2 works will give us a very fast "live profile migration" :D There some points to discuss: - switch_core_session_resurrect_channel: I didn't know this function, I need to understand what it offers, maybe tomorrow ;) - the propagation of call state variables: my first idea was to use the multicast events adding some headers to send all the necessary data (but anthm proposed XML) - I thought only to sofia aspects.. In next days I'll try to understand where to hook in FS to try these ideas. When I'll have something ready (and without very very big errors:) I'll be happy to send you the patch. This is my first work on something real like FS.. I'm opened to any kind of suggestions!* *please contact me for further clarifications Thanks Stefano Bossi

3 5

[Freeswitch-dev] LuaSofia is a Lua binding of Sofia-Sip library (off-topic)
by Paulo Pizarro 07 Jan '10

07 Jan '10

Hi all, We like to present to all Sofia SIP developers a Lua bind to Sofia SIP, Luasofia. The objective of this project is to be able to use Sofia on a more high level language, Lua was chosen because of its easy integration with C, a lot of our projects are starting to use Lua integrated with C to make development and maintenance easier and faster, because of that we wanted to have a good SIP library to use in Lua, the decision was to make a bind to the already mature Sofia library. The bind is far from being complete, we only bonded the code that we need right now, there's a lot of work to do. We expect that the project will be useful, so a lot of documentation was made to help someone who wants to bind more Sofia code. There is good documentation on how to use it too. To develop we used git to make version control, and we hosted the project at github: http://github.com/ppizarro/luasofia The wiki is at github too: http://wiki.github.com/ppizarro/luasofia We hope Luasofia can be useful to a lot of people, and eventually we get some help making it better and more complete. Best regards, Luasofia team

4 6

[Freeswitch-dev] Special Announcement: Latest FreeSWITCH Files
by Michael Collins 31 Dec '09

31 Dec '09

Greetings all! We would like to let everyone know that we have a new place for you to download the latest FreeSWITCH source packages: http://latest.freeswitch.org. The official announcement can be read here<http://www.freeswitch.org/node/225>. Thanks for all your help in making FreeSWITCH a great project and a great community. -Michael

1 0

[Freeswitch-dev] conference member's volume
by vip killa 30 Dec '09

30 Dec '09

is there anyway to auto-balance volume levels of members of the conference? some members seem to be loud and overdrive.

1 0

[Freeswitch-dev] FreeSWITCH Conference Call Starting Shortly!
by Michael Collins 30 Dec '09

30 Dec '09

Please join us today for a special Wednesday edition of the weekly FreeSWITCH conference call: http://wiki.freeswitch.org/wiki/FS_weekly_2009_12_30 -Michael

1 0

[Freeswitch-dev] FS doesn't update rtp port when sdp changed in 200OK response for invite message.
by Lei Tang 30 Dec '09

30 Dec '09

Merry Christmas everyone! I'm using FS 1.0.5pre9, I think there is a bug in mod_sofia when SDP changed in 200 OK response for INVITE message, the scenario is : A(FreeSwitch) B ------INVITE -------> <----100 Tring-------- <----180 Ring -------- with sdp m=audio 55066 RTP/AVP 0 120 c=IN IP4 10.36.143.76 <----UPDATE ------- with sdp m=audio 45486 RTP/AVP 0 120 c=IN IP4 10.36.143.76 -----200 OK ------> response for UPDATE message <---- 200 OK-------- response for INVITE message, with sdp m=audio 45486 RTP/AVP 0 120 c=IN IP4 10.36.143.76 --------ACK ---------> The problem is, B changed the rtp port in UPDATE message and "200 OK" response message, but FS didn't do update, so it still send and receive data from port 55066. I read the mod_sofia source code and debug log, I found that when get 200OK response ,mod_sofia should update rtp session when sdp information is different of the the pre sdp received in 180 ring response, I'm using proxy_media mode, and I think there is the same problem in normal mode. here is the outbound channel state change log ============================== entering state [received][100] entering state [calling][0] entering state [proceeding][180] entering state [proceeding][200] entering state [completing][200] entering state [ready][200] entering state [completed][200] entering state [ready][200] The problem is in state [proceeding][200], The code is as follow: sofia.c line 3876 if (switch_channel_test_flag(channel, CF_PROXY_MEDIA)) { if (sofia_glue_activate_rtp(tech_pvt, 0) != SWITCH_STATUS_SUCCESS) { goto done; } } Since the rtp session is initialized when 180 RING response received, sofia_glue_activate_rtp will return SWITCH_STATUS_SUCCESS without change any thing, So, I think the code should be as follow 3876 if (switch_channel_test_flag(channel, CF_PROXY_MEDIA)) { 3877 if (tech_pvt->rtp_session && !is_dup_sdp){ 3878 sofia_set_flag_locked(tech_pvt, TFLAG_REINVITE); 3879 if (sofia_glue_tech_proxy_remote_addr(tech_pvt) != SWITCH_STATUS_SUCCESS || sofia_glue_activate_rtp(tec h_pvt, 0) != SWITCH_STATUS_SUCCESS) { 3880 sofia_clear_flag_locked(tech_pvt, TFLAG_REINVITE); 3881 goto done; 3882 } 3883 sofia_clear_flag_locked(tech_pvt, TFLAG_REINVITE); 3884 }else{ 3885 if (sofia_glue_activate_rtp(tech_pvt, 0) != SWITCH_STATUS_SUCCESS) { 3886 goto done; 3887 } 3888 } 3889 } When get 200OK reponse and sdp is changed, we should update remote port and set reinvite flag before call sofia_glue_activate_rtp. Because I'm not so familiy with sofia and mod_sofia's source code, this code is only for PROXY MEDIA mode and doesn't check for codec changed.(in my scenario, only the remote port and ip are changed). Could some fs dev check this problem, and give a offical patch? BTW, I guess maybe mod_sofia is just ignore UPDATE message too. (just ignore it if I was wrong) Best Regards -- Lei.Tang lei.tlfly(a)gmail.com

3 4

[Freeswitch-dev] twitter.com/freeswitch (its not ours)
by Brian West 28 Dec '09

28 Dec '09

Dear FreeSWITCHers, Someone has registered the freeswitch name and is squatting on twitter with it. They haven't used it in over a year and I would like to have this for our project as its clearly confusing. If you own this account please contact me off list. Thanks, Brian

1 0

[Freeswitch-dev] pls help
by miracle 2012 28 Dec '09

28 Dec '09

Hi, please provide any example c programs , APIs info, reference as i want to write a dialer in c with freeswitch. i am a newbie for free switch... :| thanks.

4 3

[Freeswitch-dev] Generic Question on switch_rtp.c and STFU
by Erwin Davis 25 Dec '09

25 Dec '09

Hi, I have a question on the time period when stfu_read_a_frame(), which reads a frame from a jiffer buffer within an interval T1, is called. Ideally the frames in the jitter buffer are transmitted within interval T1 to avoid the jitter. However, if I understand the code correctly, the interval is determined by the latency between two read_pollfd triggering instead of T1. The reason is that, at switch_rtp.c, Proc stfu_read_a_frame() is called by read_rtp_packet() which is called when read_pollfd is triggered. However, If I understand correctly, read_pollfd is triggeredd only when there is something on the sockets. For example, if the latency of two read_pollfd triggerings is 50 ms, the actual transmit of next new frame from the jitter buffer should be 50 ms delay instead of T1. Please correct me if I am missing something. Thanks, Regards, e

1 0