[asterisk-dev] Peer matching and SRV records

[Jaco Kroon]

Hi,

Ok, I suspect this is starting to derail from direct dev-work, but not
completely unrelated either as it does relate somewhat to possible
strategies regarding SRV implementation (I hope).

On 10/05/2013 10:56, Olle E. Johansson wrote:
>>>>
>>>> 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.
I'll be honest, most of that is over my head.  I know there is some
"device state" sharing between servers using openaix (IIRC?) or xmpp -
neither of which mechanism suitably covers my specific need (not saying
it can't, just haven't spent a lot of time on making it work).  My core
requirement in this case is call setup.  Mostly my "upstream" will
provide a SRV configuration (whether that is a set of asterisk servers
controlled by myself or by someone else - most ZA ITSPs gives me
single-IPs to register to ... I really do not grok that and for that
use-case it's not a problem either).

And my hack I can always provide a hint pointing to multiple devices, eg:

exten => uplink,hint,SIP/provider-1&SIP/provider-2&SIP/provider-3

Which again is probably somewhat messy, but for my use-case that would
work.  Except for some new work we're doing where the "client PBX" is
starting to go clustered (and there the hacks starts getting really
messy because now I need to somehow link those hints over the cluster,
openaix or xmpp seems to be my options).

>>>> 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.
Great.  I've now fully migrated pretty much all of my clients to
asterisk 11 and after an initial burst of bug reports and patches it now
seems to be quite stable.  Can easily do an install of 1.8 again on a
non-production machine to assist with testing, and would then be willing
to assist with the forward-port.  Would probably help me to get more
familiar with the asterisk code too.

Thanks for the feedback.  Much appreciated.  Gave me some things to chew on.

Kind Regards,
Jaco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130510/be3da7aa/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/be3da7aa/attachment.vcf>