- FreeSWITCH-dev - FreeSWITCH Mailing Lists

FreeSWITCH Conference Call Today
by Michael Collins 25 May '11

25 May '11

Hi folks! Today's agenda is here: http://wiki.freeswitch.org/wiki/FS_weekly_2011_05_25 We have a few news items to discuss and if there's time I will share with you the technique I demonstrated for using bind_digit_action in conferences. Talk to you soon, Michael

1 0

No Unique-ID field in BACKGROUND JOB events
by Anton VG 25 May '11

25 May '11

In a while there was a thread (cand find it) where one of the core FS developers mentioned that there always should be an Unique-ID field in the event, so if there is no Unique ID field it can be added. Below is the event with no Unique-ID Event received Event-Name: BACKGROUND_JOB Core-UUID: bae130be-6719-4854-a0ed-2fdbb2477a12 FreeSWITCH-Hostname: lab3 FreeSWITCH-Switchname: lab3 FreeSWITCH-IPv4: 192.168.100.11 FreeSWITCH-IPv6: %3A%3A1 Event-Date-Local: 2011-05-25%2002%3A56%3A20 Event-Date-GMT: Tue,%2024%20May%202011%2021%3A56%3A20%20GMT Event-Date-Timestamp: 1306274180052931 Event-Calling-File: mod_event_socket.c Event-Calling-Function: api_exec Event-Calling-Line-Number: 1424 Job-UUID: 26266606-d9b4-4c9d-9642-792f6912d160 Job-Command: originate Job-Command-Arg: %7BMT-fwd_dst_type%3D'Phone%20No',progress_timeout%3D15,MT-fwd_condition%3DALWAYS,originate_timeout%3D90,MT-fwd_oclid%3DTrue,MT-fwd_dst_tech%3DNUM,MT- fwd_timeout%3DNone,leg_timeout%3D60,origination_caller_id_number%3D433777100,MT-fwd_dst%3D901055490,origination_uuid%3D67829d64-918f-4ecf-8ece-e0b391d05172%7D%5Bsip_h_ X-MT-fwd_dst_tech%3DNUM,sip_h_X-MT-fwd_timeout%3DNone,sip_h_X-MT-fwd_condition%3DALWAYS,continue_on_fail%3Dfalse,leg_a_uuid%3D9c3e5ca3-4081-4cde-8316-6dbd4a1d021c,sip_ h_X-MT-fwd_dst_type%3D'Phone%20No',sip_h_X-MT-fwd_dst%3D901055490,sip_h_X-MT-fwd_oclid%3DTrue%5Dsofia/gateway/fs_local/sip3779050%20%26park Content-Length: 27 -ERR INVALID_NUMBER_FORMAT

3 3

Speex rtpmap negotiation
by Andy Wood 21 May '11

21 May '11

I have client software (Win32 and ARM Linux) which uses an old eXosip and is not doing SDP negotiation properly. The clients use rtpmap:103 and 110 for Speex WB and NB respectively. If the clients call each other then everything is OK as FreeSwitch behaves very well and passes the received rtpmap values forward. Where my difficulty lies is when I use bgapi originate user xxxx yyyy. What happens then is that FreeSwitch then uses 98 and 99 as the rtpmap values, my client does not like it and the call fails with a BYE Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION". I have tried to alter the ianacodes in mod_speex to what I want but it does not work. Please could somebody let me know how to do this as I can't really use G711 due to bandwidth constraints. Thanks Andy.

2 1

Project Announcement and Request for Direction
by Kurtis Heimerl 21 May '11

21 May '11

