Hi, Daniel-Constantin Mierla!
>Hello,
>
>if you don't want the memory operations logs, then memdbg has to be
>higher than debug.
ok, thanks! sorry for buzz, doc contain this info, i'm just inattentive.
--
WBR, Victor
JID: coy...@bks.tv
JID: coy...@bryansktel.ru
I use FREE operation sys
Hello,
can you try the latest master branch or pick the patch from commit
81b9c83b2fa3bd32d502a1ae9014cc7d6747e710?
If all is ok, I will backport to 4.1 -- 4.0 might need an additional
patch to get access to picked branch, iirc, that was added in 4.1.
Cheers,
Daniel
On 18/12/13 09:19, Dani
Hello,
Kamailio SIP Server v3.3.6 stable release is out.
This is a maintenance release of the previous stable branch, 3.3, that
includes fixes since release of v3.3.5. There is no change to database
schema or configuration language structure that you have to do on
installations of previous v3
Thanks alex! Good point
On Dec 19, 2013 7:05 PM, "Alex Balashov" wrote:
> TM does not provide timers for the intervals you're seeking.
>
> If you really, really want to 'hack' this, you can use t_set_fr() to set
> an artificially low fr_inv_timer value and then, upon receipt of a 180/183
> in an
On 19/12/13 15:42, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Have you checked to see if the sip_params field is also set when
'user=phone' doesn't exist?
yes, my understanding is that it is set as the first thing always:
switch(uri->type){
case SIPS_URI_T:
Daniel-Constantin Mierla writes:
> Have you checked to see if the sip_params field is also set when
> 'user=phone' doesn't exist?
yes, my understanding is that it is set as the first thing always:
switch(uri->type){
case SIPS_URI_T:
case SIP_URI_T:
On 19/12/13 15:25, Juha Heinanen wrote:
Juha Heinanen writes:
perhaps they now take them from params field and that causes the
problem?
that was it. i just pushed a fix to master and will cherry pick to
4.1. i think that @ruri.params select would need to be fixed too.
Have you checked to see
Juha Heinanen writes:
> perhaps they now take them from params field and that causes the
> problem?
that was it. i just pushed a fix to master and will cherry pick to
4.1. i think that @ruri.params select would need to be fixed too.
-- juha
___
SIP
Daniel-Constantin Mierla writes:
> At that time I checked the sources and parameters are linked to another
> field in uri structure than without it, thus the params field is somehow
> left empty. I had no time to investigate more the specs, maybe looking
> at parse_uri() will shed more light.
Hello,
if you don't want the memory operations logs, then memdbg has to be
higher than debug. Not to get the dumps at the end, memlog has to be
higher as well.
Cheers,
Daniel
On 19/12/13 13:15, Victor V. Kustov wrote:
Hi, all
debug=2
memdbg=0
memlog=0
mem_summary=0
i saw it in kamcmd cfg.
Hi, all
debug=2
memdbg=0
memlog=0
mem_summary=0
i saw it in kamcmd cfg.get...
but anyway q_malloc messages in log. where i make mistake?
--
WBR, Victor
JID: coy...@bks.tv
JID: coy...@bryansktel.ru
I use FREE operation system: 3.10.24-calculate GNU/Linux
___
TM does not provide timers for the intervals you're seeking.
If you really, really want to 'hack' this, you can use t_set_fr() to set
an artificially low fr_inv_timer value and then, upon receipt of a
180/183 in an onreply_route, t_reset_fr() back to a larger, normal value.
So, if you wanted
just a quick question, somebody out there might have an idea:
currently, we can easily control the ff:
Time from INVITE to 200 OK -- fr_inv_timer
Time from INVITE to 100 TRYING -- fr_timer
what i hope to achieve is:
Time from Session Progress (180/183) to 200 OK
modparam("tm", "failure_reply_mode", 3)
modparam("tm", "contacts_avp", "tm_contacts");
modparam("tm", "contact_flows_avp", "tm_contact_flows");
modparam("tm", "failure_reply_mode", 3)
modparam("tm", "restart_fr_on_each_reply", 0)
Kelvin Chua
On Thu, Dec 19, 2013 at 3:57 PM, Daniel-Constantin Mi
Daniel-Constantin Mierla writes:
> I expect it has to do with the special requirements on handling uri
> enforced by 'user=phone'. Something related was on sr-dev few time
> ago:
;user=phone may mean something special, but when it comes to request-uri
parameter syntax, it is just one parameter a
Hello,
quick reminder for those people that might consider to backport
something to branch 3.3 before we do another release (probably the last
one).
Cheers,
Daniel
On 18/12/13 09:38, Daniel-Constantin Mierla wrote:
Hello,
the last two stable branches are now 4.0 and 4.1. I am considering
Hello,
I expect it has to do with the special requirements on handling uri
enforced by 'user=phone'. Something related was on sr-dev few time ago:
- http://lists.sip-router.org/pipermail/sr-dev/2013-December/022267.html
- http://lists.sip-router.org/pipermail/sr-dev/2013-December/022269.html
Hello,
I see that the modules don't have a readme in the sources, so the html
files couldn't be generated.
Hopefully the devs working with IMS modules will fix that soon.
Cheers,
Daniel
On 18/12/13 19:57, Andreas Granig wrote:
Hi,
Seems like two ims module links (linked from
http://kamaili
18 matches
Mail list logo
