Hello,
there were old and recent discussions about the representation of time
in accounting records. At this moment the acc module stores the unix
timestamp as datetime value.
In some countries is required to store more accuracy, beyond the
seconds. Also, the datetime gives some troubles with converting back to
unix timestamp, specifically with time zones and daylight saving times.
I want to open a discussion that is visible for all users and devs,
being something affecting probably everyone, input from anyone that is
interested being relevant to select the right approach.
Here are some suggestions presented so far.
1) store seconds.miliseconds as double - there is a patch (which
probably needs some tunings itself) on tracker. The precision is shifted
from seconds to milliseconds. Internally computed from microseconds from
timeval structure. The other modules might need updates (iirc dbtext has
only 2 decimals precisions for double, while miliseconds will require at
least three -- could be the case for flatstore or other modules).
Advantage is the computing of duration directly by subtraction of two
values.
2) store seconds and microseconds as two separate values. Should be no
issues with existing modules. Even more accuracy than above, no issues
with other modules, but will require to use two columns (thus four
values to compute the duration)
Any other suggestions?
Personally, at this moment, I will go with 2), but that might not meet
everyone's needs. So a solution can be to make it configurable, as a
bitmask of what time representation to store.
Say, there will be a new parameter timestamp_mode for acc module:
- bit one set - store seconds timestamp as for now (default)
- bit two set - store seconds and microseconds in separate integer columns
- bit three set - store seconds.miliseconds as double value in one column
I could add the parameter and tune acc for bit one and two. For bit
three a deeper review is needed for other modules, probably the
developer that submitted to the tracker can do it.
More suggestions? Pro or cons opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24016, 2013
* http://asipto.com/u/katu *
Hi
I'm using presence on Kamailio 4.0.3. I have in the cfg file:
modparam("presence", "timeout_rm_subs", 0) to cope with unreliable
networks. I have tried setting it to 1, but I saw sometimes server and
client got out of sync, i.e. server removed active_watcher entries when
NOTIFYs time out, while clients still thought the SUBSCRIBE dialogs are
alive.
Now I have a problem when client re-registers with different local
IP/port (e.g. changing between wifi and ethernet, or simply crashed and
rebooted), and sends new REGISTER and SUBSCRIBEs using the new local
IP/port. In this case Kamailio still sends NOTIFYs to the old registered
IP:port (as well as to the new one). NOTIFYs to old IP:port last until
expiration it seems. Even though the stale location has been removed
from the location table.
I have a DB trigger to "SET expires=UNIX_TIMESTAMP()" to the
corresponding active_watchers entries as well, when contact is removed
from location table.
So the DB tables have been updated to contain only entries with client's
new IP:port, but it seems that the SUBSCRIBE dialogs are kept in the
memory until expiration, even though they have been expired in the
active_watchers table.
My question is: is there any ways that I can stop all the NOTIFY
messages from being sent to the stale locations, i.e. remove these
SUBSCRIBE dialogs from memory?
Thank you!
Yufei
--
Yufei Tao
Red Embedded
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message.
You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender.
Red Embedded Design, Company Number 06688253 Registered in England: The Waterfront, Salts Mill Rd, Saltaire, BD17 7EZ
Hello,
being requested several times and as I did get to do some acc work, I
added the code for storing dialog-based cdrs to database. But I had no
time to setup a testbed for it, hopefully those interested in the
feature will help testing a bit.
It follows closely the same logic as writing cdrs to syslog. You have to
create table acc_cdrs (see utils/kamctl/mysql/acc-create.sql), then add
extra columns as you need. The attribute name in cdr_extra has to match
the column name (the type for extra columns have to be string/varchar).
In kamailio.cfg you have to set the cdrs_table parameter to acc_cdrs.
One odd by now is that duration column is also string, because is how
existing code (for syslog writing) stored in internally -- plan to
change it in the near future, for now sql gives the tools for converting.
More details can be found in acc module readme:
- http://kamailio.org/docs/modules/devel/modules/acc.html
Let me know the results, to tune it properly.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
Can anybody suggest me whether kamailio 4.0.3 supports pidf format for
handling presence related stuff instead of XCAP server.If yes what are the
corrosponding changes in the kamaolio cfg file?
If not, then how can I test my kamailio presence with XCAP functionality
with a browser based client like SIPML5.Actually I want the XCAP related
stuff instead of pidf which is currently available in Dubango SIPML5
Hello,
I am having difficulties with one of my SIP Trunk providers who insists
that the dropped calls are my fault. Long story short, I send the final
ACK for the INVITE 200 OK messages to the provider's SBC and 15% of the
time the provider's SBC just drops the packet without any justification.
I read through RFC 3261 and as near as I can tell, my packets conform to
RFC3261. The only thing that seems to not conform is in " 13.2.2.4 2xx
Responses" paragraph 4, sentence 4. " The ACK MUST contain the same
credentials as the INVITE."
I am using the UAC module to do authentification. How do I get UAC to
add the same credentials to the ACK as it did to the INVITE ?
I am using Kamailio as a load balancer ( module dispatcher ).
Thanks in advance.
David
Here is my awesome failure route :
failure_route[FAIL_ONE] {
if ( t_check_status("401|407") )
{
if ( isflagset(11) )
{
t_reply("503", "Authentication failed");
break;
}
if (uac_auth())
{
setflag(11);
t_on_failure("FAIL_AUTH");
append_branch();
t_relay();
}
}
if (t_is_canceled()) {
exit;
}
}
hello,
i'm searching documentation/publications/blogs howto make distributed
architecture with kamailio
- spread over several datacenters
- highly available
- N+1
p.s. i know google, but i'm sure in your bookmarks are hidden more
"valuable" links
--
---------------------------------------
Marek Cervenka
=======================================
Hello, with outgoing white list/black list I am able to put a prefix in the user preference table to block certain out going calls. In the same way is it possible to block incoming calls depending on certain prefixes ( like 1-800)?
Regards,
A
Hi,
At the moment I use kamailio to handle registrations. I have multiple
Asterisk servers behind this, is it possible to forward registrations on to
these servers? Is there a good way to do this?
Thanks,
Keith
