Summary:	ASTERISK-00904: [request] SRV support requested for chan_iax2
Reporter:	John Todd (jtodd)	Labels:
Date Opened:	2004-01-23 23:03:34.000-0600	Date Closed:	2011-06-07 14:04:51
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	chan_iax2 should support DNS SRV records in much the same way that chan_sip does now.  This allows for useful remapping of domain or host records to telephony servers running IAX. ****** ADDITIONAL INFORMATION ****** It should be noted that the concepts of "aliases" must be supported, if they are not already.  I am unfamiliar with the code to where I could say that "iax2://jtodd@loligo.com" would work if the call was transmitted to a machine that thought it's name was "asterisk.loligo.com".  This may already be the case, but it's worth noting since SRV records imply redirection, perhaps from multiple unknown primary record sources.
Comments:	By: Olle Johansson (oej) 2004-01-24 12:51:58.000-0600 I remember that IAX seems to resolve the host only once, which is a problem. This was obvious when iaxtel.com moved to another IP address, we had to restart Asterisk to force a new reload. Maybe we should add a way to force a new resolve when the DNS record expires, when fixing DNS in chan_iax2.c, that would also add to stability and redundancy. By: John Todd (jtodd) 2004-01-26 16:36:38.000-0600 I agree, but that sounds like a bug and should probably be noted on a new bug ticket, as I would classify the ENUM SRV record usage as a "feature request". By: Mark Spencer (markster) 2004-05-01 17:28:30 Actually i'm not sure i would want either of these things to change -- certainly not without an option.  The fewer gethostbyname()'s the better, and as for SRV records, why would we need that?  You don't need them for HTTP.  You don't need them for IAX. Remember, IAX is about simplicity and elegance.  If you want complicated, buffer overflow-prone parsing, lots of needless network activity, redundant headers that confusingly mean the same thing, pointless service lookups, nat traversal complications, and audio bandwidth waste, stick with SIP. By: John Todd (jtodd) 2006-12-05 13:56:10.000-0600 Yes, you do need them for HTTP.  The fact that there is an entire industry building half-baked and barely functional "load-balancing" and "failover" methods for HTTP servers is a testament to the fact that the client protocol was poorly conceived in the first place with the single gethostbyname lookup - the client should be given the ability to make decisions for multiple paths or alternate ports.  Using or assuming single A records for destinations is overly simplistic and discounts the realities of what service providers encounter, or what high-reliability enterprises require.   That being said: I don't believe this should be built into IAX2.  I think that the ability to parse SRV records should be a separate function which can be solicited externally from the channel structures.  If the dialplan administrator wishes to build an iterative process to resolve, weigh, and create calls to different destination SRV components I believe they should have that ability but it does not necessarily need to be integral in the channel featureset.