asterisk users - Nov 2003 - SIP URIs and ENUM or other types of lookup

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@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@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@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

> *.3.9.3.0.0	IN	NAPTR 100 100 "u" "SIP+E2U"
"!^+*00393(.*)!sip:\1@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)
Try "!^\\+00393(.*)!sip:\\1@pulver!" and
"!^\\+(.*)!iax2:iaxtel/\\1!".
                                                                     
-- 
Maik Schmitt        http://graphics.cs.uni-sb.de/VoIP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20031120/b476e646/attachment.pgp

> But that would sort of break SIP. A SIP URI is extension@host, so it makes
No, A SIP URI is extension@domain - there's a big difference. Read on
DNS SRV records on
http://www.voip-info.org/tiki-index.php?page=DNS%20SRV

Quoting myself:
No one really mails user@mailserver any more. We're mailing user@domain and
the DNS MX records helps the mail client to send the mail to the
correct mail server. Why should we call user@sip-proxy instead of using
user@domain?

Remember that the later construction in addition to being user friendly, also
adds redundancy, and with a proper DNS configuration also may
add load balancing.

/O