Hi Alex, Daniel,
Crystal clear, thanks for your help! Time to dive into the config.
/Tobias
> Date: Thu, 9 Oct 2014 16:36:02 -0400
> From: abalas...@evaristesys.com
> To: sr-users@lists.sip-router.org
> Subject: Re: [SR-Users] Best way to handle 100 but no 180/183?
>
> Hello Tobias,
>
> fr_inv_t
Btw, there is a global parameter to disable server signatures:
- http://www.kamailio.org/wiki/cookbooks/devel/core#server_signature
According to the code, it affect USER-Agent when generating a request
and Server header for replies.
Turn it of and can get rid of the workaround with custom hea
Hello Tobias,
fr_inv_timer won't do much for you, because it deals only with final
replies (>= 200) to the INVITE transaction. 1xx replies are all
provisional in nature.
Thus, the nature of the problem is such that if you've received a 100
Trying, you've already dampened fr_timer, but the on
Hello Daniel,
I don’t use the GIT repository. I still use the source from tar.gz.
Can you give me the link to the patch? I will patch acc module and compile it.
Regards,
Igor.
De : Daniel-Constantin Mierla [mailto:mico...@gmail.com]
Envoyé : mardi 7 octobre 2014 09:00
À : Igor Pot
Hello,
you can browse the git repository online and get from there the patch or
diff:
-
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=history;f=modules/acc;hb=HEAD
Or on github:
- https://github.com/kamailio/kamailio/commits/master/modules/acc
Cheers,
Daniel
On 09/10/14 19:50
Hello,
you can play with t_set_fr() in an onreply_route[x] block for the invite
transaction:
- http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_set_fr
Cheers,
Daniel
On 09/10/14 21:29, Tobias wrote:
Dear Kamailio users,
I have an issue with some upstream carriers quickly repl
Hi again,
Maybe I was to quick on my previous mail, after some more searching I found a
very similar
question:http://lists.sip-router.org/pipermail/sr-users/2012-November/075497.html
I guess this is still the way to go?
Thanks,/Tobias
From: the...@hotmail.com
To: sr-users@lists.sip-router.org
Da
Dear Kamailio users,
I have an issue with some upstream carriers quickly replying with 100 Trying
but then basically times out.
I'm looking for a good solution to distinguish between the 100 reply and any
other replies, and alter the timeout values. My goal is to be able to re-route
calls where
Hello,
On 09/10/14 13:19, Errol Samuels wrote:
HI Daniel,
Thanks for that.
In my case I would need to use something like:
user_agent_header = "X-Proxy: $ua"
The only purpose of the above line is that Kamailio doesn't add an
User-Agent header by itself, but this X-Proxy (which you can change
HI Daniel,
Thanks for that.
In my case I would need to use something like:
user_agent_header = "X-Proxy: $ua"
since we don't what to hardcode a specific value which would affect every
device that is registering but rather $ua which would set the real UA of
the device that is registering at that
I just commented on the other email you send, try with something like:
user_agent_header="X-Proxy: xyz"
Cheers,
Daniel
On 09/10/14 12:08, Errol Samuels wrote:
Just found something interesting.
I just commented out the "user_agent_header" in the Global section and
restarted kamailio and now t
On 08/10/14 19:25, Errol Samuels wrote:
I followed Daniel's instructions and made some progress but not 100%
there yet.
---[Global section]--
user_agent_header=""
---[Main Routing Logic]---
# handle registrations
if (is_method("REGISTER"))
{
$avp(
Just found something interesting.
I just commented out the "user_agent_header" in the Global section and
restarted kamailio and now the REGISTER message seems to be completely
intact but now we have two occurrences of the User-Agent. I tried doing
the remove_hf("User-Agent) but it doesn't seem to
Hi Gonzaio,
Thanks for the reply.
Yes the registrations are not updating to DB and info stays in cache. We
are getting Register packets every two minutes (expires = 120) and we are
using the default timer_interval value (60). What is the suggested
timer_value value here ?
DB : Postgres
kamailio
Hello,
indeed the code is storing once as a global message and then one copy
for each value in traced_user_avp.
The purpose of traced_user_avp was to be able to enable tracing of a
user by some portal/api, byt the user itself, so the portal displays
only the records which have the value of t
Hello,
On 09/10/14 07:13, David Wilson wrote:
Hi Daniel,
Thanks for the response.
Reviewing the logs again, the first occurrence was on 25Sep, after
upgrading to 4.1.6+precise on 24Sep.
Previous upgrades were to:
4.1.5+precise18Aug
4.1.4+preciseJune
Traffic patterns are fairly uniform over
16 matches
Mail list logo
