Re: Send-N draft: draft-bellis-enum-send-n-02 published

On Tue, Jul 01, 2008 at 03:34:55PM +0100, Clive D.W. Feather wrote:

> Because it's still load on the servers that would be worth reducing.

at least me would feel much more comfortable if this claim was substantiated
by facts, figures, measurements.

> > In the best case, maybe, but you need the cooperation of the clients
> 
> As is true of many optimisation techniques. That shouldn't be an issue for
> this use case.

Only if you can sanction non-optimizing clients; otehrwise the (perceived,
so far) gain only benefits the server, so why would the client dare to
implement the optional send-n feature?

> > add a lot of complexity to the ENUM tree.
> 
> I don't see how you can describe this as "a lot".

Adding a NAPTR for a significant fraction of all empty non terminals?
Thereby sacrificing the additional information that "ENT" might have given
you?

> > if you just let the client remember what a "full number" was; I've been
> > told this is already done.
> 
> What do you mean by a "full number"? The whole problem is that it isn't a
> simple thing to determine.

It is, once you succeded to placing a call there.  If the client (or the
PBX) remembers a list of dialed numbers, you can follow the digits until
you either match the number again or until you find the first differing
digit.  Of course, that's a client "cooperation", as well.  And from what
we've heard so far, it might not work well in AT.

-Peter