[Asterisk-Users] SIP URIs and ENUM or other types of lookup

[asterisk at lists.styx.org]

This has been giving me a headache for a little while, so
I thought I would throw the question out to the list.

Imagine there is a database lookup function that takes place
that, given a number, returns call routing information. It
might be a postgresql lookup, it might be an enum lookup.

If I have something like:

exten => _.,1,LookUp(${EXTEN})
exten => _.,2,Dial(${RESULT})

Then the LookUp function has to deal with making sure the
number is properly filled in before returning ${RESULT}. For 
example, if I have a wildcard DNS record that looks like this:

*.3.9.3.0.0	IN	NAPTR 100 100 "u" "SIP+E2U" "!^+*00393(.*)!sip:\1 at pulver!" .
*.0.0.7.1	IN	NAPTR 100 100 "u" "IAX2+E2U" "!^+*(.*)!iax2:iaxtel/\1!" .

They won't work since the pattern matching and replacement code is unimplemented.
(not to mention the fact that bind barfs on the \1)

One way around this is to change line 2 in the example to 

exten => _.,2,Dial(${RESULT}/${EXTEN})

and return records from Enum that will have the form Technology/Peer
as usual -- i.e.:

*.0.0.7.1	IN	NAPTR 100 100 "u" "IAX2+E2U" "!^.*$!iax2:iaxtel"

which gets transformed into IAX2/iaxtel.

Fine, but what about SIP which wants a string that looks like
SIP/extension at host?

Of course the SIP code in asterisk could be changed so that we could use
SIP/host/extension and rewrite it internally so that we could use the 
same form for the Dial commands without writing ugly special case extensions
to do the string splitting and glueing for us.

But that would sort of break SIP. A SIP URI is extension at host, so it makes
sense that the code is as it is, so there is an argument against such
a change.

On the other hand it would be very nice to be able to manipulate dial
strings in a consistent way -- especially when the dialing information
is returned in a generic way by functions like EnumLookup()

Is there any standard way to deal with this? To make something like
SIP/foobar/1234 work?

Or perhaps the real answer is to fill in the pattern matching code in
enum.c. Except that I have run into this problem in other contexts as
well...

Cheers,
-w