Hi, The functionality for storing additional data for a dialog is like this:
$dlg_var(ecscf_server) = ‘sip:ecscf.ng-voice.com’; xlog(“Emergency CSCF is $dlg_var(ecscf_server)\n”); However, it might be worth noting, that i haven't added bindings to the dialog-API and that the Pseudo-Variable currently only supports Strings. I think, my branch needs to exists a little longer, since the changes take quite a lot of time. I am currently doing a lot of cleanup where many methods get obsolete; so i do not want to add docs for later obsolete methods and parameters. I think i will need to check, how i can easily just merge some commits instead of all of them (any hints welcome, otherwise i will ask google...). Kind regards, Carsten 2011/2/2 Timo Reimann <[email protected]>: > On 02.02.2011 14:03, Daniel-Constantin Mierla wrote: >>> On 01.02.2011 21:15, Daniel-Constantin Mierla wrote: >>>> 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. >>> I initially thought about having a cdr_extra parameter similar to >>> log_extra. However, I see a problem with AVPs which live in single >>> transactions to work with dialogs that span multiple transactions. >> >> well, some of the avps are transaction persistent, but there are also >> global avps which are available as long as kamailio runs. None of these >> should be used, I gave avp just as generic PV example. The idea was to >> make new PV available with the data stored by dlg module. > > Ok, so instead of providing getter/setter functions, let's use PVs. > However, users will have varying needs regarding the to-be-defined CDR > fields next to the canonical ones (start time, end time, duration, > etc.). We, for example, use a rather large number of fields, many of > them being too specific for general integration into upstream Kamailio. > That's why I would rather see a way to dynamically specify CDR fields. > Carsten's new code would be the right approach to do this, right? His > dlg_var PV takes arbitrary key/value pairs which looks just like what is > needed. > > >>>>> 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. >>> If I get you right, by cross reference/dependency you mean that A >>> requires B and vice versa, i.e., cyclic dependency. I do not intend to >>> let that happen. >>> >>> Instead, the acc module would use getter functions attached to the >>> dialog interface (which is what I mean by "acc module will make sure"). >>> dialog would never touch the acc module or even know about the fact that >>> the acc module is using it. >> >> But then acc has to know the dialog internals, what the getter function >> will return and how to access those structures. PV framework is exactly >> the same, but available for all components/modules, no need to develop >> specif ones each time. > > Agreed, let's use PVs. If you think of Carsten's new dlg_var PV, it's > basically just a way to get/set arbitrary values; so I suppose this is > what I should have expressed. > > >> With your solution, dialog module has to know acc api to call the >> recording function, and acc has to know dialog module to know its >> exported structures. This is cross dependency imo. > > I think this point shows the major difference between our solutions: My > approach doesn't make the dialog module call the recording function. > Instead, the recording function is called by the acc module as soon as > the dialog terminates where call termination can is observed by means of > using dialog callbacks. (Sorry, I should have possibly mentioned the > words "dialog callback" before.) > > Therefore, module dependency is unidirectional: acc registers for some > dialog callbacks and, upon execution of a callback, records the 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. >>> Of course, I would want to take advantage of acc's existing backend >>> connectors. There's no need to re-invent the wheel, acc will still be >>> responsible for writing out CDRs; the difference is that a few >>> additional calls to a well-defined dialog interface will be used in >>> order to collect the data that constitute the CDR. >> >> What will happen if a new call tracking module will be available, should >> acc be changed again? > > I am not completely convinced that call tracking is such a flexible > thing even though you gave a few examples below. A call is pretty much a > dialog, and proper tracking of a dialog should be dialog module's job. > > Moreover, I believe your approach has some dependency issues as well -- > see my comment at the very end of this mail. > > >>>> - such functionality is independent of dlg module or any new call >>>> tracking extension in the future, also writing full CDR can be achieved >>>> from config file by tracking INVITE and BYE, calling >>>> acc_start()/acc_stop() from cfg >>> Tracking INVITE and BYE messages from the config file may not be enough >>> if you want to create CDRs for failed calls too, e.g., 408/487. >> What stops tracking these replies in the cfg? > > You can do it, but for a large config file with many different paths, > it's easy to miss a spot where you should have added a call to > acc_stop(). On the contrary, if recording happens automatically when the > call ends, you don't have to deal with any manual work. > > >> Anyhow, I think you divert from the initial goal. If you just break the >> message in pieces and reply on each word will lose the meaning of the >> entire content. I presented my plans above and below I added acc_cdr() >> that seems to suit your needs. > > Maybe I got you wrong but my understanding is that acc_start() records > one part of a CDR (start time, etc.) when the INVITE is routed while > acc_stop() finishes it off (end time, duration, etc.) on reception of > the BYE. I was trying to stress that a single call to the recording > function is likely preferred (at least by me), which acc_cdr() seems to > accomplish. > >>>> Therefore if I would do it: >>>> - enhance acc module to export via cfg exports and inter-module api >>>> three functions: >>>> - acc_start() - write the initial call record at start >>>> - acc_stop() - update the call record at stop, based on a matching >>>> condition specified as parameter >>>> - acc_cdr() - write a full CDR >>>> >>>> Data to be written in db (or other backend) is going to be taken from >>>> PVs, independent of who (cfg, dialog, or other module) is calling the >>>> function, specified in a similar form like db_extra. >>>> >>>> First two functions will work for db only. Third can work also without >>>> dialog, e.g., I can store the start of a call, a.s.o. in hash table and >>>> get it at BYE time to build the full cdr. >>> Where would you maintain that hash table containing the call start time >>> and similar data if you do not seek to use the dialog module? Such data >>> seems to be naturally associated to a dialog, so my impression is that >>> it should be kept there too, i.e., in the dialog module. >> The hash table module (htable) keeps the data in shared memory. It is a >> generic container, so you can store anything there. dialog module is >> just an automatic call tracker, handling sip messages passing through >> kamailio. Most of that can be done from config file. Internally, dialog >> module has also a hash table. Also, I can track active calls using a db >> table (in memory or not for speed), with a timer process (rtimer module) >> to handle missing BYEs, and so there could be other options to track >> dialogs. My point here is that acc should be independent of all these >> potential options available now or added in the future. >> >> You additions to dialog module can export the new stored data inside >> dialog via some PV, e.g., >> >> $dlgacc(caller), $dlgacc(callee), $dlgacc(duration), a.s.o. >> >> dialog module will call acc_cdr() when the call ended, making sure the >> PVs are properly available at that time. > > If you call an acc module-provided method from the dialog module, you > face a similar independence problem: Should accounting functionality > ever be changed or replaced of by another module, then you'd need to > change the dialog implementation as well. > > There's a conceptual issue related to the given usage relationship as > well: If component A requires B to implement a particular functionality, > A should use B. Having the dialog module trigger the recording function > puts this concept upside down -- CDR accounting isn't needed by dialog > tracking, it's the other way around. > > > Cheers, > > --Timo > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > -- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany Mobile +49 179 2021244 Home +49 40 34927217 Büro (Verl) +49 5246 801427 Fax +49 40 34927218 mailto:[email protected] _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
