Re: [SR-Users] Proposal to extend acc/dialog modules in order to log CDRs
Hello, On 2/1/11 8:18 PM, Timo Reimann wrote: [...] Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. From header URI is not accounted automatically, you can specify any variable that can contain caller id as you need (e.g., it can be an AVP that you previously set for in config) -- see *_extra parameters of acc module. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. Not sure what you mean here with "acc module will make sure ...", but I hope is not going to be cross reference/dependency, so that acc has to walk through dlg structures. This way, users may define CDR fields to their personal needs from the configuration file in a flexible manner. In order to accomplish this, the dialog module would need to be extended such that dialog-specific data may be stored for the duration of a dialog (which is not possible to this day AFAICS). Carsen committed some code in this regard in his IMS branch, as I could see from commit log, check: http://lists.sip-router.org/pipermail/sr-dev/2011-January/010197.html Probably it will be merged sometime in the near future. A new setter function attached to the dialog interface (struct dlg_binds) could accept a simple key/value pair for storage purposes. Exporting this function to the configuration file and accompanying it with a corresponding getter function will ensure that dialog-specific data may be written and read generically. Thus, improvements to the dialog module may be leveraged not just for CDR-accounting purposes. Regarding the acc module, a couple of new features need to be implemented: First, the introduction of another module parameter called something like "cdr_fields" that comprises the set of key names designated for CDR inclusion. Hence, a line like modparam("acc", "cdr_fields", "caller, callee, foo, bar") The db_extra has the format of 'key=variable', where the 'key' is the db column name and the 'variable' is the name of PV holding the value to be stored. I think the format is better than just providing the names of the dialog keys. would require Kamailio configurators to store dialog-specific values for the keys "caller", "callee", "foo", and "bar", respectively, during call processing. The values will be fed to the dialog structure employing the new dialog store function explained above. I think exporting anything related to dialog via PV and fetching them like this will be better from point of view of cross-relationships. Second, when the acc module is in CDR mode, dialogs shall be tracked from creation to termination using dialog callbacks. On termination of a dialog, values from keys referenced in the "cdr_fields" parameter will be fetched from the terminating dialog structure and associated with the new, fresh CDR. Third, the CDR is persisted to either log file, database, or both. If this new thing is not going to support what acc module API has for backends (radius is missing), then will not make sense to tie the two. dialog module can do its accounting alone. Note that my approach would not touch the existing acc module functionality: CDR mode is supposed to be working in addition to transaction-based accounting as people will likely want to keep transaction logs for debugging or similar needs. A flag would enable and disable CDR generation at will. I have not fully investigated re-usability possibilities but believe that acc's persistence functions may be taken advantage of by the new CDR-producing parts as well. That's it with regards to the basic mode of operation. I am also thinking of having a few other features, such as using a switch to set the call start time to the moment the ACK or OK is seen instead of the INVITE (because users shouldn't be billed for call setup times). Looking forward to seeing your feedback on this proposal. As general observation, there are some modules (I mainly think about presence) that have cross references/dependencies that should be avoided normally, and planned to clean it up already. It is not good to have A uses/needs B and B uses/needs A Regarding db accounting: - I have in my todo list the plan to enhance acc to export a functions like acc_start() and acc_stop(), with the goal of storing the initial record for start of the call (acc_start() for INVITE) then at the end of the call (BYE) acc_stop() will just set extra details (end time, duration, etc) - practically then dialog module can call acc_start() and
Re: [SR-Users] t_local_replied() ?
argh. I just mixed up the true/false return values in the eMail but you still got it :-) Thanks a lot! - Original Message - From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] To: Bernhard Suttner [mailto:bernhard.sutt...@winet.ch] Cc: sr-users@lists.sip-router.org Sent: Tue, 01 Feb 2011 20:31:17 +0100 Subject: Re: [SR-Users] t_local_replied() ? > Hello, > > not sure if you ask about the options, or you tried them and don't give > you the needed feature, since there are some improper true/false return > codes in your email. t_branch_replied() will return false if the 408 is > generated locally. > > Cheers, > Daniel > > On 2/1/11 8:25 PM, Bernhard Suttner wrote: > > Hi, > > > > just to be sure: > > > > - If the gateway does send back a 100 Trying and then a 408 is detected > within failure_route the method t_branch_replied does return false (means: > gateway is up and running) - dont go to next gateway (dispatcher) > > > > - If the gateway does not respond and a 408 is detected within > failure_route (= 408 was generated from kamailio) t_branch_replied does > return true (means: gateway is down) - go to the next gateway (dispatcher) > > > > Is that correct or am I wrong? > > > > Best regards, > > Bernhard > > > > > > > > - Original Message - > > From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] > > To: Bernhard Suttner [mailto:bernhard.sutt...@winet.ch] > > Cc: sr-users@lists.sip-router.org > > Sent: Tue, 01 Feb 2011 13:30:54 +0100 > > Subject: Re: [SR-Users] t_local_replied() ? > > > > > >> Hello, > >> > >> On 2/1/11 12:08 PM, Bernhard Suttner wrote: > >>> Hi, > >>> > >>> I am using the dispatcher module and want to check within the > >> failure_route if the 408 was internally generated from kamailio or it was > >> received from the dispatcher gateway. > >>> There was previously a function called t_local_replied() in the > TM-module > >> but I could not find this function in the current documentation. Was it > >> removed? > >>> Is there a alternative to check if the 408 was local generated or if it > >> was received from the peer (= from the dispatcher gateway)? > >> see the example of: > >> http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied > >> > >> Cheers, > >> Daniel > >> > >> -- > >> Daniel-Constantin Mierla > >> http://www.asipto.com > >> > >> > > ___ > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > > sr-users@lists.sip-router.org > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_local_replied() ?
Hello, not sure if you ask about the options, or you tried them and don't give you the needed feature, since there are some improper true/false return codes in your email. t_branch_replied() will return false if the 408 is generated locally. Cheers, Daniel On 2/1/11 8:25 PM, Bernhard Suttner wrote: Hi, just to be sure: - If the gateway does send back a 100 Trying and then a 408 is detected within failure_route the method t_branch_replied does return false (means: gateway is up and running) - dont go to next gateway (dispatcher) - If the gateway does not respond and a 408 is detected within failure_route (= 408 was generated from kamailio) t_branch_replied does return true (means: gateway is down) - go to the next gateway (dispatcher) Is that correct or am I wrong? Best regards, Bernhard - Original Message - From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] To: Bernhard Suttner [mailto:bernhard.sutt...@winet.ch] Cc: sr-users@lists.sip-router.org Sent: Tue, 01 Feb 2011 13:30:54 +0100 Subject: Re: [SR-Users] t_local_replied() ? Hello, On 2/1/11 12:08 PM, Bernhard Suttner wrote: Hi, I am using the dispatcher module and want to check within the failure_route if the 408 was internally generated from kamailio or it was received from the dispatcher gateway. There was previously a function called t_local_replied() in the TM-module but I could not find this function in the current documentation. Was it removed? Is there a alternative to check if the 408 was local generated or if it was received from the peer (= from the dispatcher gateway)? see the example of: http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_local_replied() ?
Hi, just to be sure: - If the gateway does send back a 100 Trying and then a 408 is detected within failure_route the method t_branch_replied does return false (means: gateway is up and running) - dont go to next gateway (dispatcher) - If the gateway does not respond and a 408 is detected within failure_route (= 408 was generated from kamailio) t_branch_replied does return true (means: gateway is down) - go to the next gateway (dispatcher) Is that correct or am I wrong? Best regards, Bernhard - Original Message - From: Daniel-Constantin Mierla [mailto:mico...@gmail.com] To: Bernhard Suttner [mailto:bernhard.sutt...@winet.ch] Cc: sr-users@lists.sip-router.org Sent: Tue, 01 Feb 2011 13:30:54 +0100 Subject: Re: [SR-Users] t_local_replied() ? > Hello, > > On 2/1/11 12:08 PM, Bernhard Suttner wrote: > > Hi, > > > > I am using the dispatcher module and want to check within the > failure_route if the 408 was internally generated from kamailio or it was > received from the dispatcher gateway. > > > > There was previously a function called t_local_replied() in the TM-module > but I could not find this function in the current documentation. Was it > removed? > > > > Is there a alternative to check if the 408 was local generated or if it > was received from the peer (= from the dispatcher gateway)? > see the example of: > http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Radius and kamailio: avp unknown attribute
On 2/1/11 6:12 PM, Dominguez Jover, Ricardo wrote: Solved, bad dictionary Good to know you got it working and thanks for reporting back, this helps a lot people reading later the mailing list archive. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Proposal to extend acc/dialog modules in order to log CDRs
Hi all, I'd like to bring forward a proposal for creating CDRs (Call Data Records) from Kamailio by means of extending both acc and dialog modules. Feedback is very welcome. So far, CDR generation requires post-processing of log entries created by the (transaction-based) acc module or some other means. Looking at OpenSIPS (which is already capable of producing CDRs), my idea is to copy the basic notion of tracking dialogs for to-be-accounted calls and log a proper CDR on termination. Creating basic CDRs including start time, end time, and call duration can be accomplished quite easily this way. Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. This way, users may define CDR fields to their personal needs from the configuration file in a flexible manner. In order to accomplish this, the dialog module would need to be extended such that dialog-specific data may be stored for the duration of a dialog (which is not possible to this day AFAICS). A new setter function attached to the dialog interface (struct dlg_binds) could accept a simple key/value pair for storage purposes. Exporting this function to the configuration file and accompanying it with a corresponding getter function will ensure that dialog-specific data may be written and read generically. Thus, improvements to the dialog module may be leveraged not just for CDR-accounting purposes. Regarding the acc module, a couple of new features need to be implemented: First, the introduction of another module parameter called something like "cdr_fields" that comprises the set of key names designated for CDR inclusion. Hence, a line like modparam("acc", "cdr_fields", "caller, callee, foo, bar") would require Kamailio configurators to store dialog-specific values for the keys "caller", "callee", "foo", and "bar", respectively, during call processing. The values will be fed to the dialog structure employing the new dialog store function explained above. Second, when the acc module is in CDR mode, dialogs shall be tracked from creation to termination using dialog callbacks. On termination of a dialog, values from keys referenced in the "cdr_fields" parameter will be fetched from the terminating dialog structure and associated with the new, fresh CDR. Third, the CDR is persisted to either log file, database, or both. Note that my approach would not touch the existing acc module functionality: CDR mode is supposed to be working in addition to transaction-based accounting as people will likely want to keep transaction logs for debugging or similar needs. A flag would enable and disable CDR generation at will. I have not fully investigated re-usability possibilities but believe that acc's persistence functions may be taken advantage of by the new CDR-producing parts as well. That's it with regards to the basic mode of operation. I am also thinking of having a few other features, such as using a switch to set the call start time to the moment the ACK or OK is seen instead of the INVITE (because users shouldn't be billed for call setup times). Looking forward to seeing your feedback on this proposal. Cheers, --Timo ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Radius and kamailio: avp unknown attribute
Solved, bad dictionary Thanks ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Trunk connection asterisk-kamailio
Hello, On 1/31/11 1:25 PM, Mino Haluz wrote: Hi, I have a question about kamailio-asterik interconnection. I'd like to connect 1000 numbers with a trunk, but it would be painful to add 1000 trunks on asterisk. Do you have some idea how could I group those numbers into one trunk connected to kamailio? asterisk and kamailio configuration settings. see mtree (or pdt) or dialplan modules. You can map these numbers to an unique id (trunk). The using permissions you can have restrictions for who can use/call these numbers (matching trunk id with tag attribute). Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] t_local_replied() ?
Hello, On 2/1/11 12:08 PM, Bernhard Suttner wrote: Hi, I am using the dispatcher module and want to check within the failure_route if the 408 was internally generated from kamailio or it was received from the dispatcher gateway. There was previously a function called t_local_replied() in the TM-module but I could not find this function in the current documentation. Was it removed? Is there a alternative to check if the 408 was local generated or if it was received from the peer (= from the dispatcher gateway)? see the example of: http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] t_local_replied() ?
Hi, I am using the dispatcher module and want to check within the failure_route if the 408 was internally generated from kamailio or it was received from the dispatcher gateway. There was previously a function called t_local_replied() in the TM-module but I could not find this function in the current documentation. Was it removed? Is there a alternative to check if the 408 was local generated or if it was received from the peer (= from the dispatcher gateway)? Thanks in advance! Best regards, Bernhard ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Radius and kamailio: avp unknown attribute
Hi everybody, I have a problem with Kamalio and Radius, when a try to authenticate a user I get the following: Feb 1 11:50:48 kamailiodes /usr/local/kamailio-3.1/sbin/kamailio[5941]: rc_avpair_new: unknown attribute 5 Feb 1 11:50:48 kamailiodes /usr/local/kamailio-3.1/sbin/kamailio[5941]: ERROR: auth_radius [sterman.c:412]: authorization failed In fact I can't see any packet sended to the Radius Server from Kamailio. I've read several posts and I've chmod of /var/run/radius.seq, include dictionary.sip in dictionary.radius and so on. Changing "if (!radius_www_authorize("$td"))" with " if (!radius_www_authorize(""))" I don't get any error but and can't neither see any packet sended to the Radius Server. I've checked the connection between radius client and radius server and it's OK, I get: Received response ID 91, code 2, length = 211 Any help would be appreciated. Kind regards, Ricardo Dominguez ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users