[asterisk-users] better enumlookup handler

[Brian J. Murrell]

On Wed, 2008-05-07 at 14:26 +0200, Johansson Olle E wrote:
> 
> Quoting RFC 3824:
> 
> "Only one SIP URI, ideally, appears in an ENUM record set for a
>        telephone number.  While it may initially seem attractive to
>        provide multiple SIP URIs that reach the same user within ENUM,  
> if
>        there are multiple addresses at which a user can be contacted,
>        considerably greater flexibility is afforded if multiple URIs are
>        managed by a SIP location service that is identified by a single
>        record in ENUM.

There are several problems with that.  In my use case, it's toll-free
handling by separate SIP providers being enumerated (generically -- i.e.
they return NAPTRs for any 18{00,66,88,etc.}* numbers) for all providers
registered to handle toll-free) by e164.org.  I'm not sure how feasible
it is to return a single SIP location service (I take that to mean a SRV
record) in that situation given that different providers have different
formats.  See from my previous e-mail, that for a given number, say,
18668823998 the following two SIP urls can be used:

sip:18668823998 at tollfree.sip-happens.com!" .
sip:16416418668823998 at sip.tollfreegateway.com!" .

I fail to see how something like that could be coded into a single
location service record.

Additionally, I'm not even sure multiple SRV records would be any
better.  Where is the handling of the fact that there is(/are multiple)
SRV records for a given SIP address done and how does rollover happen
when one of them returns CONGESTION, say?

>   Behavior for parallel and sequential forking in
>        SIP, for example, is better managed in SIP than in a set of ENUM
>        records."

Does this imply that if there are multiple SRV records for a resource,
say:

$ORIGIN mydomain.com
_sip._udp 3600 IN SRV 10 0 5060 asterisk1
_sip._udp 3600 IN SRV 10 0 5060 asterisk2

that Dial(SIP/2001 at mydomain.com) will in fact iterate over the SRV
records in the case of connection failure of one of them?

If so, I'm not sure how/if e164.org can translate their generic
toll-free NAPTR mapping into a working SRV service instead.

> We look forward to source code improvements!

I didn't really intend to bash ENUMLOOKUP() but was simply looking for
something more robust.  I am sure for the case of single NAPTR records,
ENUMLOOKUP() is just fine.  Sure I would like it more robust, but other
solutions exist so I'm willing to exercise them.

Well my understanding is that the enumlookup AGI script that I'm looking
for does what I want (and would like ENUMLOOKUP() to do) and that's
return all of the values from a single lookup (i.e. in an array or list)
rather than calling ENUMLOOKUP() iteratively for however many objects
exist.

Even the existing single record/iterative behaviour of ENUMLOOKUP()
would not be so bad if it kept state for each caller and actually did
return the successive records found from a single lookup rather than
doing a new lookup every time, possibly getting records in a different
order than it did last time (which of course results in handing back the
same record it did last time even though the record number counter has
been incremented).

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080507/6b8857cb/attachment.pgp