[Home]

Summary:ASTERISK-04825: [patch] [post 1.2] ENUM Lookup for non SIP/IAX2/TEL...
Reporter:Andy Paumann - internic Datenkommunikations GmbH. (internic)Labels:
Date Opened:2005-08-12 09:52:10Date Closed:2006-03-03 05:37:29.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) enum-cvs-2005-08-12.patch
( 1) enum-cvs-2005-08-12-final.txt
( 2) enum-cvs-2005-08-12-latest.txt
( 3) enum-cvs-2005-08-12-no101.txt
Description:...if for a given number there is only a non SIP, IAX2, TEL entry, there is currently no jump to priority +101. Only the Error-Variable is set. As many customers only choose a different way to deliver the call when priority is changed to +101, I have patched the apps/app_enumlookup.c to jump to +101 also.

An initialization bug of a variable (tech) has also been fixed with this patch.





****** ADDITIONAL INFORMATION ******

Patch has been generated with diff -u and is attached to this report.

Patch is only for CVS version!!!
Comments:By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-12 09:54:55

Another fix within this patch is:

If the service type is unrecognized, the ENUM-Variable is set to the regexp'd value of the NAPTR regexp (and the jump to priority +101 is performed).

best regards

Andy
By: Olle Johansson (oej) 2005-08-12 10:19:50

Check my other patch for ENUMstatus and we'll see if we can agree on one patch instead of multiple...
By: Olle Johansson (oej) 2005-08-12 10:20:12

...since we are removing +101 jumps, not adding more.
By: Olle Johansson (oej) 2005-08-12 10:21:38

Remove your name and e-mail from all over the code, we're adding credits to CREDITS, not to source files. :-)
By: Michael Jerris (mikej) 2005-08-12 10:42:49

ASTERISK-4666 is already commited, please update your patch to use the return status var instead of +101 jumps and other changes as oej has suggested.
By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-12 11:30:14

Hi Oje,

I have just added the +101 jump to be backwards compatible like you did a few lines above. The variable ENUMSTATUS is set to BADURI (was already added).

The ENUM-Variable is set to the REGEXP (the resolved), if the user wants to do something with this returned value (Sending an Email, etc. ...) I think this is useful.

The tech variable is now initialized always and the service type is stored there (so the warning in app_enumlookup.c, line 146 looks sensefull and helps the user in identifying problems with his NAPTRs, fixed in enum.c).

Please tell me, if the above is OK for you or what else I should change.


The second-patch I uploaded now is without emails :-)

Best regards

Andy
By: Michael Jerris (mikej) 2005-08-12 11:35:52

we are really not adding any more +101's at all for any reason.  The return variable can be used to reproduce the same functionality.
By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-12 13:13:31

OK... +101 Jump has been removed from patch.
The other fixes are still in (enum...no101.txt Attachment)
By: Michael Jerris (mikej) 2005-08-12 13:24:43

also can you please get rid of the extra blank lines, and if you are going to comment out the return, you might as well remove it completely.
By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-12 13:49:52

Hi!

The blank lines have been removed and the return in remarks also.

Stored in ...final.txt
By: Michael Jerris (mikej) 2005-08-12 13:53:10

Ok, if you can track down some outside testers to try this out and make sure that works for them, that would be the next step on this.  One more aside, can we use a define instead of the magic number 512?
By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-12 13:59:26

OK...I will do so (As you know in Austria ENUM is already productive) we have several customers.

I will add a define for the 512 number also...just give me a few hours until I am back at my working place :-)

Which header-file would you suggest? Otherwise I will put it in enum.c directly.

Best regards

Andy
By: Olle Johansson (oej) 2005-08-12 17:04:44

Ooops. I was not aware that patch was committed... Sorry.
By: Andy Paumann - internic Datenkommunikations GmbH. (internic) 2005-08-29 07:06:44

Hi!

Is there anything else for me to do...as far as I understand all changes has been done...so no need for me for changing anything?

Best regards

Andy
By: Michael Jerris (mikej) 2005-08-29 07:38:08

As this is new funtionality, it is likely going to have to wait until after 1.2 is released before it can be commited.
By: Michael Jerris (mikej) 2005-09-13 22:39:11

this patch was probably quite affected by the commit this evening of ASTERISK-5063 which converted enumlookup to a function, and provided other enhancements to enumlookup.  Does any of that effect the need for this bug?
By: Olle Johansson (oej) 2005-11-18 02:24:01.000-0600

Can we get an update for the ENUMLOOKUP function instead, adopted for the current cvs head?

Thank you.

/O
By: Matt O'Gorman (mogorman) 2006-01-08 10:49:06.000-0600

it looks like enum.c is now uptodate and doesn't need that part of the patch, and it would be a fairly minor part to add it to func_enum.c, is it still needed / valid?
By: John Todd (jtodd) 2006-02-15 14:09:57.000-0600

I think this is patch is redundant given the new features in func_enumlookup.  Does anyone disagree?  I don't see any special abilities that this patch has that cannot be trivially reproduced in the dialplan with ENUMLOOKUP, but I could be missing something...
By: Olle Johansson (oej) 2006-03-03 05:37:27.000-0600

No answer from committer, seems redundant now. Thanks to everyone involved. Will re-open if anyone disagrees.