[SR-Users] Fwd: questions about FL_RPL flag in dmq_usrloc

Charles Chance charles.chance at sipcentric.com
Fri May 26 21:39:19 CEST 2017


Hi Julien,

Thankfully, today was a quiet day, although I appreciate the offer :)

Cheers,

Charles


On 26 May 2017 at 15:30, Julien Chavanton <jchavanton at gmail.com> wrote:

> Hi Charles, if you are too busy, I may be able to give you a hand, in such
> case you could push your branch.
>
> This seems like a basic required feature indeed
>
> Else have fun :)
>
> On Fri, May 26, 2017 at 4:50 AM, Charles Chance <
> charles.chance at sipcentric.com> wrote:
>
>> Hello,
>>
>> I did look at this a few weeks ago and made some progress, although due
>> to other commitments had to shelve it for a while.
>>
>> I have some time today so should hopefully have something for you to test
>> shortly.
>>
>> Cheers,
>> Charles
>>
>>
>> On 25 May 2017 at 09:56, 张顺通 <shuntongzhang at gmail.com> wrote:
>>
>>> Is there any progress? Thanks
>>>
>>> 2017-05-04 16:49 GMT+08:00 Charles Chance <charles.chance at sipcentric.com
>>> >:
>>>
>>>> Hello,
>>>>
>>>> I think in the case of a (re)register, the receiving server should
>>>> become authoritive for that contact and remove any FL_RPL which may be
>>>> present.
>>>>
>>>> I will take a look at this today/tomorrow along with the other issue
>>>> reported on Github.
>>>>
>>>> Cheers,
>>>> Charles
>>>>
>>>> On 4 May 2017 09:35, "张顺通" <shuntongzhang at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> In dmq_usrloc, a ucontact_t with FL_RPL flag will not send it's modify
>>>>> to other kamailio.
>>>>>
>>>>> For example, I have one edge and three kamailio(for register, name A B
>>>>> C). And First SIP REGISTER send to edge, and edge forward to register
>>>>> kamailio A, then kamailio B & C have FL_RPL flag, kamailio A do not
>>>>> have FL_RPL flag.
>>>>> In this situation,  If kamailio A is crash, the second SIP
>>>>> REGISTER(same call-id and tag) forward to kamailio B, kamailio B will not
>>>>> replicate reg info to C, because kamailio B have FL_RPL flag.
>>>>>
>>>>> What is the suggestion in this case?
>>>>> Thanks
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users at lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>>>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>>>> Birmingham Science Park, Birmingham B7 4BB.
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users at lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered 
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, 
Birmingham Science Park, Birmingham B7 4BB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170526/29054ab8/attachment.html>


More information about the sr-users mailing list