[asterisk-dev] Peer matching and SRV records

[Jaco Kroon]

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.

My scenarios only have one IP in the A RRs but I do have multiple SRV
RRs for all of _sip._udp, _sip._tcp and _iax._udp.

To add further insult to injury, an *outbound* Dial() also won't use
secondary SRV RRs, it'll only go to the first "picked" host, and only
use that, so even if timers expires and we're unable to contact the
remote side ... the call WILL fail.  One way to do this would be to
construct a list of contact points, and for SIP at least only use the T1
timer to cycle through them with INVITEs, first one to respond ... grabs
it, if they all fail, send to all of them at the same time with the T2
timer, first one to respond grabs it, any other responses simply gets
CANCELed.  I can see a great many number of holes in this strategy, but
it may be a starting point for someone else to start thinking from.

This applies to both SIP and IAX/2 (and probably other protocols that I
don't even know about).

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.

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.

Kind Regards,
Jaco Kroon
On 19/04/2013 11:48, Olle E. Johansson wrote:
> Friends,
>
> Looking into the SRV record support of Asterisk I believe there's an issue with peer matching here.
>
> If a service, like "edvina.org", have multiple SRV records that points to multiple hosts IPs, maybe even dual stack, then a request FROM that service
> may come from any of these IPs.
>
> Let's assume the configuration looks like this:
>
> register=marko:okram at edvinaservice/callback
>
> [edvinaservice]
> type=peer
> host=edvina.org
>
>
> In this case the peer will pick one address from the SRV records and use for matching. If another server IP is used on the
> server side, matching will fail.
>
> I would like to be able to add all available IP addresses and ports for matching. Will that work with the ao2object list or will it
> mess up the list to have many hash entries for the same object?
>
> The way I would like to do this is to set up an ACL entry in the peer for the SRV record so we have a list to go through
> and perform the matching on. If that list is empty, we will match as before.
>
> Thoughts?
> /O
> --
> _____________________________________________________________________
> -- 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/20130419/8f2c3442/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .eml_jaco.png
Type: image/png
Size: 26699 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130419/8f2c3442/attachment-0001.png>
-------------- 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/20130419/8f2c3442/attachment-0001.vcf>