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
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 wrote:
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
On 21/07/2014 14:24, Bruce McAlister wrote:
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
On 22/07/14 09:55, Asgaroth wrote:
Hi,
On 22/07/2014 09:13, Daniel-Constantin Mierla wrote:
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 :) )
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
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, Asgaroth wrote:
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:
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:
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
On 24/07/2014 15:52, Daniel-Constantin Mierla wrote:
Hello,
On 24/07/14 17:29, Asgaroth 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.
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
On 24/07/2014 17:26, Daniel-Constantin Mierla wrote:
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.
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
On 24/07/14 19:34, Asgaroth wrote:
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.
Going to look at the code and add it if not something very complex.
Cheers, Daniel
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
On 25/07/14 09:31, Daniel-Constantin Mierla wrote:
Hi,
On 25/07/2014 11:03, Daniel-Constantin Mierla wrote:
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
On 25/07/14 12:20, Asgaroth wrote:
Yes, and this should work on existing versions 4.1.x or older
This one as well, but only with master branch.
Cheers, Daniel
On 25/07/2014 11:33, Daniel-Constantin Mierla wrote:
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
On 25/07/14 12:51, Asgaroth 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.
You have to use master or pick the commit to 4.1
Cheers, Daniel
On 25/07/2014 12:04, Daniel-Constantin Mierla wrote:
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@gmail.com 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@gmail.com 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
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
On 25/07/14 14:24, Asgaroth wrote:
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_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
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,
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
On 25/07/2014 18:41, Daniel-Constantin Mierla wrote:
Hello,
On 25/07/14 22:47, Asgaroth wrote:
great, welcome!
Perhaps you can keep same r-uri and set different dst-uri via $branch(...) variable.
Cheers, Daniel
Envoyé de mon iPad
Le 28 juil. 2014 à 11:06, Daniel-Constantin Mierla miconda@gmail.com a écrit :
Envoyé de mon iPad
Le 28 juil. 2014 à 11:06, Daniel-Constantin Mierla miconda@gmail.com a écrit :
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
On 25/07/2014 11:20, Asgaroth wrote:
Hello,
On 25/07/14 12:36, Asgaroth wrote:
yes, the patch is in the above sources tarball.
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
-
Aelfatihy -
Asgaroth -
Bruce McAlister -
Daniel-Constantin Mierla