Hello Freeswitch-dev! I originally sent this email to freeswitch-users, and didn't get a lot of responses. I thought this might be a better list for this discussion. My name is Kurtis Heimerl, and I'm a graduate researcher at the University of California, Berkeley in the Technology and Infrastructure for Emerging Regions (TIER) group under Eric Brewer. We're currently investigating the use of OpenBTS (http://openbts.sourceforge.net/) for providing cellular coverage via low-cost base stations in low-density parts of the world. This project is called The Village Base Station. In support of that project, we're also investigating the use of Freeswitch to support OpenBTS and provide a flexible, extensible, and simple platform for deploying voice/sms/data applications on the basestation itself. Towards this end, I'm asking you, the freeswitch community, for advice and direction on some of our research goals. The basic story is simple. OpenBTS uses a software radio and generic PC to provide cellular service. As a byproduct of this architecture, we also gain the ability to run freeswitch applications "locally" (concurrently with OpenBTS), and take advantage of the benefits this tight coupling provides us. These benefits are numerous; calls/SMS between BTS users can be much cheaper, as they do not use any backhaul bandwidth. Applications can query the system for more information about users, such as location or status. As an example, unlike traditional GSM telephony applications, we are able to query if users are currently available on the network. This could be used to create voice "chat lists", which tell participants which of their friends are currently within cellular range. We foresee 6 features required to support these "local" freeswitch applications on our OpenBTS system. I'm very curious how the freeswitch community feels about these possible additions, as well how they might be implemented. There are a few that are already available in freeswitch, but may be rougher than we would like. These include: 1) Identity: The ability to query for user's status, numbers, etc. This seems simple enough in the existing system. However, we'd like to provide hooks for applications to act on these sign-ons or offs. For instance, an app may hold messages until a phone logs onto the system and push them then. My understanding is that this should be simple, probably hooking onto "SIP presence" events? 2) Storage: Freeswitch currently seems to support only per-application storage, with limited support for cross-application storage (mostly user directories). This is occasionally problematic: one issue we've heard is that it is difficult to place messages into voice mailboxes from other apps. We'd like a more unified storage framework. Or... 3) "Pipes": This is the ability to pass messages between freeswitch apps. This seems pretty well supported though simple dialplan interactions, though the modules themselves may not provide enough functionality. Is there a way to do this inside of apps? I consider this an alternative to the storage framework discussed in #2 Lastly, there are three functions we don't believe are well-supported in freeswitch. These are... 1) Privacy: We expect our BTS to be used in politically sensitive areas. Given this, freeswitch could provide an anonymity layer, providing short term phone/SMS numbers, or directing communications through more secure layers (e.g., Tor). 2) Asynchrony: While freeswitch seems to support basic asynchrony though its event system, I couldn't find any way to delay events for indeterminate times. For instance, we may want to schedule a traffic warning for 1PM every Wednesday to every phone currently on the system. Is there a way to do that currently? 3) SMS: Freeswitch seems to currently support SIP chat messages (using SIMPLE?). We need to either extend OpenBTS to speak SIMPLE, or extend freeswitch to speak OpenBTS's SMS protocol. Neither seems particularly difficult. This will allow our apps to send and receive both voice and SMS messages from users. We believe these core functions will enable a wide variety of BTS applications. I have a laundry list of those, but I'll omit them for sake of space. If any members of the community (that means you!) have any directions, ideas, projects, or thoughts, please pass them on! We're just beginning this part of the project, and getting the lay of the land. Feedback is critical at this point. Thanks!

2 1

Skypopen segfault
by Anton VG 21 May '11

21 May '11

Giovanny, I've got several segfaults of FS, seems they belongs to SKYPOPEN Core was generated by `./freeswitch -core -nc'. Program terminated with signal 11, Segmentation fault. #0 0x00007f53e7234028 in switch_core_session_get_channel (session=0x0) at src/switch_core_session.c:1082 1082 switch_assert(session->channel); (gdb) bt full #0 0x00007f53e7234028 in switch_core_session_get_channel (session=0x0) at src/switch_core_session.c:1082 __PRETTY_FUNCTION__ = "switch_core_session_get_channel" #1 0x00007f53ce23dd0a in dtmf_received (tech_pvt=0x7f53ce470af0, value=0x7f53cd8c6560 "2") at mod_skypopen.c:2138 session = 0x0 channel = 0x0 __func__ = "dtmf_received" #2 0x00007f53ce24a1dd in skypopen_signaling_read (tech_pvt=0x7f53ce470af0) at skypopen_protocol.c:537 read_from_pipe = "CALL 41977 DTMF 2", '\000' <repeats 4078 times> message = "CALL\000\064\061\071\067\067\000DTMF\000\062", '\000' <repeats 4078 times> message_2 = "CALL 41977 DTMF 2", '\000' <repeats 4078 times> buf = 0x0 obj = "CALL", '\000' <repeats 507 times> id = "41977", '\000' <repeats 506 times> prop = "DTMF", '\000' <repeats 507 times> value = "2", '\000' <repeats 510 times> where = 0x0 stringp = 0x7f53cd8c6d68 a = 18 howmany = 18 i = 17 __func__ = "skypopen_signaling_read" #3 0x00007f53ce236c65 in skypopen_signaling_thread_func (thread=0x7f53d80a6378, obj=0x7f53ce470af0) at mod_skypopen.c:1399 tech_pvt = 0x7f53ce470af0 res = 0 forever = 1 event = 0x0 __func__ = "skypopen_signaling_thread_func" #4 0x00007f53e72e1317 in dummy_worker (opaque=0x7f53d80a6378) at threadproc/unix/thread.c:138 thread = 0x7f53d80a6378 #5 0x00007f53e67628ba in start_thread () from /lib/libpthread.so.0 No symbol table info available. #6 0x00007f53e5c8e02d in clone () from /lib/libc.so.6 No symbol table info available. #7 0x0000000000000000 in ?? () No symbol table info available. (gdb)

