[asterisk-dev] Peer matching and SRV records

[Jaco Kroon]

Hi Olle,

On 10/05/2013 10:31, Olle E. Johansson wrote:
>
> 19 apr 2013 kl. 12:34 skrev Jaco Kroon <jaco at uls.co.za
> <mailto:jaco at uls.co.za>>:
>
>> Hi Olle,
>>
>> I can confirm your observations.  For this reason I've updated (or
>> initiated the process) to periodically resolve the SRV records
>> out-of-band and generate an updated configuration file that contains
>> all of the hosts.  I must further point out that (last I checked) it
>> gets even worse, if you have an A record with multiple IPs listed,
>> asterisk will only use one of those as well.
> I am not sure I like supporting round-robin DNS as the official
> recommendation is to use SRV records. The idea with round-robin DNS is
> not failover, but to load balance and this works perfectly well. 
> After som googling last week, I do realize too many people use rr DNS
> so we might have some optional support for it
> regardless of my personal feelings. It's not part of the current
> project though, my funding is only focused on SRV support.
Fine by me.  Not my use-case either ... and if you need load balancing,
I'd recommend doing it via SRV by adding multiple RRs with the same
priority, with potentially differing weights anyway.

-- snip --

>> I am currently working on fixing Dial() and SRV in SIP.
>>>
>>> This applies to both SIP and IAX/2 (and probably other protocols
>>> that I don't even know about).
>> The "other" protocol is out of scope for this project.
What would it take to include it?

>
>>
>> Currently my suggestion would be to deal with the outbound situation
>> in Dialplan(), and to generate multiple peer configs in the config
>> files, covering each host individually.  Obviously this implies that
>> you have to track DNS changes external to asterisk.  My setup also
>> utilizes the inbound ACLs for dealing with IAX/2 authorization (so
>> all peers will send IE username=foo, and [foo] will deny=all,
>> permit=${ips_from_srv_and_a_rrs}).  Still need to generate multiple
>> peers for outbound cases though.
> That sounds a bit messy to me. I have a more elegant solution based on
> the code. I don't know if it works yet, so thank you for your
> suggestion, I might have to revert to that if this fails ;-)
Not saying it's not messy, just saying it's something that can work
*now* without changes to the code.
>
>>
>> If you'd like to fix this in the code - something which should
>> probably done, and would be a better solution than my hack, but which
>> I suspect is going to be rather complex - I'd be more than willing to
>> help test for you.
> Looking forward to your test results.
As long as it applies to ast 11 :).  What's your time frames?  Trying to
decide how much effort to put into my messy idea or whether I should
wait for your patch?  I might base a patch for the "other" protocol off
of your work for SIP if it's reasonably trivial.

Kind Regards,
Jaco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130510/c711c66a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jaco.vcf
Type: text/x-vcard
Size: 231 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130510/c711c66a/attachment.vcf>