Re: [asterisk-users] srv records not being honoured properly
On Sun, 2008-10-19 at 21:14 +0300, Kevin P. Fleming wrote: > > Never mind... I was mistaken. The srv_callback() function puts the > records returned by the DNS lookup into priority order (lowest numbers > first), Yes, I can see that function and while I have not audited it detail, it looks as though it was at least intended to sort by priority. > So, in both Asterisk 1.4 and 1.6, the SRV record lookups > should choose the lowest-priority, highest-weight entry returned by the > DNS lookup. So it seems. I wonder why I have evidence that it is not actually working. Asterisk even told me: -- ast_get_srv: SRV lookup for '_sip._udp.tollfree.sip-happens.com.' mapped to host ares.sip-happens.com, port 5070 And while unfortunately those SRV records don't exist any more (because I complained to the sip-happens.com guys about their ares server not working and they just removed the ares record rather than having it at a lower priority) so we can't test it again, I am positive when I manually inspected the SRV records sometimes.sip-happens.com had a lower priority (the first of the two numbers in the RR right?) than ares.sip-happens.com. It might be worthwhile writing a small unit test for ast_get_srv that just calls it 100 times on a set of dns records that should replicate the problem and see how many times it's correct vs. not correct. Except for having to cobble up an "ast_channel *" it might not be that terribly difficult. On second thought (or having tried at least) maybe not. Just trying to pull main/srv.o into a unit test unravels a whole nest of dependencies. > There still isn't any failover, but we are least choosing > the correct single record from the list in DNS. Right, which would be the minimum requirement in my mind. Anything less and one shouldn't even implement it. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
Kevin P. Fleming wrote: > I guess I'm wrong then... the weight processing is in 1.4 already, and > hasn't changed in 1.6. You are right, though, that there doesn't seem to > be any priority ordering, which seems odd because it should be simple. > I'll see about adding that to 1.6. Never mind... I was mistaken. The srv_callback() function puts the records returned by the DNS lookup into priority order (lowest numbers first), and then the process_weights() function sorts by weight within each priority. So, in both Asterisk 1.4 and 1.6, the SRV record lookups should choose the lowest-priority, highest-weight entry returned by the DNS lookup. There still isn't any failover, but we are least choosing the correct single record from the list in DNS. -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
Brian J. Murrell wrote: > That would be in ast_get_srv() then? In 1.4.17 I do see weight > processing but not priority processing. I'd just go look at the code > for 1.6.1 at svn.digium.com but that server does not not seem to be > responding. Reachable but HTTP requests seem to not be completing. The HTTP viewer for SVN is down right now, due to being attacked by spiders/robots/etc. and making the hosting server unusable. You can check it out directly with SVN (even just a single file), or look at the tarballs on downloads.digium.com. > Strangely enough, I think priority processing is more important than > weight processing. If I were only going to implement one or the other I > would have chosen priority I think. I guess I'm wrong then... the weight processing is in 1.4 already, and hasn't changed in 1.6. You are right, though, that there doesn't seem to be any priority ordering, which seems odd because it should be simple. I'll see about adding that to 1.6. -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Sun, 2008-10-19 at 13:31 +0300, Kevin P. Fleming wrote: > > Asterisk 1.6 supports proper SRV record sorting, so that the lookups > will return the correct record to the module that requested the lookup. That would be in ast_get_srv() then? In 1.4.17 I do see weight processing but not priority processing. I'd just go look at the code for 1.6.1 at svn.digium.com but that server does not not seem to be responding. Reachable but HTTP requests seem to not be completing. Strangely enough, I think priority processing is more important than weight processing. If I were only going to implement one or the other I would have chosen priority I think. > However, the channel drivers still don't maintain any state information > about records that have failed and then use that to failover to other > records. Indeed. This seemed to be my observation when I took a quick peek at 1.6.1 yesterday. > There are plans to extend the Asterisk DNS code (dnsmgr) to be > able to provide this functionality, but like everything else, it's on > the to-do list :-) Indeed. That never ending to-do list. :-/ b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
Brian J. Murrell wrote: > Not to this point, no. 1.4 does everything I want and if it ain't > broke, don't fix it. Well, now it's broke I guess. Still, Ubuntu still > uses 1.4 and I don't like having to maintain my own packages. Asterisk 1.6 supports proper SRV record sorting, so that the lookups will return the correct record to the module that requested the lookup. However, the channel drivers still don't maintain any state information about records that have failed and then use that to failover to other records. There are plans to extend the Asterisk DNS code (dnsmgr) to be able to provide this functionality, but like everything else, it's on the to-do list :-) -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Fri, 2008-10-17 at 12:11 -0500, Tilghman Lesher wrote: > > Have you considered upgrading to 1.6? Not to this point, no. 1.4 does everything I want and if it ain't broke, don't fix it. Well, now it's broke I guess. Still, Ubuntu still uses 1.4 and I don't like having to maintain my own packages. > I believe it is fixed in that branch. I think I'd sooner (backport a) fix (it) and offer it back upstream before I'd go to maintaining my own packages. I can do it, I just have better things to do. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Friday 17 October 2008 11:46:09 Brian J. Murrell wrote: > On Fri, 2008-10-17 at 11:35 -0500, Eric "ManxPower" Wieling wrote: > > If you fight Asterisk's oddities then you will have a depressing and > > miserable life. If you embrace Asterisk's oddities then you will have a > > joyous and enlightened life. 8-) > > I just want something that works. :-) > > > I agree that if Asterisk has SRV support it should work in the way > > expected. The reason Asterisk's SRV support has not been fixed is > > because nobody with the skills has thought the issue was important > > enough to fix. > > ~sigh~ > > > Do you know any programming languages? > > I do and I'm pretty sure I could fix the problem. I just have so much > other stuff to do that I didn't really want to be an Asterisk hacker on > top of all that. Have you considered upgrading to 1.6? I believe it is fixed in that branch. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Fri, 2008-10-17 at 11:35 -0500, Eric "ManxPower" Wieling wrote: > If you fight Asterisk's oddities then you will have a depressing and > miserable life. If you embrace Asterisk's oddities then you will have a > joyous and enlightened life. 8-) I just want something that works. :-) > I agree that if Asterisk has SRV support it should work in the way > expected. The reason Asterisk's SRV support has not been fixed is > because nobody with the skills has thought the issue was important > enough to fix. ~sigh~ > Do you know any programming languages? I do and I'm pretty sure I could fix the problem. I just have so much other stuff to do that I didn't really want to be an Asterisk hacker on top of all that. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
Brian J. Murrell wrote: > On Fri, 2008-10-17 at 11:18 -0500, Eric "ManxPower" Wieling wrote: >> It should be fairly easy to write an AGI script that does the SRV query, >> do whatever you want with the response, set a channel variable with >> the results and use that in your dialplan. > > Maybe. If I were an AGI hacker. But really, should I (and every other > Asterisk user) have to? > If you fight Asterisk's oddities then you will have a depressing and miserable life. If you embrace Asterisk's oddities then you will have a joyous and enlightened life. 8-) I agree that if Asterisk has SRV support it should work in the way expected. The reason Asterisk's SRV support has not been fixed is because nobody with the skills has thought the issue was important enough to fix. Do you know any programming languages? -- Consulting and design services for LAN, WAN, voice and data. Based near Birmingham, AL. Now accepting clients worldwide. Contact me for Tellabs echo canceling systems. Also see http://www.fnords.org/skillslist.html ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Fri, 2008-10-17 at 11:18 -0500, Eric "ManxPower" Wieling wrote: > It should be fairly easy to write an AGI script that does the SRV query, > do whatever you want with the response, set a channel variable with > the results and use that in your dialplan. Maybe. If I were an AGI hacker. But really, should I (and every other Asterisk user) have to? b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
It should be fairly easy to write an AGI script that does the SRV query, do whatever you want with the response, set a channel variable with the results and use that in your dialplan. Brian J. Murrell wrote: > On Fri, 2008-10-17 at 10:32 -0500, Andres wrote: >> Because Asterisk does not support that. > > Which is just another way of saying Asterisk is broken then. SRV > records have requirements for their correct use. If those requirements > are ignored, that is a broken implementation. > >> The only thing that Asterisk >> does is use the first SRV entry > > First in terms of what was returned, not sorted by priority and weight, > right? > >> but it pays no attention to priorities >> or weights. It does not care about other SRV entries either. > > Tsk tsk tsk. > >> This is >> how things have been as long as I can remember. > > Wonderful. Nothing like half implementing standards. -- Consulting and design services for LAN, WAN, voice and data. Based near Birmingham, AL. Now accepting clients worldwide. Contact me for Tellabs echo canceling systems. Also see http://www.fnords.org/skillslist.html ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
On Fri, 2008-10-17 at 10:32 -0500, Andres wrote: > > Because Asterisk does not support that. Which is just another way of saying Asterisk is broken then. SRV records have requirements for their correct use. If those requirements are ignored, that is a broken implementation. > The only thing that Asterisk > does is use the first SRV entry First in terms of what was returned, not sorted by priority and weight, right? > but it pays no attention to priorities > or weights. It does not care about other SRV entries either. Tsk tsk tsk. > This is > how things have been as long as I can remember. Wonderful. Nothing like half implementing standards. b. signature.asc Description: This is a digitally signed message part ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] srv records not being honoured properly
Brian J. Murrell wrote: >Given the following SRV records: > >_sip._udp.tollfree.sip-happens.com. 38400 IN SRV 10 0 5060 >sometimes.sip-happens.com. >_sip._udp.tollfree.sip-happens.com. 38400 IN SRV 20 0 5070 >ares.sip-happens.com. > >Why is asterisk (1.4.17) not honouring the priority and not failing over >to using other records when a connection fails? > > > Because Asterisk does not support that. The only thing that Asterisk does is use the first SRV entry but it pays no attention to priorities or weights. It does not care about other SRV entries either. This is how things have been as long as I can remember. I am not sure about version 1.6 though. Andres http://www.neuroredes.com > > >___ >-- Bandwidth and Colocation Provided by http://www.api-digital.com -- > >asterisk-users mailing list >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] srv records not being honoured properly
Given the following SRV records:
_sip._udp.tollfree.sip-happens.com. 38400 IN SRV 10 0 5060
sometimes.sip-happens.com.
_sip._udp.tollfree.sip-happens.com. 38400 IN SRV 20 0 5070 ares.sip-happens.com.
Why is asterisk (1.4.17) not honouring the priority and not failing over
to using other records when a connection fails?
For a given call to tollfree.sip-happens.com ares.sip-happens.com was
chosen and tried before sometimes.sip-happens.com and additionally, when
the connection to ares.sip-happens.com was being refused there was no
roll-over to sometimes.sip-happens. Here's what asterisk did:
-- Executing [EMAIL PROTECTED]:23] Dial("SIP/anonymous-b5e02fd0",
"SIP/[EMAIL PROTECTED]||") in new stack
-- ast_get_srv: SRV lookup for '_sip._udp.tollfree.sip-happens.com.' mapped
to host ares.sip-happens.com, port 5070
-- Called [EMAIL PROTECTED]
[Oct 17 10:15:46] NOTICE[4973]: chan_sip.c:2920 auto_congest: Auto-congesting
SIP/tollfree.sip-happens.com.-081ddc28
-- SIP/tollfree.sip-happens.com.-081ddc28 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
And here's the packet trace:
10:15:16.612062 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:16.652721 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:17.613997 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:17.654697 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:18.611068 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:18.652786 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:20.614106 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:20.654785 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:24.614115 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:24.658934 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:32.615275 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:32.668930 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
10:15:48.614675 IP 67.193.213.184.5060 > 209.9.237.93.5070: SIP, length: 855
10:15:48.655403 IP 209.9.237.93 > 67.193.213.184: ICMP 209.9.237.93 udp port
5070 unreachable, length 556
So, as you can see, the priority was not honoured, nor was the alternate
SRV record used when there was a connection failure. Maybe that's
because it was looking for a lower priority. Is SRV handling in
Asterisk just broken? Or is this a known and fixed bug?
b.
signature.asc
Description: This is a digitally signed message part
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