2 6

RTCP patch to send source reports in the RECV_RTCP_MESSAGE event
by Guillaume Binet 21 May '11

21 May '11

Hi all, Please find attached a patch that parses and add RTCP source reports and added the info to the corresponding the switch event. It adds the following headers, numbered by source : Event arrived : RECV_RTCP_MESSAGE Event Header : Event-Name -> RECV_RTCP_MESSAGE Event Header : Core-UUID -> 649cbe4e-7bb8-4edd-a0f5-2662246966f8 Event Header : FreeSWITCH-Hostname -> sal Event Header : FreeSWITCH-IPv4 -> 192.168.0.89 Event Header : FreeSWITCH-IPv6 -> ::1 Event Header : Event-Date-Local -> 2010-06-29 12:11:00 Event Header : Event-Date-GMT -> Tue, 29 Jun 2010 10:11:00 GMT Event Header : Event-Date-Timestamp -> 1277806260737911 Event Header : Event-Calling-File -> mod_sofia.c Event Header : Event-Calling-Function -> sofia_read_frame Event Header : Event-Calling-Line-Number -> 907 Event Header : Unique-ID -> 4fa7d00b-64f2-47ff-b2db-266943ee5fe2 Event Header : SSRC -> 402076d6 Event Header : NTP-Most-Significant-Word -> 3486795060 Event Header : NTP-Least-Significant-Word -> 3111085330 Event Header : RTP-Timestamp -> 40160 Event Header : Sender-Packet-Count -> 246 Event Header : Octect-Packet-Count -> 39360 Event Header : Last-RTP-Timestamp -> 39840 Event Header : RTP-Rate -> 8000 Event Header : Capture-Time -> 1277806260738059 --> HERE Event Header : Source0-SSRC -> 18320497 Event Header : Source0-Fraction -> 0 Event Header : Source0-Lost -> 0 Event Header : Source0-Highest-Sequence-Number-Received -> 40032 Event Header : Source0-Jitter -> 5 Event Header : Source0-LSR -> 0 Event Header : Source0-DLSR -> 0 Guillaume BINET. Guillaume Binet Mobile: +32 487 57 35 81 Fax: +32 2 223 01 15 Ch. de la Hulpe 181 Terhulpsesteenweg Bruxelles B-1170 Brussel www.mondialtelecom.be To discover the innovation of Mondial Telecom, becherry.be

4 3

SIP fantom calls, when calling disconnected SIP endpoint. EP called when plugged in. suppose bug?
by Anton VG 21 May '11

21 May '11

