MÉSZÁROS Mihály schrieb:
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
2009/8/24 Daniel-Constantin Mierla :
I am personally aware of companies using Kamailio with several
millions of
subscribers, using kamailio database schema. Also, I am aware of
companies
having more or less same l
Klaus Darilion wrote:
Iñaki Baz Castillo schrieb:
2009/8/24 Daniel-Constantin Mierla :
I am personally aware of companies using Kamailio with several
millions of
subscribers, using kamailio database schema. Also, I am aware of
companies
having more or less same level of subscriber base usin
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#14 - TLS modul problem
User who did this - Anonymous user ()
http://sip-router.org/tracker/index.php?do=details&task_id=14
You are receiving this message because you have reques
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Anonymous user ()
Attached to Project - sip-router
Summary - TLS modul problem
Task Type - Bug Report
Category - tls
Status - Assigned
Assigned To - Andrei Pelinescu-Onciu
Iñaki Baz Castillo schrieb:
2009/8/24 Daniel-Constantin Mierla :
I am personally aware of companies using Kamailio with several millions of
subscribers, using kamailio database schema. Also, I am aware of companies
having more or less same level of subscriber base using SER database schema.
A
On 24.08.2009 16:47 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
No, no caching for above mentioned modules. They simply hide a db
query in most of the cases. They are supposed to deal with quite
large volume of records where caching makes no sense. So you do not
loose any perf
Daniel-Constantin Mierla wrote:
No, no caching for above mentioned modules. They simply hide a db query
in most of the cases. They are supposed to deal with quite large volume
of records where caching makes no sense. So you do not loose any
performance by using sqlops. You can check with bench
On 24.08.2009 16:29 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
Just as a different example, sqlops plus some scripting could
obsolete most of db-connected modules - auth_db, alias_db, speeddial,
uri_db, a.s.o, but doing so is not at all a good decision.
In the case of my imp
On 24.08.2009 16:05 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> :-) -- ahh, yes, imo, srctl sort of exists already, but is called
> kamctl.
are you saying that one can control s modules with kamctl? i know that
one can control both s and k modules with serctl (except for a
Daniel-Constantin Mierla wrote:
Just as a different example, sqlops plus some scripting could obsolete
most of db-connected modules - auth_db, alias_db, speeddial, uri_db,
a.s.o, but doing so is not at all a good decision.
In the case of my implementations, I have to do this quite frequently
On 24.08.2009 15:57 Uhr, Iñaki Baz Castillo wrote:
2009/8/24 Daniel-Constantin Mierla :
I am personally aware of companies using Kamailio with several millions of
subscribers, using kamailio database schema. Also, I am aware of companies
having more or less same level of subscriber base us
Daniel-Constantin Mierla writes:
> :-) -- ahh, yes, imo, srctl sort of exists already, but is called
> kamctl.
are you saying that one can control s modules with kamctl? i know that
one can control both s and k modules with serctl (except for async
t_uac_dlg).
-- juha
___
2009/8/24 Daniel-Constantin Mierla :
> I am personally aware of companies using Kamailio with several millions of
> subscribers, using kamailio database schema. Also, I am aware of companies
> having more or less same level of subscriber base using SER database schema.
> All have additional tools
On 24.08.2009 15:14 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> kamctl is in sip-router, check tools directory.
ok, i looked at scripts dir where it used to be in k.
> You are more than welcome to implement the srctl, I am going to
> contribute if I am able to and use it
On 24.08.2009 15:08 Uhr, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
I am personally aware of companies using Kamailio with several
millions of subscribers, using kamailio database schema. Also, I am
aware of companies having more or less same level of subscriber base
using SER dat
Daniel-Constantin Mierla writes:
> kamctl is in sip-router, check tools directory.
ok, i looked at scripts dir where it used to be in k.
> You are more than welcome to implement the srctl, I am going to
> contribute if I am able to and use it.
srctl sort of exists already, but is is called
Daniel-Constantin Mierla wrote:
I am personally aware of companies using Kamailio with several millions
of subscribers, using kamailio database schema. Also, I am aware of
companies having more or less same level of subscriber base using SER
database schema. All have additional tools for manag
On 24.08.2009 14:54 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> Kamailio is the same -- will be a new major release of the sip server
> everybody know so far -- new features in core plus some new modules,
> either new development (memcache) or imported from ser (iptrtprox
On 24.08.2009 14:32 Uhr, Iñaki Baz Castillo wrote:
I must agree with Alex.
Sincerely I will wait until SR is really released to start with it.
And with "really released" I mean: when both kamailio and SER concepts
disapear entirely from SR (no more K/S-modules, K/S-functions,
K/S-components, K/S
Daniel-Constantin Mierla writes:
> Kamailio is the same -- will be a new major release of the sip server
> everybody know so far -- new features in core plus some new modules,
> either new development (memcache) or imported from ser (iptrtproxy). To
> update from kamailio 1.5 to 3.0 you wil
Martin Hoffmann wrote:
Alex Balashov wrote:
What this fails to explain in any way is what the intended
applications of K vs. SR are from an end-user perspective.
There is quite some substantial differences between SER 2.x and
Kamailio. However, they are at a level further up -- most importantl
Alex Balashov wrote:
>
> What this fails to explain in any way is what the intended
> applications of K vs. SR are from an end-user perspective.
There is quite some substantial differences between SER 2.x and
Kamailio. However, they are at a level further up -- most importantly
completely differe
Daniel-Constantin Mierla wrote:
Hello,
On 24.08.2009 14:14 Uhr, Alex Balashov wrote:
The sip-router.org documentation is already excessively complicated
and difficult to understand for anyone who does not routinely work
with both the K and S code. At this point, the documentation, while
vol
Iñaki Baz Castillo writes:
> What I don't understand is the reasons to make current SR working with
> K and S features/modules compatibility. We don't need a SR working
> solution right now (since Kamailio and SER do exist), do we?. Wouldn't
> be better to spent devel time in porting the requi
Iñaki Baz Castillo wrote:
What I don't understand is the reasons to make current SR working with
K and S features/modules compatibility. We don't need a SR working
solution right now (since Kamailio and SER do exist), do we?. Wouldn't
be better to spent devel time in porting the required K/S mod
Hello,
On 24.08.2009 14:14 Uhr, Alex Balashov wrote:
The sip-router.org documentation is already excessively complicated
and difficult to understand for anyone who does not routinely work
with both the K and S code. At this point, the documentation, while
voluminous, is overwhelming and, in p
2009/8/24 Alex Balashov :
> Please be careful amidst all this to remember that this "integration" could
> be the undoing of the Kamailio/SR project, and may drive people to OpenSIPS.
> In the end, it is the users that matter.
>
> The sip-router.org documentation is already excessively complicated
On 24.08.2009 14:01 Uhr, Martin Hoffmann wrote:
Daniel-Constantin Mierla wrote:
Or, if developers commit to update the page once they add new
selects, we can work directly on the list, merging the two sections.
It is what we do in Kamailio side of PV/transformations - but there
was no objdu
Please be careful amidst all this to remember that this "integration"
could be the undoing of the Kamailio/SR project, and may drive people to
OpenSIPS. In the end, it is the users that matter.
The sip-router.org documentation is already excessively complicated and
difficult to understand for
On 24.08.2009 13:58 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> You can still use one interface though - MI is fully available and does
> (pseudo) async xmlrpc commands.
that is not true if you use modules from both s and k (like domain
domain module, for example, that is
Daniel-Constantin Mierla wrote:
>
> Or, if developers commit to update the page once they add new
> selects, we can work directly on the list, merging the two sections.
> It is what we do in Kamailio side of PV/transformations - but there
> was no objdump tool for auto-generation, though.
I think
Hello,
On 24.08.2009 13:49 Uhr, Iñaki Baz Castillo wrote:
2009/8/24 Daniel-Constantin Mierla :
Hello everybody,
during the last IRC devel meeting, we pinned end of summer to be the time to
enter testing phase for the new major release - codenamed kamailio 3.0.
There was quite a lot of bra
Daniel-Constantin Mierla writes:
> You can still use one interface though - MI is fully available and does
> (pseudo) async xmlrpc commands.
that is not true if you use modules from both s and k (like domain
domain module, for example, that is much more advanced in s).
besides, s xmlrpc inter
On 24.08.2009 13:52 Uhr, Daniel-Constantin Mierla wrote:
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> If you have discovered something else, let us know.
well, just before your message i send a question to andrei about async
(or delayed reply) sup
Hello,
On 24.08.2009 13:47 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
> If you have discovered something else, let us know.
well, just before your message i send a question to andrei about async
(or delayed reply) support for t_uac_dlg. without that i'm not able to
start usin
2009/8/24 Daniel-Constantin Mierla :
> Hello everybody,
>
> during the last IRC devel meeting, we pinned end of summer to be the time to
> enter testing phase for the new major release - codenamed kamailio 3.0.
>
> There was quite a lot of brand new features, considering that most of devel
> effort
Daniel-Constantin Mierla writes:
> If you have discovered something else, let us know.
well, just before your message i send a question to andrei about async
(or delayed reply) support for t_uac_dlg. without that i'm not able to
start using sip router, because having to use two xmlrpc managemen
Hi Martin,
On 24.08.2009 13:37 Uhr, Martin Hoffmann wrote:
Daniel-Constantin Mierla wrote:
Thanks, I used awk to generate listing in dokuwiki:
http://sip-router.org/wiki/cookbooks/selects/devel#raw_list
How do we procede from there? Should we keep the page in some format
that allows
Daniel-Constantin Mierla wrote:
> Thanks, I used awk to generate listing in dokuwiki:
> http://sip-router.org/wiki/cookbooks/selects/devel#raw_list
How do we procede from there? Should we keep the page in some format
that allows magically adding new selects from ser_objdump output or do
we just t
Hello,
there is a new PV class that provides access to SER select variables. A
list with available selects can be found at:
http://sip-router.org/wiki/cookbooks/selects/devel
Therefore, all Kamailio modules relying on PV framework can get access
to select values without any change. See exampl
Thanks, I used awk to generate listing in dokuwiki:
http://sip-router.org/wiki/cookbooks/selects/devel#raw_list
Cheers,
Daniel
On 24.08.2009 11:56 Uhr, Jan Janak wrote:
Attached is the select list.
Jan.
On Thu, Aug 20, 2009 at 5:35 PM, Jan Janak wrote:
On Thu, Aug 20, 2009 at 5:26 PM,
Hello everybody,
during the last IRC devel meeting, we pinned end of summer to be the
time to enter testing phase for the new major release - codenamed
kamailio 3.0.
There was quite a lot of brand new features, considering that most of
devel effort was directed to integration. A try to colle
andrei
you wrote in july regarding async (delayed reply) support for t_uac_dlg:
Ok, I'll add async support (in fact delayed reply support since it's not
true async), at least to xmlrpc (turns out that it's quite easy since
xmlrpc reuses sr tcp). For ctl/binrpc it would be easy for datagram
43 matches
Mail list logo
