[SR-Users] append_branch and t_replicate issue

[Asgaroth]

Hi All,

I have an issue that I cant seem to get to the bottom of, I would
appreciate if someone could point me in the right direction.

I have 3 registrar's and would like to replicate the registration regest
from 1 to the other 2, I am trying this with t_replicate, the docs say
that to send to multiple destinations an append_branch should be
performed prior to the t_replicate, which is what I am trying to do.

What appears to happen is that the replication only sends the REGISTER
to the server defined in the t_replicate command, it doesnt appear to be
sending it to the destination defined in append_branch.

Kamailio Version:

version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7

Here is what I have tried so far (on registrar 1):

#!define BACKUP_REGISTRAR_1 '1.1.1.1'
#!define BACKUP_REGISTRAR_2 '1.1.1.2'
#!define BACKUP_REGISTRAR_3 '1.1.1.3'

save("location");
if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) {
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060");
};

With the above in place, I only see the system attempting to replicate
to BACKUP_REGISTRAR_3, I dont see any request to BACKUP_REGISTRAR_2.

Am I doing something wrong here?

Thanks
Bruce

[Asgaroth]

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
REGISTER sip:*domain.com*;transport=UDP SIP/2.0

This one looks like the r-uri is re-written to that of the
BACKUP_REGISTRAR_2 address, but destination is still BACKUP_REGISTRAR_3

U 2014/07/21 14:56:33.781441 BACKUP_REGISTRAR_1:5060 ->
BACKUP_REGISTRAR_3:5060
REGISTER sip:*BACKUP_REGISTRAR_2*:5060 SIP/2.0

Is this normal operation or am I missing something fundamental here with
t_replicate/append_branch?

Thanks
Bruce

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)

Post by Asgaroth
Hi All,
I have an issue that I cant seem to get to the bottom of, I would
appreciate if someone could point me in the right direction.
I have 3 registrar's and would like to replicate the registration
regest from 1 to the other 2, I am trying this with t_replicate, the
docs say that to send to multiple destinations an append_branch
should be performed prior to the t_replicate, which is what I am
trying to do.
What appears to happen is that the replication only sends the
REGISTER to the server defined in the t_replicate command, it doesnt
appear to be sending it to the destination defined in append_branch.
version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7
#!define BACKUP_REGISTRAR_1 '1.1.1.1'
#!define BACKUP_REGISTRAR_2 '1.1.1.2'
#!define BACKUP_REGISTRAR_3 '1.1.1.3'
save("location");
if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) {
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060");
};
With the above in place, I only see the system attempting to
replicate to BACKUP_REGISTRAR_3, I dont see any request to
BACKUP_REGISTRAR_2.
Am I doing something wrong here?
Thanks
Bruce

[Bruce McAlister]

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)

Post by Asgaroth
Hi All,
I have an issue that I cant seem to get to the bottom of, I would
appreciate if someone could point me in the right direction.
I have 3 registrar's and would like to replicate the registration
regest from 1 to the other 2, I am trying this with t_replicate, the
docs say that to send to multiple destinations an append_branch should
be performed prior to the t_replicate, which is what I am trying to do.
What appears to happen is that the replication only sends the REGISTER
to the server defined in the t_replicate command, it doesnt appear to
be sending it to the destination defined in append_branch.
version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7
#!define BACKUP_REGISTRAR_1 '1.1.1.1'
#!define BACKUP_REGISTRAR_2 '1.1.1.2'
#!define BACKUP_REGISTRAR_3 '1.1.1.3'
save("location");
if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) {
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060");
};
With the above in place, I only see the system attempting to replicate
to BACKUP_REGISTRAR_3, I dont see any request to BACKUP_REGISTRAR_2.
Am I doing something wrong here?
Thanks
Bruce

[Asgaroth]

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.

