[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Enum] I-D Action: New draft - draft-bellis-enum-send-n-00
>
> I am certainly not going to argue with a Neustar employee about the
> realities of deploying and managing this sort of stuff...
But anyone familiar with the realities of the E.164 plan and its national
implementations would tell you exactly the same thing. There is no
centralized registry describing the structure of the totality of E.164 plan.
We've had the issue of various here for years especially given the structure
of the German and Austrian dialing plans.
The business/technical case here is self evident. The issue is do you use
the DNS to reveal the structure of the national dial plan or use some out of
band method to describe the structure.
I understand the issue of post dial delay intimately since it also comes up
in how the ENUM query is to be preformed and by what network element and if
the "directory" is THE DNS or simply a IPRD (big fat cached ANS- ENUM box)
located in the carrier network that has its data store fed from various
forms of numbering data sources (Private ENUM).
I know people hate timers but the solution proposed here is probably worse
than the problem.
> But from a UAC perspective the solutions for variable length numbers
> suck. Overlap dialing is problematic at best, and timers don't give an
> adequate user experience. Provisioning is ok if you are deploying in a
> place with a simple, generally fixed length numbering plan, with few
> and
> easily knowable exceptions. But as soon as you throw in international
> dialing or deploy in a place with variable number lengths on anything
> approaching a per-number basis it doesn't work.
>
> Requirements to solve this keep coming up from marketing.
>
> A good (hypothentical) use case is:
>
> - install a sip "pbx" in a german hotel, with a short main number
> and longer room numbers.
>
> - connect that hotel to a sip service provider
>
> - connect some other sip clients (unaffiliated with the hotel)
> to the same sip SP. Let these be adapters to black phones.
>
> - try to call the desk and the rooms of the hotel from
> those clients. Give as good a user experience to the caller
> as before switching from pstn to sip on both sided.
> (Namely no lag after dialing the last digit before getting
> ringback.)
>
> - also have those clients call another hotel that is still
> only on the PSTN, using redundant GWs on the SP network.
> Again give as good a user experience as before.
>
> Paul
>
> Richard Shockey wrote:
> > In line...
> >
> >>
> >> We still need a *workable* solution to the overlap dialing issue.
> >> (People don't consider timers to be adequate.)
> >>
> >> This seems like the only real solution to that.
> >>
> >> > 2. If such a standardization effort should be undertaken, should
> the
> >> IETF do
> >> > it? Since we're trying to close down ENUM, this would be done
> >> somewhere
> >> > else I believe.
> >>
> >> If we want it available via a protocol (and I think that is far
> >> preferable to a word doc), and if it is to at least play nice with
> >> enum,
> >> then ietf seems like a suitable place. But I am not really
> familiar
> >> with> the alternatives.
> >
> >
> > I'm told Geneva is very pleasant in the springtime. I highly
> recommend Le
> > boufe rouge restaurant. Excellent French bistro food.
> >
> >>
> >> Re the numbering authorities: Obviously they must have a role in
> this.
> >> But it is not nice if we have to wait for a national numbering
> >> authority
> >> to report that some number that was assigned to a hotel in germany
> now
> >> may end in either "0" or "[1-9]xxx". The reporting needs to be
> more
> >> direct from those who implement the behavior.
> >
> > Numbering is, has been and will continue to be a nation state issue.
> My own
> > sentiment is that this is a out of band data point that it will be
> very
> > difficult implement as a protocol. For in country calls ..its a
> network
> > element configuration issue.
> >
> >
> > For out of country calls ..give the call to your termination partner
> and let
> > them sort it out (a trunking decision).
> >
> >>
> >> Paul
> >>
> >
> >
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum