[asterisk-dev] Peer matching and SRV records

[Olle E. Johansson]

10 maj 2013 kl. 10:46 skrev Jaco Kroon <jaco at uls.co.za>:

> 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>:
>> 
>>> 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?
Contact me off-list to discuss 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.
Well, it won't give you support for subscribe, publish and quite a lot of other functions where you need SRV load balancing and failover. It will just help call setup. We do have func_srv.c today, but I personally don't feel it's a good long-term solution. A nice hack, but nothing more.

>> 
>>> 
>>> 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.
The code in pgtips is based on 1.8 but it should not be a lot of work to modify it to 11. I hope to have something finished by the end of the month, as we need to move on to stage 2 which involves some strange IMS-specific stuff.

/O
> 
> Kind Regards,
> Jaco
> <jaco.vcf>--
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130510/399b5bb4/attachment.htm>