Envoyé de mon iPad
Le 28 juil. 2014 à 11:06, Daniel-Constantin Mierla a écrit :
> Hello,
>
> On 25/07/14 22:47, Asgaroth wrote:
>> Hi,
>>
>> using t_replicate() did the trick! it appears to be replicating to both
>> systems now, thanks alot for looking at this.
> great, welcome!
>>
>> The
Envoyé de mon iPad
Le 28 juil. 2014 à 11:06, Daniel-Constantin Mierla a écrit :
> Hello,
>
> On 25/07/14 22:47, Asgaroth wrote:
>> Hi,
>>
>> using t_replicate() did the trick! it appears to be replicating to both
>> systems now, thanks alot for looking at this.
> great, welcome!
>>
>> The
Envoyé de mon iPad
Le 25 juil. 2014 à 17:35, Asgaroth <00asgarot...@gmail.com> a écrit :
> Hi,
>
> On 25/07/2014 13:49, Daniel-Constantin Mierla wrote:
>> The second one is with the patch to the code and it is enough to pick only
>> that one.
>
> OK, I tried 4.1.4 with this patch applied an
Hello,
On 25/07/14 22:47, Asgaroth wrote:
Hi,
using t_replicate() did the trick! it appears to be replicating to
both systems now, thanks alot for looking at this.
great, welcome!
The only difference i can see is that the r-uri is re-written for both
replicated regesters although this shou
Hi,
using t_replicate() did the trick! it appears to be replicating to both
systems now, thanks alot for looking at this.
The only difference i can see is that the r-uri is re-written for both
replicated regesters although this shouldnt make any difference as the
registration is already auth
Hello,
use t_replicate() without any parameter.
I said before that I mistakenly evaluated the code as working with empty
parameter, but it was not. Later today I pushed a new patch for this
case as well.
Cheers,
Daniel
On 25/07/14 19:35, Asgaroth wrote:
Hi,
On 25/07/2014 13:49, Daniel-Con
Hi,
On 25/07/2014 13:49, Daniel-Constantin Mierla wrote:
The second one is with the patch to the code and it is enough to pick
only that one.
OK, I tried 4.1.4 with this patch applied and I still get the following
error message:
/usr/sbin/kamailio[22158]: ERROR: tm [tm.c:1618]: t_replicate_
The second one is with the patch to the code and it is enough to pick
only that one.
The first one is for docs (readme file), which is not really necessary
to test (main reason to split the commit, because patches to docs
typically throw conflicts when backporting, due to different formatting
On 25/07/2014 12:04, Daniel-Constantin Mierla wrote:
I read the condition on uri wrong -- it was only on a null pointer for
the uri, not on length (in this case pointer is to a empty string). I
pushed an enhanced check for length as well, but it is only in master
for the moment.
ok, I will tr
On 25/07/14 12:51, Asgaroth wrote:
On 25/07/2014 11:33, Daniel-Constantin Mierla wrote:
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate("");*
Yes, and this should work on existing versions 4.1.x or older
OK, trying to test this
On 25/07/2014 11:33, Daniel-Constantin Mierla wrote:
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate("");*
Yes, and this should work on existing versions 4.1.x or older
OK, trying to test this and I'm seeing an error with debug=2:
Hello,
On 25/07/14 12:36, Asgaroth wrote:
Hi,
Another quick question on the git checkout, do I need to checkout the
4.1 branch for this patch, or is it in 4.2 branch?
I did the following:
git clone --depth 1 git://git.sip-router.org/sip-router kamailio
make FLAVOUR=kamailio tar
this genera
Hi,
Another quick question on the git checkout, do I need to checkout the
4.1 branch for this patch, or is it in 4.2 branch?
I did the following:
git clone --depth 1 git://git.sip-router.org/sip-router kamailio
make FLAVOUR=kamailio tar
this generates the following tar file which I will use
On 25/07/14 12:20, Asgaroth wrote:
Hi,
On 25/07/2014 11:03, Daniel-Constantin Mierla wrote:
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
Apparently the same behaviour can be achieved using:
t_replicate("")
so the parameter is an empty string. Ca
Hi,
On 25/07/2014 11:03, Daniel-Constantin Mierla wrote:
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
Apparently the same behaviour can be achieved using:
t_replicate("")
so the parameter is an empty string. Can you try it and see if works?
Also
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
Apparently the same behaviour can be achieved using:
t_replicate("")
so the parameter is an empty string. Can you try it and see if works?
Also, feedback on testing the patch for no parameter would be a
On 24/07/14 19:34, Asgaroth wrote:
On 24/07/2014 17:26, Daniel-Constantin Mierla wrote:
checking docs, it seems like that. I will have to look at the code
and eventually make an option without parameter. Otherwise, like it
is not, the parameter forces an outbound proxy to be used for
forwardi
On 24/07/2014 17:26, Daniel-Constantin Mierla wrote:
checking docs, it seems like that. I will have to look at the code and
eventually make an option without parameter. Otherwise, like it is
not, the parameter forces an outbound proxy to be used for forwarding.
I guess that makes sense for set
Hello,
On 24/07/14 17:29, Asgaroth wrote:
Hi,
Thanks for the suggestion, I tried it but t_replicate() seems to cause
an issue with config parsing, looking at TM module v4.1.x
documentation, it looks like t_replicate *must* have paramteres.
checking docs, it seems like that. I will have to l
Hi,
Thanks for the suggestion, I tried it but t_replicate() seems to cause
an issue with config parsing, looking at TM module v4.1.x documentation,
it looks like t_replicate *must* have paramteres.
Here's my test snip:
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
appe
Hello,
you use t_replicate(uri1) -- by that you force outbound proxy to uri1
parameter.
Can you try like in the next example?
$ru = uri1;
append_branch("uri2");
t_replicate();
Cheers,
Daniel
On 22/07/14 17:40, Daniel-Constantin Mierla wrote:
Hello,
ok, I will look it up and investigate wh
Hello,
ok, I will look it up and investigate when I get the first chance.
Cheers,
Daniel
On 22/07/14 16:43, Asgaroth wrote:
Hi,
On 22/07/2014 11:38, Daniel-Constantin Mierla wrote:
Hello,
looking a bit at the source code, append branch should still create a
new destination point and messag
Hi,
On 22/07/2014 11:38, Daniel-Constantin Mierla wrote:
Hello,
looking a bit at the source code, append branch should still create a
new destination point and message to be sent there. I would need the
log messages printed with debug=3 in kamailio.cfg for the case when
you use append branch
Hello,
looking a bit at the source code, append branch should still create a
new destination point and message to be sent there. I would need the log
messages printed with debug=3 in kamailio.cfg for the case when you use
append branch. Can you provide them?
Cheers,
Daniel
On 22/07/14 10:29
Hi,
On 22/07/2014 09:13, Daniel-Constantin Mierla wrote:
first some clarifications about the subject:
- append_branch() adds a new destination for normal
forwarding/relaying -- replies from these destinations are forwarded
back to the initial sender
- t_replicate() creates a special branch --
Hello,
first some clarifications about the subject:
- append_branch() adds a new destination for normal forwarding/relaying
-- replies from these destinations are forwarded back to the initial sender
- t_replicate() creates a special branch -- replies from these
destinations are absorbed local
I ended up using two 'forward' statements in stead of t_replicate as it
does not appear to work with 2+ servers to replicate to.
On 21/07/2014 15:01, Asgaroth wrote:
Further update, it looks like append_branch is over-writing the
original request-uri, an ngrep shows the following for the 2 mes
Just an update on this, it appears to send 2 REGISTER requests in
parellel to BACKUP_REGISTRAR_3, so it looks like the append_branch is
being added but its uri is set to BACKUP_REGISTRAR_3 (and not
BACKUP_REGISTRAR_2 as requested int the append_branch section)
On 21/07/2014 13:49, Asgaroth wro
Further update, it looks like append_branch is over-writing the original
request-uri, an ngrep shows the following for the 2 messages sent:
This one looks like the proper replicate for the original request
U 2014/07/21 14:56:29.781372 BACKUP_REGISTRAR_1:5060 ->
BACKUP_REGISTRAR_3:5060
REGISTE
29 matches
Mail list logo
