<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Helvetica, Arial,
sans-serif">Hi,<br>
</font><br>
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).<br>
<br>
On 10/05/2013 10:56, Olle E. Johansson wrote:<br>
</div>
<blockquote
cite="mid:B7781D19-23F9-44E7-9B8D-E638592C5330@edvina.net"
type="cite">
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote
cite="mid:CA7EF8A9-1B40-4478-B0B0-189D66545DDC@edvina.net"
type="cite">
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Helvetica,
Arial, sans-serif"> <br>
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.<br>
</font></div>
</div>
</blockquote>
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 ;-)</div>
</blockquote>
Not saying it's not messy, just saying it's something that
can work *now* without changes to the code.<br>
</div>
</blockquote>
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.</div>
</blockquote>
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).<br>
<br>
And my hack I can always provide a hint pointing to multiple
devices, eg:<br>
<br>
exten =>
uplink,hint,SIP/provider-1&SIP/provider-2&SIP/provider-3<br>
<br>
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).<br>
<br>
<blockquote
cite="mid:B7781D19-23F9-44E7-9B8D-E638592C5330@edvina.net"
type="cite">
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote
cite="mid:CA7EF8A9-1B40-4478-B0B0-189D66545DDC@edvina.net"
type="cite">
<div>
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix"><font face="Helvetica,
Arial, sans-serif"> 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.<br>
</font></div>
</div>
</blockquote>
Looking forward to your test results.</div>
</blockquote>
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.<br>
</div>
</blockquote>
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.</div>
</blockquote>
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.<br>
<br>
Thanks for the feedback. Much appreciated. Gave me some things to
chew on.<br>
<br>
Kind Regards,<br>
Jaco<br>
</body>
</html>