[SR-Users] append_branch and t_replicate issue

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


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 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:
>> 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:
>>> 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140722/baa9890a/attachment.html>