Hi all,
In a previous post I was alerted to the (perhaps obvious) fact that that ims_charging module is design to run within an IMS environment: http://lists.sip-router.org/pipermail/sr-users/2015-January/086675.html
I have subsequently attempted to modify the module to work with the standard usrloc Kamailio module. I decided to branch from the 4.2.2 release rather than the master since I was unsure of the state of the ims_charging module in the master. It now compiles fine and installs. I also have the cdp module talking watchdog_requests to a freeDiameter server so at that level things seem OK.
However inserting the Ro_CCR() call into the kamailio cfg file shows up some problems, primarily: Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: WARNING: usrloc [dlist.c:624]: register_udomain(): Registering a new domain called 'voip.we-rcs.flowcloud.systems' with usrloc Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: ERROR: <core> [db.c:443]: db_check_table_version(): invalid version 0 for table voip.we-rcs.flowcloud.systems found, expected 6 (check table structure and table "version")
Exploring this error leads me to a few questions:
1) The 4.2.2 Ro_CCR() has the diameter domain as a parameter. The addition of this function to my kamailio.cfg file causes ro_fixup() -> domain_fixup() -> ul.register_domain which as per the log above, attempts to look for a table with the same name as the domain. Is it expected that such a table exists, for standard Kamailio I thought all usrloc records simply go into the Location table , regardless of the domain.
2) What is the purpose of the ro_fixup()
3) I notice that the 4.3 module documentation for ims_charging module has 6 parameters for the function call while the example code given in the same section as only 5 (missing domain). The code from the master branch for the function is different again - not sure if 4.3 is still in quite a bit of flux or not for the ims_charging module?
4) Should I be using 4.3 ims_charging module as a starting point or is 4.2.2 good enough i.e are there major changes?
At this stage I am going to create a table for the domain but would like some clarity on how the usrloc and domains relate to table names.
Kind regards Shane
Shane Harrison Senior Software Engineer
Imagination Technologies NZ Limited Level 2 1 Market Grove Lower Hutt, 5010 New Zealand
PO Box 30-449 Lower Hutt, 5040 New Zealand
Phone: +64 4 890-3681 ext 3361
Well further reading :-) and digging has allowed me to understand that the 'location' table is used because of the save('location') call. The ims_charging_module assumes that a table will exist with the same name as the domain specified in the Ro_CCR().
Interestingly, I wasn't successful in using a table called ' voip.we-rcs.flowcloud.systems' as the db_check_table_version() didn't seem to like the '.' or the '-'. I guess back ticks aren't being used in the SQL query. Anyway, for the time being I am specifying a domain that doesn't have either periods or dashes.
My problem now is that no dialog is being found and hence no charging requests are generated. I have set the dialog flag: modparam("dialog_ng", "dlg_flag", 2) if (is_method("INVITE")) { dlg_setflag("2"); xlog("L_DBG","Sending initial CCR Request for call\n"); Ro_CCR("CHARGING_CCR_REPLY", "orig", "SCUR", "", "30","CCR_location"); }
but still get: dialog_ng [dlg_hash.c:924]: get_dlg(): no dialog callid='6428867e-2@192.168.148.30' found
kamcmd does show the dialog with dlg2_list but of course that is later in the SIP messaging flow by the time I look at it.
Anything obvious I am doing wrong that means the dialog isn't found? I am assuming that on reception of the INVITE is when I should do the initial CCR request even though the dialog is not fully formed yet.
Cheers Shane
On 2 February 2015 2:43 p.m, Shane Harrison wrote:
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Shane Harrison Sent: Monday, 2 February 2015 2:43 p.m. To: sr-users@lists.sip-router.org Subject: [SR-Users] Ro_CCR function
Hi all,
In a previous post I was alerted to the (perhaps obvious) fact that that ims_charging module is design to run within an IMS environment: http://lists.sip-router.org/pipermail/sr-users/2015-January/086675.html
I have subsequently attempted to modify the module to work with the standard usrloc Kamailio module. I decided to branch from the 4.2.2 release rather than the master since I was unsure of the state of the ims_charging module in the master. It now compiles fine and installs. I also have the cdp module talking watchdog_requests to a freeDiameter server so at that level things seem OK.
However inserting the Ro_CCR() call into the kamailio cfg file shows up some problems, primarily: Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: WARNING: usrloc [dlist.c:624]: register_udomain(): Registering a new domain called 'voip.we-rcs.flowcloud.systems' with usrloc Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: ERROR: <core> [db.c:443]: db_check_table_version(): invalid version 0 for table voip.we-rcs.flowcloud.systems found, expected 6 (check table structure and table "version")
Exploring this error leads me to a few questions:
- The 4.2.2 Ro_CCR() has the diameter domain as a parameter. The addition of this function to my kamailio.cfg file causes ro_fixup() -> domain_fixup() -> ul.register_domain which as per the log above, attempts to look for a table with the same name as the domain. Is it expected that such a table exists, for standard Kamailio I thought all usrloc records simply go into the Location table , regardless of the domain.
- What is the purpose of the ro_fixup()
- I notice that the 4.3 module documentation for ims_charging module has 6 parameters for the function call while the example code given in the same section as only 5 (missing domain). The code from the master branch for the function is different again - not sure if 4.3 is still in quite a bit of flux or not for the ims_charging module?
- Should I be using 4.3 ims_charging module as a starting point or is 4.2.2 good enough i.e are there major changes?
At this stage I am going to create a table for the domain but would like some clarity on how the usrloc and domains relate to table names.
A little more digging showed that get_dlg() checks callID, fromTag and toTag - clearly this is going to fail if the check is done on an INVITE since the dialog is not yet formed.
So now I am confused - how can the ims_charging function Ro_CCR() be called in my kamailio config script upon receipt of an INVITE and be dependent on having a dialog....... What am I missing here?
Cheers Shane
-----Original Message----- From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Shane Harrison Sent: Tuesday, 3 February 2015 1:40 p.m. To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Ro_CCR function
Well further reading :-) and digging has allowed me to understand that the 'location' table is used because of the save('location') call. The ims_charging_module assumes that a table will exist with the same name as the domain specified in the Ro_CCR().
Interestingly, I wasn't successful in using a table called ' voip.we- rcs.flowcloud.systems' as the db_check_table_version() didn't seem to like the '.' or the '-'. I guess back ticks aren't being used in the SQL query. Anyway, for the time being I am specifying a domain that doesn't have either periods or dashes.
My problem now is that no dialog is being found and hence no charging requests are generated. I have set the dialog flag: modparam("dialog_ng", "dlg_flag", 2) if (is_method("INVITE")) { dlg_setflag("2"); xlog("L_DBG","Sending initial CCR Request for call\n"); Ro_CCR("CHARGING_CCR_REPLY", "orig", "SCUR", "", "30","CCR_location"); }
but still get: dialog_ng [dlg_hash.c:924]: get_dlg(): no dialog callid='6428867e- 2@192.168.148.30' found
kamcmd does show the dialog with dlg2_list but of course that is later in the SIP messaging flow by the time I look at it.
Anything obvious I am doing wrong that means the dialog isn't found? I am assuming that on reception of the INVITE is when I should do the initial CCR request even though the dialog is not fully formed yet.
Cheers Shane
On 2 February 2015 2:43 p.m, Shane Harrison wrote:
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Shane Harrison Sent: Monday, 2 February 2015 2:43 p.m. To: sr-users@lists.sip-router.org Subject: [SR-Users] Ro_CCR function
Hi all,
In a previous post I was alerted to the (perhaps obvious) fact that that
ims_charging module is design to run within an IMS environment:
http://lists.sip-router.org/pipermail/sr-users/2015-January/086675.htm l
I have subsequently attempted to modify the module to work with the
standard usrloc Kamailio module. I decided to branch from the 4.2.2 release rather than the master since I was unsure of the state of the ims_charging module in the master. It now compiles fine and installs. I also have the cdp module talking watchdog_requests to a freeDiameter server so at that level things seem OK.
However inserting the Ro_CCR() call into the kamailio cfg file shows up
some problems, primarily:
Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: WARNING: usrloc [dlist.c:624]: register_udomain(): Registering a new domain called 'voip.we-rcs.flowcloud.systems' with usrloc Feb 2 01:05:52 hh-rcs-sipproxy3 /usr/sbin/kamailio[6473]: ERROR: <core> [db.c:443]: db_check_table_version(): invalid version 0 for table voip.we-rcs.flowcloud.systems found, expected 6 (check table structure and table "version")
Exploring this error leads me to a few questions:
- The 4.2.2 Ro_CCR() has the diameter domain as a parameter. The
addition of this function to my kamailio.cfg file causes ro_fixup() -> domain_fixup() -> ul.register_domain which as per the log above, attempts to look for a table with the same name as the domain. Is it expected that such a table exists, for standard Kamailio I thought all usrloc records simply go into the Location table , regardless of the domain.
- What is the purpose of the ro_fixup()
- I notice that the 4.3 module documentation for ims_charging module has
6 parameters for the function call while the example code given in the same section as only 5 (missing domain). The code from the master branch for the function is different again - not sure if 4.3 is still in quite a bit of flux or not for the ims_charging module?
- Should I be using 4.3 ims_charging module as a starting point or is 4.2.2
good enough i.e are there major changes?
At this stage I am going to create a table for the domain but would like
some clarity on how the usrloc and domains relate to table names.
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
-
Shane Harrison