<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>19 apr 2013 kl. 16:47 skrev Jaco Kroon &lt;<a href="mailto:jaco@uls.co.za">jaco@uls.co.za</a>&gt;:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><font face="Helvetica, Arial,
        sans-serif">Hi,<br>
      </font><br>
      On 19/04/2013 16:30, Eric Wieling wrote:<br>
    </div>
    <blockquote cite="mid:616B4ECE1290D441AD56124FEBB03D081573D53AEE@mailserver2007.nyigc.globe" type="cite">
      <pre wrap="">I experienced similar issues.   Solved it in "userspace" rather than in the code.    For inbound we switched to username auth, though that is not an option for most use cases.   For outbound I wrote an AEL function using SRVLOOKUP to handle failover and priorities, based on the sample in the relevant RFC.</pre>
    </blockquote>
    Thanks for that - you just potentially saved me a LOT of work.&nbsp;
    Potentially.&nbsp; Unless you move your auth data into the dialplan
    though you're still stuck, unless there is some way to specify to
    use the settings from a specific peer in sip.conf or iax2.conf, but
    contacting a specific host, similar to the register =&gt; line that
    can be prefixed with a peer?&nbsp;</div></blockquote>Or use the realm based auth :-)<br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"> Eg:<br>
    <br>
    Dial(SIP/peername?server/1234)<br>
    <br>
    Type of thing?&nbsp; Would still be good (IMHO) to just be able to do:<br>
    <br>
    Dial(SIP/peername/1234) and have the channel driver deal with the
    SRV stuff at the back.&nbsp; <br></div></blockquote>Right.<br><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Also (and this is critical), as Olle pointed out, we can *receive*
    calls from any one of the hosts listed in the SRV records and
    asterisk needs to match it to the appropriate peer, so at a minimum
    just defining the peer with for example:<br>
    <br>
    [uls]<br>
    type=peer<br>
    host=voip.uls.co.za ; which has SRV records pointing to
    {morpheus,r2d2}.uls.co.za<br>
    <br>
    Should allow the SIP driver to match incoming calls from either r2d2
    or morpheus to this peer.&nbsp; That won't currently happen unless you
    set up multiple peers.<br>
    <blockquote cite="mid:616B4ECE1290D441AD56124FEBB03D081573D53AEE@mailserver2007.nyigc.globe" type="cite">
      <pre wrap="">
Are you convinced handling outbound SRV stuff in Asterisk is the right way, as opposed to handling it in the dialplan?</pre>
    </blockquote>
    For registration at a minimum yes.&nbsp; Question here is - do we
    register to ALL hosts, or only one, or some specified number?&nbsp; SRV
    records are supposed to deal with redundancy, so what happens f the
    host we're registered to crashes?<br></div></blockquote>We register with ONE. You do not register with a server, you register with a service. The registration should be replicated between servers.</div><div><br></div><div>Unless we implement SIP OUTBOUND where we register with multiple servers and keep flow active across NATs, but that's a different topic.<br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Just a random thought - my approach is to register to the whole lot
    (but I control the registered to hosts as well in most cases :).&nbsp;
    Other providers may not appreciate that.<br></div></blockquote>That's not the idea with registrations. You will get one forked call per registration and have to merge the INVITEs on your side.</div><div><br></div><div>/O<br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Kind Regards,<br>
    Jaco Kroon<br>
    <blockquote cite="mid:616B4ECE1290D441AD56124FEBB03D081573D53AEE@mailserver2007.nyigc.globe" type="cite">
      <pre wrap="">
---
Documentation for Polycom phones can be found at <a class="moz-txt-link-freetext" href="http://help.nyigc.net/">http://help.nyigc.net/</a>

________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</a> [<a class="moz-txt-link-abbreviated" href="mailto:asterisk-dev-bounces@lists.digium.com">asterisk-dev-bounces@lists.digium.com</a>] On Behalf Of Olle E. Johansson [<a class="moz-txt-link-abbreviated" href="mailto:oej@edvina.net">oej@edvina.net</a>]
Sent: Friday, April 19, 2013 10:26 AM
To: Asterisk Developers Mailing List
Cc: Olle E. Johansson
Subject: Re: [asterisk-dev] Peer matching and SRV records


19 apr 2013 kl. 16:17 skrev Jaco Kroon &lt;<a class="moz-txt-link-abbreviated" href="mailto:jaco@uls.co.za">jaco@uls.co.za</a><a class="moz-txt-link-rfc2396E" href="mailto:jaco@uls.co.za">&lt;mailto:jaco@uls.co.za&gt;</a>&gt;:

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.
Ok, did not think of that. Hmm.


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.

That's the stuff I'm targeting in SIP now. We should fail over as long as we have SRV priorities left.

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

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.

Please check the README for the new branch where I have jotted down some ideas. We have the dialplan support for resolving SRV records, I want to make it automatic in the SIp channel for both DIAL() a peer with SRV records and getting calls from them.

<a class="moz-txt-link-freetext" href="http://svnview.digium.com/svn/asterisk/team/oej/pgtips-srv-and-outbound-stuff-1.8/README.pgtips-srv-records">http://svnview.digium.com/svn/asterisk/team/oej/pgtips-srv-and-outbound-stuff-1.8/README.pgtips-srv-records</a>

No code yet, just moving around preparing stuff.


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.
Thank you for feedback. And thanks for the feedback on RTCP - will go through it soon.

The funding for this project is from Inteno Broadband Solutions. Proper SRV record support in Asterisk is something I wanted for years.

/O

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 "<a href="http://edvina.org">edvina.org</a><a class="moz-txt-link-rfc2396E" href="http://edvina.org/">&lt;http://edvina.org&gt;</a>", 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@edvinaservice/callback

[edvinaservice]
type=peer
host=<a href="http://edvina.org">edvina.org</a><a class="moz-txt-link-rfc2396E" href="http://edvina.org/">&lt;http://edvina.org&gt;</a>


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 <a class="moz-txt-link-freetext" href="http://www.api-digital.com/">http://www.api-digital.com</a> --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com/">http://www.api-digital.com</a> --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com/">http://www.api-digital.com</a> --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   <a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

<span>&lt;jaco.vcf&gt;</span>--<br>_____________________________________________________________________<br>-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> &nbsp;&nbsp;<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div><br></body></html>