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

[Freeswitch-dev] mod_radius_cdr behavior and questions
by Apostolos Pantsiopoulos 12 Feb '09

12 Feb '09

Hi, I am tweaking the mod_radius_cdr module to archive the behavior that most NASes have (i.e. accounting packets are sent in a separate thread so that the submission does not interfere with the execution of the call). While doing that, however, I bumped into another behavior of the module that I think is not desirable (at least by me) : While on a bridge, the module sends one acct start packet at the beginning of the originating leg (on_routing event handler) and two acct stop packets at the end of each leg (inbound and outbound). My opinion is that it should send one accounting start packet at the beginning of each call leg (inbound, outbound) resulting to a total number of two acct start packets. It is generally accepted that acct start/stop packets come in pairs so that billing applications can handle them accordingly. Some NAS's radius radius implementations have some other configuration modes like the Cisco's RADIUS Packet Suppression. When in this mode the Cisco NAS sends only an accounting start/stop pair at the end of a final dialpeer attempt (and suppresses all the previous failed dialpeer attempts) thus resulting to less network traffic. Other NASes (such as MERA MVTS) can send a start/stop pair for each leg OR a start/stop pair for each end to end call, depending on the configuration. Opensips follows the star/stop pair by call leg paradigm. No matter what the implementation, all of them always send a acct start/stop pair. This is a common thing. And all the billing platforms can deal only with paired start/stops. The current module behavior (one start two stops) can complicate things since the radius server would not know how to match the second stop packet with its equivalent start. Before I get the infamous answer "pathes welcomed" I would like to state that I am already involved in changing this behavior (through a patch). So my real question is this : I noticed that the module uses the switch_core_add_state_handler function to register its handler table : switch_core_add_state_handler(&state_handlers); So the on_routing ( or the on_execute) event happens only when the inbound call is started. When the outbound call is initiated no handler is available to hook up a function and send the proper acct start packet. Should the module register its handlers using the switch_channel_add_state_handler() function instead? And if yes, how could the module pass the channel as a parameter to the function since channels are created and destroyed dynamically (and the module when initialized does not have that info). I would greatly appreciate your help in pinpointing a proper way to call my event handling routines on a per call leg basis. -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs(a)kinetix.gr -------------------------------------------

5 26

[Freeswitch-dev] Freeswitch on Debian repository
by Nicholas Santos 06 Feb '09

06 Feb '09

Hi, I'm the current owner of the Freeswitch package on Debian Testing (Lenny). I'm just beginning to package it, if there's something that I should know before I package it, just say it. I'm here to do my best on this that I consider a great step. Thanks in advance, Nicholas Amorim. PS: By the way, what a great piece of software! :)

6 18

[Freeswitch-dev] ANNOUNCEMENT: FreeSWITCH 1.0.3 RC1 Available
by Michael Collins 31 Jan '09

31 Jan '09

The FreeSWITCH development team is happy to announce the immediate availability of FreeSWITCH 1.0.3 RC1. The download is available here: http://files.freeswitch.org/freeswitch-1.0.3RC1.tar.gz More information regarding this release candidate can be found here: http://freeswitch.org/node/159 Please help us out by downloading and running the latest FreeSWITCH release. Thank you all for your continued support of this awesome project! -MC

5 4

[Freeswitch-dev] [RFC] mod_entity
by John Skopis 31 Jan '09

31 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The module is not complete. I am sending it now for some feedback as it might be a good time (mostly completed). The module, mod_entity, will build all xml entities the xml interface supports, currently it only supports directory, and dialplan (partially). The idea is that mod_entity describing xml entities, which are just collections of elements, queries a directory (dbi) for the values it needs to build the xml. mod_directory accepts a char** array of fields, and returns an ordered char ** array of values, the dn (id) of the last entry (row), and how many entries remain. I would like to hear what you think, anthm especially. I know it's not finished code but I am not sure I am in the right direction. For this module to be at all practical the xml created needs to be cached. Lets save this for another thread though. http://jira.freeswitch.org/browse/FSREPO-1 - -John -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJhIuVopIcoit0BmcRCqNQAJ9013ALiephXYqPo3ZnsAR8LgGc8ACglpns iknUUEuRDtPC8Owo8ma0bfs= =KxVd -----END PGP SIGNATURE-----

