Summary:	ASTERISK-01131: enumlookup goes to priority+1 on parse error
Reporter:	Michael Labuschke (zigman)	Labels:
Date Opened:	2004-03-02 06:12:24.000-0600	Date Closed:	2008-01-15 14:45:31.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-enum.patch
Description:	-- Executing EnumLookup("SIP/6845534-fbac", "491735645745") in new stack Mar  2 11:56:38 WARNING[294931]: enum.c:161 parse_naptr: Regex delimiter error (on "!^. *$!sip@home.zigman.de"). Mar  2 11:56:38 WARNING[294931]: enum.c:236 enum_callback: Failed to parse naptr :(    -- Executing BackGround("SIP/6845534-fbac", "enum-ok") in new stack
Comments:	By: Brian West (bkw918) 2004-03-02 10:58:09.000-0600 well fix your naptr record and it goes n+1 on no match (ie error in parse) and n+51 on tel: bkw By: James Golovich (jamesgolovich) 2004-03-02 13:07:09.000-0600 Should we be returning -1 on parse error so the call flow will stop?  That seems prudent, but if someone is depending on enumlookup in their callflow and something happens with the dns records then everything will be broken By: Michael Labuschke (zigman) 2004-03-02 19:16:35.000-0600 bkw  you are kidding me aren't you ? of course i can fix the naptr record... but thats a bug !!! when anything goes wrong with enum it should go to n+101 .. which it does when there is no enum entry.. but when there is a wrong one it should go there too... By: Brian West (bkw918) 2004-03-02 19:38:48.000-0600 no on parse error it should NOT return -1 and call flow should continue.  It should go n+101 now that I think about it.  But call flow SHOULD NOT STOP. By: James Golovich (jamesgolovich) 2004-03-02 21:00:01.000-0600 Try this patch out, especially to make sure it doesn't break anything.  It passes all my tests, but some extra confirmation would be good before I commit By: Mark Spencer (markster) 2004-03-02 22:01:23.000-0600 I'm also not yet convinced tha stopping call flow is the right thing to do.  Why should an invalidly parsed record be considered somehow different than a missing record? By: James Golovich (jamesgolovich) 2004-03-02 22:23:52.000-0600 Fixed in CVS.  Now invalid records are ignored, so call proceeds +101 By: Digium Subversion (svnbot) 2008-01-15 14:45:31.000-0600 Repository: asterisk Revision: 2311 U   trunk/dns.c U   trunk/enum.c U   trunk/srv.c ------------------------------------------------------------------------ r2311 | citats | 2008-01-15 14:45:30 -0600 (Tue, 15 Jan 2008) | 3 lines Make DNS callbacks return -1 on error, so invalid records are ignored (bug ASTERISK-1131) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2311 By: Digium Subversion (svnbot) 2008-01-15 14:45:31.000-0600 Repository: asterisk Revision: 2312 U   branches/v1-0_stable/dns.c U   branches/v1-0_stable/enum.c U   branches/v1-0_stable/srv.c ------------------------------------------------------------------------ r2312 | citats | 2008-01-15 14:45:31 -0600 (Tue, 15 Jan 2008) | 3 lines Make DNS callbacks return -1 on error, so invalid records are ignored (bug ASTERISK-1131) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2312