Post by Asgaroth
Further update, it looks like append_branch is over-writing the
original request-uri, an ngrep shows the following for the 2 messages
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
REGISTER sip:*domain.com*;transport=UDP SIP/2.0
This one looks like the r-uri is re-written to that of the
BACKUP_REGISTRAR_2 address, but destination is still BACKUP_REGISTRAR_3
U 2014/07/21 14:56:33.781441 BACKUP_REGISTRAR_1:5060 ->
BACKUP_REGISTRAR_3:5060
REGISTER sip:*BACKUP_REGISTRAR_2*:5060 SIP/2.0
Is this normal operation or am I missing something fundamental here
with t_replicate/append_branch?
Thanks
Bruce

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)

Post by Asgaroth
Hi All,
I have an issue that I cant seem to get to the bottom of, I would
appreciate if someone could point me in the right direction.
I have 3 registrar's and would like to replicate the registration
regest from 1 to the other 2, I am trying this with t_replicate, the
docs say that to send to multiple destinations an append_branch
should be performed prior to the t_replicate, which is what I am
trying to do.
What appears to happen is that the replication only sends the
REGISTER to the server defined in the t_replicate command, it doesnt
appear to be sending it to the destination defined in append_branch.
version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7
#!define BACKUP_REGISTRAR_1 '1.1.1.1'
#!define BACKUP_REGISTRAR_2 '1.1.1.2'
#!define BACKUP_REGISTRAR_3 '1.1.1.3'
save("location");
if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) {
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060");
};
With the above in place, I only see the system attempting to
replicate to BACKUP_REGISTRAR_3, I dont see any request to
BACKUP_REGISTRAR_2.
Am I doing something wrong here?
Thanks
Bruce

[Daniel-Constantin Mierla]

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 locally by the proxy

Can you try using t_replicate() several times?

Cheers,
Daniel

Post by Asgaroth
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.

Post by Asgaroth
Further update, it looks like append_branch is over-writing the
original request-uri, an ngrep shows the following for the 2 messages
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
REGISTER sip:*domain.com*;transport=UDP SIP/2.0
This one looks like the r-uri is re-written to that of the
BACKUP_REGISTRAR_2 address, but destination is still BACKUP_REGISTRAR_3
U 2014/07/21 14:56:33.781441 BACKUP_REGISTRAR_1:5060 ->
BACKUP_REGISTRAR_3:5060
REGISTER sip:*BACKUP_REGISTRAR_2*:5060 SIP/2.0
Is this normal operation or am I missing something fundamental here
with t_replicate/append_branch?
Thanks
Bruce

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)

Post by Asgaroth
Hi All,
I have an issue that I cant seem to get to the bottom of, I would
appreciate if someone could point me in the right direction.
I have 3 registrar's and would like to replicate the registration
regest from 1 to the other 2, I am trying this with t_replicate,
the docs say that to send to multiple destinations an append_branch
should be performed prior to the t_replicate, which is what I am
trying to do.
What appears to happen is that the replication only sends the
REGISTER to the server defined in the t_replicate command, it
doesnt appear to be sending it to the destination defined in
append_branch.
version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7
#!define BACKUP_REGISTRAR_1 '1.1.1.1'
#!define BACKUP_REGISTRAR_2 '1.1.1.2'
#!define BACKUP_REGISTRAR_3 '1.1.1.3'
save("location");
if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) {
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060");
};
With the above in place, I only see the system attempting to
replicate to BACKUP_REGISTRAR_3, I dont see any request to
BACKUP_REGISTRAR_2.
Am I doing something wrong here?
Thanks
Bruce

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Asgaroth]

Hi,

Post by Daniel-Constantin Mierla
- 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 locally by the proxy

Thanks for the clarification, I guess these two staements cant really be
used in conjunction then, and it appears that the behaviour I was seeing
is correct. I was pretty certain I saw it in the documentation yesterday
that to replicate to more than 1 destination that an append_branch must
be called, however, I have just checked TM module documentation for 4.1,
3.2 and 3.1 and the documentation has changed (I must be going crazy :) )

Post by Daniel-Constantin Mierla
Can you try using t_replicate() several times?

I did try calling 2 t_replicate statements, but it appears that only the
first one is called and the second one ignored:

t_replicate("sip:" + BACKUP_REGISTRAR_2 + ":5060"); <- I see
this message being sent
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060"); <- This one
does not get generated/sent

Thanks

[Daniel-Constantin Mierla]

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

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
- 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 locally by the proxy

