2 Feb
2015
2 Feb
'15
3:42 a.m.
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
3 Feb
3 Feb
2:39 a.m.
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(a)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(a)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:
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.
6:09 a.m.
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(a)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:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-
users(a)lists.sip-router.org http://lists.sip-router.org/cgi-
bin/mailman/listinfo/sr-users
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(a)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:
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.
3580
days inactive
3581
days old
2 comments
1 participants
participants (1)
-
Shane Harrison