1 0

[Freeswitch-dev] very early prototype of SLA/BLA
by Matthew Kaufman 31 Jan '09

31 Jan '09

See http://jira.freeswitch.org/browse/MODENDP-179 for how far I've gotten on doing SLA/BLA in the draft-anil-sipping-bla-02/03 style. If the patch is applied and the feature enabled and Polycom phones in use and the phones configured for type="shared" and thirdPartyName="<some extension>", the lights really work. And with a patch Anthony provided to me today to add support for INVITE w/REPLACES, you can even put a call on hold at one phone, go to another phone with a blinking light for that line, and pick it up. (But you can't pick up a second phone with the first still on the call and have them both join the call at the same time via an auto-created conference... yet) Amazing how much work it takes to emulate an old key system. Again, this is a total rough-draft hack of a prototype, just enough to get the lights working, and with at least one major memory leak and/or nua handle leak(s) that cause bad things to happen, so isn't for production at all yet. I will be continuing to work on it myself, but I know this is something that gets requests so I wanted to get the fact that I'm working on it out in the open ASAP. Matthew Kaufman

12 37

[Freeswitch-dev] freeswitch development question (memory allocation?)
by Apostolos Pantsiopoulos 30 Jan '09

30 Jan '09

I have the code below : struct radacct_thread_handle { switch_core_session_t *session; switch_mutex_t *mutex; switch_thread_cond_t *cond; }; static switch_status_t my_on_routing(switch_core_session_t *session){ switch_thread_t *thread; switch_threadattr_t *thd_attr = NULL; switch_memory_pool_t *pool; struct radacct_thread_handle *thread_params = NULL; pool = switch_core_session_get_pool(session); thread_params->session = session; ... } when the program reaches the last line (thread_params->session = session;) I get a core dump. Is this a memory allocation error? Is it because I am making use of the wrong pool? Please enlighten me because I am not an experienced c programmer, and I am struggling to get familiar with the FS API. -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs(a)kinetix.gr -------------------------------------------

3 9

[Freeswitch-dev] getting a session pointer within an event handler
by Apostolos Pantsiopoulos 30 Jan '09

30 Jan '09

How can I get a session pointer within an event handler? I tried to extract the uuid from the event header and then I tried to locate the session using the uuid : static void my_event_handler(switch_event_t *event) { switch_assert(event); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "channel name : %s\n",switch_event_get_header_nil(event, "channel-name")); char* uuid = switch_event_get_header(event, "session-id"); switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_DEBUG, "uuid : %s\n",uuid); switch_core_session_t *session; session = switch_core_session_locate(uuid); switch_assert(session); ... } But the uuid is always null. The events that I am binding my routine is for CHANNEL_CREATE (I tried CHANNEL_EXECUTE too, same result) -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: regs(a)kinetix.gr -------------------------------------------

3 3

[Freeswitch-dev] Recoding G729 raw payload in FreeSWITCH and G729 decoding
by seven du 27 Jan '09

27 Jan '09

Hi FreeSWITCHers, 1) FreeSWITCH support G729 codec in passthrough mode, it is normally engough if both call-legs suport G729. But there is no way to do recording if you can't decode it. I wrote a small module called mod_recpld. The idea is to record the raw payload in rtp packets to files, and decode them into 3rd party converters. See details at: http://code.google.com/p/mod-recpld/ 2) EasyG729A implemented by http://imtelephone.com can be free of use on research purpose, I made a wrapper so it can be used in FreeSWITCH. See deatila at: http://code.google.com/p/libg729/ The code is not good but just works. BTW, I think it maybe easy to store codes on FreeSWITCH svn than on google code, how can I become a developer? Can I get a svn access on svn.freeswitch.org and own a branch?

2 3

Re: [Freeswitch-dev] mod_skypiax inching forward
by seven du 26 Jan '09

26 Jan '09