Thanks for the clarification, I guess these two staements cant really
be used in conjunction then, and it appears that the behaviour I was
seeing is correct. I was pretty certain I saw it in the documentation
yesterday that to replicate to more than 1 destination that an
append_branch must be called, however, I have just checked TM module
documentation for 4.1, 3.2 and 3.1 and the documentation has changed
(I must be going crazy :) )

Post by Daniel-Constantin Mierla
Can you try using t_replicate() several times?

I did try calling 2 t_replicate statements, but it appears that only
t_replicate("sip:" + BACKUP_REGISTRAR_2 + ":5060"); <- I see
this message being sent
t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060"); <- This one
does not get generated/sent
Thanks

[Asgaroth]

Hi,

Post by Daniel-Constantin Mierla
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?

Just for completeness, I sent the debug output directly to your gmail
address.

Thanks for looking at this Daniel.

Cheers
Bruce

[Daniel-Constantin Mierla]

Hello,

ok, I will look it up and investigate when I get the first chance.

Cheers,
Daniel

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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?

Just for completeness, I sent the debug output directly to your gmail
address.
Thanks for looking at this Daniel.
Cheers
Bruce

[Daniel-Constantin Mierla]

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

Post by Daniel-Constantin Mierla
Hello,
ok, I will look it up and investigate when I get the first chance.
Cheers,
Daniel

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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?

Just for completeness, I sent the debug output directly to your gmail
address.
Thanks for looking at this Daniel.
Cheers
Bruce

[Asgaroth]

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";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate();

The kamailio restart throws the following error (I do have the tm module
loaded):

Not starting : invalid configuration file!

0(15737) ERROR: <core> [cfg.y:3273]: yyparse(): cfg. parser:
failed to find command t_replicate (params 0)
0(15737) : <core> [cfg.y:3412]: yyerror_at(): parse error in
config file //etc/kamailio/kamailio.cfg, line 190, column 25: unknown
command, missing loadmodule?

ERROR: bad config file (1 errors)

Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Post by Daniel-Constantin Mierla
Hello,
ok, I will look it up and investigate when I get the first chance.
Cheers,
Daniel

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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?

Just for completeness, I sent the debug output directly to your
gmail address.
Thanks for looking at this Daniel.
Cheers
Bruce

[Daniel-Constantin Mierla]

Hello,

Post by Asgaroth
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 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.

You sent me the sip trace and you can see there that two register
requests are sent out, both to the address in the parameter of the
t_replicate(), but one has the address from append_branch() in r-uri. So
the forking was done.

Maybe you can try with a look via kamailio itself:

$ru = uri1;
append_branch("uri2");
t_replicate("sip:kamailioip:kamailioport");

Then you see that is coming with src_ip==myself and simply do t_relay()
and the r-uri should point to where it needs to be forwarded.

Cheers,
Daniel

