[sr-dev] Proposed Change to DMQ Notification Address Resolution

Robert Boisvert rdboisvert at gmail.com
Mon Mar 30 19:47:36 CEST 2015


Charles,

The parameter does make an important difference.  Instead of using host
names it uses explicit IP addresses which are saved in the DMQ structure.

I'm in the midst of several things right now so it will be faster if you
can push.  Next time, if it should happen, I will work with a pull
request.  Sorry for the extra work.

Thanks,
Bob

On Mon, Mar 30, 2015 at 12:13 PM, Charles Chance <
charles.chance at sipcentric.com> wrote:

> Hi Bob,
>
> Sorry for the delay.
>
> It all seems fine - the patch did not apply against the master branch, so
> I added it manually. I'm not sure we need the extra module parameter
> though, since it doesn't break existing functionality if only a single DNS
> record is present or an IP address is specified directly. Did you have a
> reason for adding the parameter?
>
> I can either push directly to master, or if you'd prefer you can create a
> pull request (again, master, not 4.2).
>
> Cheers,
>
> Charles
>
>
> On 23 March 2015 at 15:59, Charles Chance <charles.chance at sipcentric.com>
> wrote:
>
>> Hi Bob,
>>
>> Thanks for your patch. At quick glance it looks great but I will take a
>> closer look over the next 24 hours and report back.
>>
>> It is in my opinion a worthwhile addition and your time is very much
>> appreciated.
>>
>> Kind regards,
>>
>> Charles
>>
>>
>> On 20 March 2015 at 20:46, Robert Boisvert <rdboisvert at gmail.com> wrote:
>>
>>> Charles,
>>>
>>> I coded and tested the attached patch based on 4.2.3 code.  So as not to
>>> disturb current functionality, I add a modparam called "multi_notify".
>>> When set to a non-zero value it loads all IPs returned by the SIP URI,
>>> including those provided by DNS SRV records.
>>>
>>> With regard to your point about the notifications being sent to all
>>> nodes in the cluster, I noticed that if hosts A, B and C send notifications
>>> to D and D is not available when the cluster starts DMQ will not function
>>> even if D comes up some time later.  However, if I create a SRV record or A
>>> records that resolve to hosts D and E and send notifications to that group
>>> with multi_notify set to 1 then the cluster will always function as
>>> long as one either D or E is functional.  Even in a well-designed network
>>> servers may be unavailable for a period of time so this redundancy allows
>>> functionality to be preserved during downtime.
>>>
>>> We are having good success with this current patch and would like to
>>> request that it be mainstreamed.
>>>
>>> Thanks for considering this request and for your help,
>>> Bob
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>>>
>>
>>
>> --
>> *Charles Chance*
>> Managing Director
>>
>> t. 0121 285 4400    m. 07932 063 891
>>
>
>
>
> --
> *Charles Chance*
> Managing Director
>
> t. 0121 285 4400    m. 07932 063 891
>
> www.sipcentric.com
>
> Follow us on twitter @sipcentric <http://twitter.com/sipcentric>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150330/5d384127/attachment.html>


More information about the sr-dev mailing list