While emulating end-user behavior, encountered a problem. When there is a call to the SIP endpoint, which have disappeared (power unplugged), SOFIA queues the call and calls that endpoint, if it's plugged IN back, within origination_timeout interval. So it means, that there is NO job UUID (I kill all job uuid's by UUID_kill, no show calls, no show channels. But still - I do plug my phone back, it registers to FS, and in 10 seconds I'm receiving a call to it! Reproducibility 100% How to reproduce: Register an endpoint. Unplug the power, so registration persists in FS I do 'originate' a call to a SIP endpoint and &park as shown originate {ringback='%(2000,4000,440.0,480.0)',origination_caller_id_number=907388397,originate_timeout=60,origination_uuid=f84558f4-46e9-4f8a-a546-7edfd6fd0d5e,leg_timeout=60}[continue_on_fail=false,leg_a_uuid=bb744c31-92cf-47d1-aaeb-1c984cb4d599]sofia/internal/sip:sip3779100@192.168.5.21:5062;fs_nat=yes;fs_path=sip%3Asip3779100%40192.168.5.21%3A5062 &park than System attempts to call that endpoint, wait for 4 seconds, disconnect. Kill all job UUIDs, which was originating the call. than plug in the phone, and in 10 seconds there is an incoming call. Just discovered: If i do not kill the JOB UUIDs - than, when phantom call happens, I can see the debug: 2011-05-19 19:59:56.662932 [WARNING] sofia_reg.c:1241 SIP auth challenge (REGISTER) on sofia profile 'internal' for [sip3779100(a)192.168.100.11] from ip 192.168.5.21 2011-05-19 20:00:08.182927 [INFO] sofia.c:748 sofia/internal/sip:sip3779100@192.168.5.21:5062 Update Callee ID to "Outbound Call" <sip3779100> 2011-05-19 20:00:08.252929 [DEBUG] sofia.c:4770 Channel sofia/internal/sip:sip3779100@192.168.5.21:5062 entering state [proceeding][180] 2011-05-19 20:00:08.252929 [NOTICE] sofia.c:4848 Ring-Ready sofia/internal/sip:sip3779100@192.168.5.21:5062! 2011-05-19 20:04:24.822927 [DEBUG] switch_channel.c:2592 (sofia/internal/sip:sip3779100@192.168.5.21:5062) Callstate Change RINGING -> HANGUP 2011-05-19 20:04:24.822927 [NOTICE] mod_commands.c:2117 Hangup sofia/internal/sip:sip3779100@192.168.5.21:5062 [CS_CONSUME_MEDIA] [NORMAL_CLEARING] 2011-05-19 20:04:24.822927 [DEBUG] switch_channel.c:2608 Send signal sofia/internal/sip:sip3779100@192.168.5.21:5062 [KILL] 2011-05-19 20:04:24.822927 [DEBUG] switch_core_session.c:1114 Send signal sofia/internal/sip:sip3779100@192.168.5.21:5062 [BREAK] 2011-05-19 20:04:24.822927 [CONSOLE] switch_cpp.cpp:1197 API cmd result: [+OK ]2011-05-19 20:04:24.822927 [DEBUG] mod_python.c:186 Finished calling python script 2011-05-19 20:04:24.822927 [DEBUG] switch_cpp.cpp:988 sofia/external/907388397(a)10.34.0.4 destroy/unlink session from object 2011-05-19 20:04:24.822927 [DEBUG] switch_core_state_machine.c:497 Hangup Command with Session python(cleanup f84558f4-46e9-4f8a-a546-7edfd6fd0d5e): If I KILL the uuids by api hangup hook - there is no DEBUG, but still the call... 2011-05-19 20:04:24.822927 [CONSOLE] switch_cpp.cpp:1197 hangup hook, UUIDS: f84558f4-46e9-4f8a-a546-7edfd6fd0d5e 2011-05-19 20:04:24.822927 [CONSOLE] switch_cpp.cpp:1197 API cmd: [uuid_setvar f84558f4-46e9-4f8a-a546-7edfd6fd0d5e disposition ORIGINATOR_CANCEL] 2011-05-19 20:04:24.822927 [CONSOLE] switch_cpp.cpp:1197 API cmd result: [+OK ]2011-05-19 20:04:24.822927 [CONSOLE] switch_cpp.cpp:1197 API cmd: [uuid_kill f84558f4-46e9-4f8a-a546-7edfd6fd0d5e] show version FreeSWITCH Version 1.0.head (git-fccbba5 2011-05-18 19-00-42 -0400) Seems JOB is detached from UUID - but still not killed itself.

3 10

SIP endpoint can be registered several times
by Anton VG 19 May '11

19 May '11

Just noted an issue (or feature :) - I ve been switching on/off my sip phone by powering it on/off from power plug, and now it's registered several time with the same properties. I suppose that is kind of strange. I found that whle looking for a reason, why there is more than a single UUID on originate, while originating a single end point. Should I report the given on JIRA? freeswitch@lab3> sofia_contact sip3779100 sofia/internal/sip:sip3779100@192.168.5.21:5062;fs_nat=yes;fs_path=sip%3Asip3779100%40192.168.5.21%3A5062,sofia/internal/sip:sip3779100@192.168.5.21:5062;fs_nat=yes;fs_path=sip%3Asip3779100%40192.168.5.21%3A5062,sofia/internal/sip:sip3779100@192.168.5.21:5062;fs_nat=yes;fs_path=sip%3Asip3779100%40192.168.5.21%3A5062,sofia/internal/sip:sip3779100@192.168.5.21:5062;fs_nat=yes;fs_path=sip%3Asip3779100%40192.168.5.21%3A5062 freeswitch@lab3>

4 9

FreeSWITCH Conference Call Today
by Michael Collins 18 May '11

18 May '11

Hello all! Today's agenda is here: http://wiki.freeswitch.org/wiki/FS_weekly_2011_05_18 It's a bit light but there are a few things to talk about. Please bring your questions for discussion. Thanks, MC

1 0

unable to access jira
by Anton VG 18 May '11

18 May '11

Curios, I'm unable to access Jira for several days, and direct connection failed. I have tried through iranprox.com and anonymizer.ru to make sure it's not my local routing problem - the same result - timeout. Is it down? --------- ERROR The requested URL could not be retrieved While trying to retrieve the URL: http://jira.freeswitch.org/ The following error was encountered: Read Error The system returned: (104) Connection reset by peer An error condition occurred while reading data from the network. Please retry your request.

3 5