Post by Asgaroth
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
t_replicate();
The kamailio restart throws the following error (I do have the tm
Not starting : invalid configuration file!
failed to find command t_replicate (params 0)
0(15737) : <core> [cfg.y:3412]: yyerror_at(): parse error in
config file //etc/kamailio/kamailio.cfg, line 190, column 25: unknown
command, missing loadmodule?
ERROR: bad config file (1 errors)
Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Post by Daniel-Constantin Mierla
Hello,
ok, I will look it up and investigate when I get the first chance.
Cheers,
Daniel

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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?

Just for completeness, I sent the debug output directly to your
gmail address.
Thanks for looking at this Daniel.
Cheers
Bruce

[Asgaroth]

Post by Daniel-Constantin Mierla
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 setting $ds to replicate the message and
explains the behaviour I was seeing both branches going to $ds which was
set in t_replicate uri param.

Post by Daniel-Constantin Mierla
You sent me the sip trace and you can see there that two register
requests are sent out, both to the address in the parameter of the
t_replicate(), but one has the address from append_branch() in r-uri.
So the forking was done.
$ru = uri1;
append_branch("uri2");
t_replicate("sip:kamailioip:kamailioport");
Then you see that is coming with src_ip==myself and simply do
t_relay() and the r-uri should point to where it needs to be forwarded.

Can you forsee any issues with using 2 forward requests instead of
t_replicate. the only difference i can see in the message is that the
second forward adds a duplicate (expected behaviour) via address (i
presume because the message already had a via added in the previous
forward. So what I was thinking was, something like this:

on registrar 1:

save("location")
forward(BACKUP_REGISTRAR_2);
forward(BACKUP_REGISTRAR_3);

then on the 2nd registrar something like this:

if ( src_ip == BACKUP_REGISTRAR_1 || src_ip == BACKUP_REGISTRAR_3 ) {
save("location","0x02");
exit;
};

I use 0x02 flag so that save does not send reply because forward above
is stateless.

A 'kamctl ul show <contact>' seems to look the same accross the 3
registrars when testing.

The only thing I can think of is if kamailio is really busy and does not
get to process the message, because forward is stateless, it wont
re-transmit a couple times to relay the message.

I guess, it would be nice if t_replicate accepted a couple of uri to
replicate to then for each uri set $ds to uri an send message, however,
I'm not sure if that is even feasable :)

Thanks
Bruce

[Daniel-Constantin Mierla]

Post by Asgaroth

Post by Daniel-Constantin Mierla
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 setting $ds to replicate the message and
explains the behaviour I was seeing both branches going to $ds which
was set in t_replicate uri param.

Post by Daniel-Constantin Mierla
You sent me the sip trace and you can see there that two register
requests are sent out, both to the address in the parameter of the
t_replicate(), but one has the address from append_branch() in r-uri.
So the forking was done.
$ru = uri1;
append_branch("uri2");
t_replicate("sip:kamailioip:kamailioport");
Then you see that is coming with src_ip==myself and simply do
t_relay() and the r-uri should point to where it needs to be forwarded.

Can you forsee any issues with using 2 forward requests instead of
t_replicate. the only difference i can see in the message is that the
second forward adds a duplicate (expected behaviour) via address (i
presume because the message already had a via added in the previous
save("location")
forward(BACKUP_REGISTRAR_2);
forward(BACKUP_REGISTRAR_3);
if ( src_ip == BACKUP_REGISTRAR_1 || src_ip == BACKUP_REGISTRAR_3 ) {
save("location","0x02");
exit;
};
I use 0x02 flag so that save does not send reply because forward above
is stateless.
A 'kamctl ul show <contact>' seems to look the same accross the 3
registrars when testing.
The only thing I can think of is if kamailio is really busy and does
not get to process the message, because forward is stateless, it wont
re-transmit a couple times to relay the message.

If it is in the same network, it should be ok, udp forwarding is
unlikely to be lost. Or you can use tcp for forwarding.

Post by Asgaroth
I guess, it would be nice if t_replicate accepted a couple of uri to
replicate to then for each uri set $ds to uri an send message,
however, I'm not sure if that is even feasable :)

Going to look at the code and add it if not something very complex.

Cheers,
Daniel

[Daniel-Constantin Mierla]

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 appreciated.

Cheers,
Daniel

Post by Daniel-Constantin Mierla

Post by Asgaroth

Post by Daniel-Constantin Mierla
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 setting $ds to replicate the message and
explains the behaviour I was seeing both branches going to $ds which
was set in t_replicate uri param.

Post by Daniel-Constantin Mierla
You sent me the sip trace and you can see there that two register
requests are sent out, both to the address in the parameter of the
t_replicate(), but one has the address from append_branch() in
r-uri. So the forking was done.
$ru = uri1;
append_branch("uri2");
t_replicate("sip:kamailioip:kamailioport");
Then you see that is coming with src_ip==myself and simply do
t_relay() and the r-uri should point to where it needs to be forwarded.

Can you forsee any issues with using 2 forward requests instead of
t_replicate. the only difference i can see in the message is that the
second forward adds a duplicate (expected behaviour) via address (i
presume because the message already had a via added in the previous
save("location")
forward(BACKUP_REGISTRAR_2);
forward(BACKUP_REGISTRAR_3);
if ( src_ip == BACKUP_REGISTRAR_1 || src_ip == BACKUP_REGISTRAR_3 ) {
save("location","0x02");
exit;
};
I use 0x02 flag so that save does not send reply because forward
above is stateless.
A 'kamctl ul show <contact>' seems to look the same accross the 3
registrars when testing.
The only thing I can think of is if kamailio is really busy and does
not get to process the message, because forward is stateless, it wont
re-transmit a couple times to relay the message.

If it is in the same network, it should be ok, udp forwarding is
unlikely to be lost. Or you can use tcp for forwarding.

Post by Asgaroth
I guess, it would be nice if t_replicate accepted a couple of uri to
replicate to then for each uri set $ds to uri an send message,
however, I'm not sure if that is even feasable :)

Going to look at the code and add it if not something very complex.
Cheers,
Daniel

[Asgaroth]

Hi,

Post by Daniel-Constantin Mierla
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
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
appreciated.

Thanks for this patch, I'll get on to building a couple rpm's with
master branch to test.

Just to verify, you want me to test using the following setup:

$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate("");*

and

$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate();*

Thanks
Bruce

[Daniel-Constantin Mierla]

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
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
appreciated.

Thanks for this patch, I'll get on to building a couple rpm's with
master branch to test.
$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

Post by Asgaroth
and
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate();*

This one as well, but only with master branch.

Cheers,
Daniel

[Asgaroth]

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 for building the
rpms:

kamailio-4.2.0-dev7_src.tar.gz

Is the patch living in this branch or can I do a 'git checkout -b 4.1
origin/4.1' and expect the patch to be in there?

Thanks
Bruce

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
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
appreciated.

Thanks for this patch, I'll get on to building a couple rpm's with
master branch to test.
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate("");*
and
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate();*
Thanks
Bruce

[Daniel-Constantin Mierla]

Hello,

Post by Asgaroth
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?
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 for building
kamailio-4.2.0-dev7_src.tar.gz
Is the patch living in this branch

yes, the patch is in the above sources tarball.

Post by Asgaroth
or can I do a 'git checkout -b 4.1 origin/4.1' and expect the patch to
be in there?

No, the patch is not in branch 4.1. If you have the branch 4.1 cloned
locally, you can use:

git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c

to get the patch in branch 4.1, in your local copy of sources.

Cheers,
Daniel

Post by Asgaroth
Thanks
Bruce

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
I pushed a patch to master branch that allows to use t_replicate()
without any parameters.
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
appreciated.

Thanks for this patch, I'll get on to building a couple rpm's with
master branch to test.
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate("");*
and
$ru = "sip:" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060");
*t_replicate();*
Thanks
Bruce

[Asgaroth]

Post by Daniel-Constantin Mierla

Post by Asgaroth
$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:

/usr/sbin/kamailio[25432]: ERROR: tm [tm.c:1616]: t_replicate_uri(): bad
replicate SIP address!

And, I guess because of this, the messages are not being replicated at all.

I tried something like this:

$ru = "*sip:me@*" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("*sip:me@*" + BACKUP_REGISTRAR_1 + ":5060");
t_replicate("");

But I still get the same error message as above.

this is on kamailio version:

version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7

Thanks
Bruce

[Daniel-Constantin Mierla]

Post by Daniel-Constantin Mierla

Post by Asgaroth
$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

bad replicate SIP address!

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.

You have to use master or pick the commit to 4.1

Cheers,
Daniel

And, I guess because of this, the messages are not being replicated at
all.
t_replicate("");
But I still get the same error message as above.
version: kamailio 4.1.4 (x86_64/linux) 84c1ff
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 84c1ff
compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7
Thanks
Bruce

[Asgaroth]

Post by Daniel-Constantin Mierla
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 try to cherry pick it back to 4.1

Is it these 2 that I need to get back in to 4.1:

commit 1be7c3ebc9b29046c023290ad580bb83c3e6e44d
Author: Daniel-Constantin Mierla <miconda-***@public.gmane.org>
Date: Fri Jul 25 12:01:37 2014 +0200

tm: docs - added note about t_replicate() without params

commit c5b6b6021e75cd4e73f54f9131524b588709950c
Author: Daniel-Constantin Mierla <miconda-***@public.gmane.org>
Date: Fri Jul 25 11:58:50 2014 +0200

tm: enable t_replicate() without any parameter

- r-uri or dst-uri will be used for sending out

Thanks
Bruce

[Daniel-Constantin Mierla]

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
of whitespacing by vaiorus OSes).

Daniel

Post by Asgaroth

Post by Daniel-Constantin Mierla
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 try to cherry pick it back to 4.1
commit 1be7c3ebc9b29046c023290ad580bb83c3e6e44d
Date: Fri Jul 25 12:01:37 2014 +0200
tm: docs - added note about t_replicate() without params
commit c5b6b6021e75cd4e73f54f9131524b588709950c
Date: Fri Jul 25 11:58:50 2014 +0200
tm: enable t_replicate() without any parameter
- r-uri or dst-uri will be used for sending out
Thanks
Bruce

[Asgaroth]

Hi,

Post by Daniel-Constantin Mierla
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_uri(): bad
replicate SIP address!

Kamailio version:

version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7

The snip I am trying is as follows:

$ru = "sip:me@" + BACKUP_REGISTRAR_1 + ":5060";
append_branch("sip:me@" + BACKUP_REGISTRAR_1 + ":5060");
t_replicate("");

I had a copy of the 4.1 branch on my local machine, the steps I followed
to build the tar file was:

git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar

Thanks
Bruce

[Daniel-Constantin Mierla]

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

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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
bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
I had a copy of the 4.1 branch on my local machine, the steps I
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce

[Asgaroth]

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 authorized and is not re-checked on the other 2
registrars :)

Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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
bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
I had a copy of the 4.1 branch on my local machine, the steps I
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce

[Daniel-Constantin Mierla]

Hello,

Post by Asgaroth
Hi,
using t_replicate() did the trick! it appears to be replicating to
both systems now, thanks alot for looking at this.

great, welcome!

Post by Asgaroth
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 authorized and is not re-checked on the other
2 registrars :)

Perhaps you can keep same r-uri and set different dst-uri via
$branch(...) variable.

Cheers,
Daniel

Post by Asgaroth
Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Post by Asgaroth
Hi,

Post by Daniel-Constantin Mierla
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
bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN
16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
I had a copy of the 4.1 branch on my local machine, the steps I
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce

[Aelfatihy]

Envoyé de mon iPad

Post by Daniel-Constantin Mierla
Hello,

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 shouldnt make any difference as the registration is already authorized and is not re-checked on the other 2 registrars :)