hi Giovanni, I just made some improve on skypiax, so you can call skypiax/ANY/ another_skypename, it will automatically chose an available channel. not good, but it works. put the following code directly before the following line: for (i = 0; i < SKYPIAX_MAX_INTERFACES; i++) { And change the above line to for (i = 0; !found && i < SKYPIAX_MAX_INTERFACES; i++) { It should be like: if (strncmp("ANY", interface_name, strlen(interface_name)) == 0) { //find an available one, allowing call like originate skypiax/ ANY/another_skypename DEBUGA_SKYPE("Finding one available skype interface\n", SKYPIAX_P_LOG); for (i = 0; !found && i < SKYPIAX_MAX_INTERFACES; i++) { if (strlen(globals.SKYPIAX_INTERFACES[i].name)) { int skype_state = 0; tech_pvt = &globals.SKYPIAX_INTERFACES[i]; skype_state = tech_pvt->interface_state; DEBUGA_SKYPE("skype interface: %d, name: %s, state: %d\n", SKYPIAX_P_LOG, i, globals.SKYPIAX_INTERFACES[i].name, skype_state); if (SKYPIAX_STATE_DOWN == skype_state || 0 == skype_state) { found=1; break; } } } } for (i = 0; !found && i < SKYPIAX_MAX_INTERFACES; i++) { Regards, Seven

5 5

[Freeswitch-dev] Trouble registering SIP client
by Roland Zagler 25 Jan '09

25 Jan '09

Hi everybody, I am writing a Java SIP ua (based on mjsip 1.6) that is supposed to register to freeswitch. Unfortunately I am not able to register and I cannot find the problem, although a softphone (X-Lite) CAN register by using the same creds. The credentials are: SIP username: roland SIP password: roland SIP realm: 10.0.4.60 There is no acl activated. The freeswitch versions I have tested are 1.0.2 and the trunk of today (11480). I hope someone on the list could take a look on the trace I attached below and give me a hint what goes wrong. Thank you very much in advance. Roland tport_wakeup_pri(0x81042c8): events IN tport_recv_event(0x81042c8) tport_recv_iovec(0x81042c8) msg 0xb3415ed8 from (udp/10.0.4.60:5060) has 373 bytes, veclen = 1 recv 373 bytes from udp/[10.0.2.51]:32816 at 17:01:30.461289: ------------------------------------------------------------------------ REGISTER sip:10.0.4.60:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.2.51:32816;rport;branch=z9hG4bK33562 Max-Forwards: 70 To: "roland" <sip:roland@10.0.4.60:5060> From: "roland" <sip:roland@10.0.4.60:5060>;tag=z9hG4bK84430669 Call-ID: 218108472980(a)10.0.2.51 CSeq: 1 REGISTER Contact: <sip:roland@10.0.2.51:32816> Expires: 3600 User-Agent: ZaKoSIP v1.2 Content-Length: 0 ------------------------------------------------------------------------ tport_deliver(0x81042c8): msg 0xb3415ed8 (373 bytes) from udp/10.0.2.51:5060/sip next=(nil) nta: received REGISTER sip:10.0.4.60:5060 SIP/2.0 (CSeq 1) nta: canonizing sip:10.0.4.60:5060 with contact nta: REGISTER (1) going to a default leg nua: nua_stack_process_request: entering nua: nh_create: entering nua: nh_create_handle: entering nua: nua_stack_set_params: entering soa_clone(static::0x80fe270, 0x80f9448, 0xb3402b30) called soa_set_params(static::0xb341ba78, ...) called nua: nua_application_event: entering nua: nua_respond: entering nua(0xb3402b30): sent signal r_respond 2009-01-24 18:01:30 [DEBUG] sofia_reg.c:883 sofia_reg_handle_register() Requesting Registration from: [roland(a)10.0.4.60] nua: nua_handle_destroy: entering nua(0xb3402b30): sent signal r_destroy nua: nua_handle_magic: entering nua: nua_handle_destroy: entering nua: nua_stack_set_params: entering soa_set_params(static::0xb341ba78, ...) called tport_tsend(0x81042c8) tpn = UDP/10.0.2.51:32816 tport_resolve addrinfo = 10.0.2.51:32816 tport_by_addrinfo(0x81042c8): not found by name UDP/10.0.2.51:32816 tport_vsend returned 620 send 620 bytes to udp/[10.0.2.51]:32816 at 17:01:30.586602: ------------------------------------------------------------------------ SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 10.0.2.51:32816;rport=32816;branch=z9hG4bK33562 From: "roland" <sip:roland@10.0.4.60:5060>;tag=z9hG4bK84430669 To: "roland" <sip:roland@10.0.4.60:5060>;tag=aZa7matyy5Uca Call-ID: 218108472980(a)10.0.2.51 CSeq: 1 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-11480 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: timer, precondition, path, replaces WWW-Authenticate: Digest realm="10.0.4.60", nonce="a5608fcc-ea38-11dd-8437-6d678b851040", algorithm=MD5, qop="auth" Content-Length: 0 ------------------------------------------------------------------------ nta: sent 401 Unauthorized for REGISTER (1) nta: timer set to 32000 ms nta_leg_destroy((nil)) soa_destroy(static::0xb341ba78) called tport_wakeup_pri(0x81042c8): events IN tport_recv_event(0x81042c8) tport_recv_iovec(0x81042c8) msg 0xb3444050 from (udp/10.0.4.60:5060) has 575 bytes, veclen = 1 recv 575 bytes from udp/[10.0.2.51]:32816 at 17:01:30.614376: ------------------------------------------------------------------------ REGISTER sip:10.0.4.60:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.2.51:32816;rport;branch=z9hG4bK33562 Max-Forwards: 70 To: "roland" <sip:roland@10.0.4.60:5060> From: "roland" <sip:roland@10.0.4.60:5060>;tag=z9hG4bK84430669 Call-ID: 218108472980(a)10.0.2.51 CSeq: 2 REGISTER Contact: <sip:roland@10.0.2.51:32816> Expires: 3600 User-Agent: ZaKoSIP v1.2 Authorization: Digest username="roland", realm="10.0.4.60", nonce="a5608fcc-ea38-11dd-8437-6d678b851040", uri="sip:10.0.4.60:5060", algorithm=MD5, qop=auth, response="2f26d787c68ac2a342a4b1d7bb49a1a0" Content-Length: 0 ------------------------------------------------------------------------ tport_deliver(0x81042c8): msg 0xb3444050 (575 bytes) from udp/10.0.2.51:5060/sip next=(nil) nta: received REGISTER sip:10.0.4.60:5060 SIP/2.0 (CSeq 2) nta: canonizing sip:10.0.4.60:5060 with contact nta: REGISTER (2) going to a default leg nua: nua_stack_process_request: entering nua: nh_create: entering nua: nh_create_handle: entering nua: nua_stack_set_params: entering soa_clone(static::0x80fe270, 0x80f9448, 0xb3445690) called soa_set_params(static::0xb341ba78, ...) called nua: nua_application_event: entering 2009-01-24 18:01:30 [DEBUG] sofia_reg.c:869 sofia_reg_handle_register() Send challenge for [roland(a)10.0.4.60] nua: nua_respond: entering nua(0xb3445690): sent signal r_respond nua: nua_handle_destroy: entering nua(0xb3445690): sent signal r_destroy nua: nua_handle_magic: entering nua: nua_handle_destroy: entering nua: nua_stack_set_params: entering soa_set_params(static::0xb341ba78, ...) called tport_tsend(0x81042c8) tpn = UDP/10.0.2.51:32816 tport_resolve addrinfo = 10.0.2.51:32816 tport_by_addrinfo(0x81042c8): not found by name UDP/10.0.2.51:32816 tport_vsend returned 500 send 500 bytes to udp/[10.0.2.51]:32816 at 17:01:30.617125: ------------------------------------------------------------------------ SIP/2.0 403 Forbidden Via: SIP/2.0/UDP 10.0.2.51:32816;rport=32816;branch=z9hG4bK33562 From: "roland" <sip:roland@10.0.4.60:5060>;tag=z9hG4bK84430669 To: "roland" <sip:roland@10.0.4.60:5060>;tag=B83Zp5a2UejZN Call-ID: 218108472980(a)10.0.2.51 CSeq: 2 REGISTER User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-11480 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH Supported: timer, precondition, path, replaces Content-Length: 0 ------------------------------------------------------------------------ nta: sent 403 Forbidden for REGISTER (2) nta_leg_destroy((nil)) soa_destroy(static::0xb341ba78) called

3 4