Perhaps you can keep same r-uri and set different dst-uri via $branch(...) variable.
Cheers,
Daniel

Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Hi,

The second one is with the patch to the code and it is enough to pick only that one.

/usr/sbin/kamailio[22158]: ERROR: tm [tm.c:1618]: t_replicate_uri(): bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Aelfatihy]

Envoyé de mon iPad

Post by Daniel-Constantin Mierla
Hello,

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 shouldnt make any difference as the registration is already authorized and is not re-checked on the other 2 registrars :)

Perhaps you can keep same r-uri and set different dst-uri via $branch(...) variable.
Cheers,
Daniel

Thanks
Bruce

Post by Daniel-Constantin Mierla
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

Hi,

The second one is with the patch to the code and it is enough to pick only that one.

/usr/sbin/kamailio[22158]: ERROR: tm [tm.c:1618]: t_replicate_uri(): bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Aelfatihy]

Envoyé de mon iPad

Hi,

The second one is with the patch to the code and it is enough to pick only that one.

/usr/sbin/kamailio[22158]: ERROR: tm [tm.c:1618]: t_replicate_uri(): bad replicate SIP address!
version: kamailio 4.1.4 (x86_64/linux) 43f4ee
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 43f4ee
compiled on 16:07:03 Jul 25 2014 with gcc 4.4.7
t_replicate("");
git clone git://git.sip-router.org/kamailio kamailio
cd kamailio
git checkout -b 4.1 origin/4.1
git pull origin
git cherry-pick -x c5b6b6021e75cd4e73f54f9131524b588709950c
make FLAVOUR=kamailio tar
Thanks
Bruce
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users