[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Enum] Fwd: I-D ACTION:draft-livingood-shockey-enum-npd-00.txt
Mike comments in line
-----Original Message-----
From: Michael Hammer (mhammer) [mailto:mhammer at cisco.com]
Sent: Tuesday, July 26, 2005 1:58 PM
To: McCandless, Kevin; Livingood, Jason; Richard Shockey
Cc: enum at ietf.org; Stastny Richard
Subject: RE: [Enum] Fwd: I-D
ACTION:draft-livingood-shockey-enum-npd-00.txt
Kevin,
"needs to be synchronized" Could you elaborate on what this requirement
means?
<KM> Yes, if NP records are placed into other databases, ENUM, then
those records need to be synchronized, updated, when changes are made in
the NPAC associated with the TN. If not, then you will have NP data in
ENUM that are no longer valid. The authoritative source is still the
NPAC for all ported numbers, (US specific in this discussion).
For example. Let's say I contract with a VoIP provider to port my
number to them as my service provider. Let's say also for argument's
sake that I have a WiFi-based phone as well as the old analog phone
connected to the PTT. Can the VoIP provider register my number into
Carrier ENUM immediately and have calls from other VoIP callers directed
to my WiFi phone immediately, along with all its features, without
waiting on the PSTN bureaucracy to provision the number as ported in the
TDM network?
<KM>Yes, but if the call originates from the PSTN then you still have
the time frames for processing a ported number. But for on Net to on Net
calls you should not have any delay, theoretically ;-) In reality, 99%
of VoIP originated calls are dumped onto the PSTN (US again). Ooops
I suspect I won't like the answer, but it might make glaringly obvious
how much room for improvement there may be to this porting process.
Wonder if we can get it down to less than one day (Web time).
Mike
> -----Original Message-----
> From: McCandless, Kevin [mailto:KMcCandless at verisign.com]
> Sent: Tuesday, July 26, 2005 11:53 AM
> To: Michael Hammer (mhammer); Livingood, Jason; Richard Shockey
> Cc: enum at ietf.org; Stastny Richard
> Subject: RE: [Enum] Fwd: I-D
> ACTION:draft-livingood-shockey-enum-npd-00.txt
>
> The NPD is authoritative and therefore the source for routing
> on ported numbers. This information can be replicated in the
> IP space but needs to be synchronized to the one in the TDM
> side ie the NPAC.
>
> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On
> Behalf Of Michael Hammer (mhammer)
> Sent: Monday, July 25, 2005 7:22 PM
> To: Livingood, Jason; Richard Shockey
> Cc: enum at ietf.org; Stastny Richard
> Subject: RE: [Enum] Fwd: I-D
> ACTION:draft-livingood-shockey-enum-npd-00.txt
>
> Agree completely. I think I hinted at the idea that the
> E.164 number could terminate in either the IP domain or TDM
> domain and still be included in ENUM.
>
> My concern about tying too tightly to NP was when I heard
> suggestion in other fora that ENUM add things like CLLI codes
> and other TDM elements, as well as anchoring ENUM to NP
> administrative processes. I may have misunderstood what was
> proposed, but it seemed headed in the wrong direction.
>
> Mike
>
>
> > -----Original Message-----
> > From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org]
> On Behalf
> > Of Livingood, Jason
> > Sent: Monday, July 25, 2005 3:50 PM
> > To: Michael Hammer (mhammer); Richard Shockey
> > Cc: enum at ietf.org; Stastny Richard
> > Subject: RE: [Enum] Fwd: I-D
> > ACTION:draft-livingood-shockey-enum-npd-00.txt
> >
> > Replies inline below.
> >
> > > I suspect that some 20 years in the future we will have something
> > > called the PSTN, but it will not look anything like the TDM
> > network.
> > > My only goal here is to not assume that the number portability
> > > databases and processes will automatically become the ENUM
> > databases
> > > and processes.
> > > As a result, I start with the assumption that number
> portability is
> > > purely a TDM mechanism that affect routing in the TDM
> domain. But,
> > > then acknowledge that certain information may bleed over
> > and be acted
> > > on in the IP domain.
> >
> > This is probably a fair assumption to make. However,
> simply because
> > the endpoints may not be IP-based, does not mean that the
> > data/addressing cannot be queried for over IP or that such
> data can be
> > distributed via IP networks.
> >
> > The motivation on my part grew out of a desire to consolidate both
> > on-net and off-net TN lookups into a single DNS query that hits my
> > ENUM server. Some vendors are (creatively) starting to propose
> > methods of doing so (to carriers at
> > least) that are vendor-specific (aka proprietary). As a service
> > provider, I have an interest in trying to standardize this
> so that I
> > have more potential software providers to choose from, more
> > competition, innovation, etc. I then have a open standards-based
> > method for querying for any addressing info associated with both
> > on-net and off-net TNs (not-IP-based, or not IP-based that
> I can route
> > to), as well as distributing such data around my IP network, etc.
> > since it all uses DNS and ENUM.
> >
> > > But, there have been others that have suggested that
> > somehow the ENUM
> > > registration change needs to be dependent on the number
> portability
> > > change, and I don't think that is necessary. If ENUM can
> > do it in one
> > > day, while NP takes several weeks, no sense in anchoring
> ENUM down.
> >
> > This should not in any way slow down or conflict with
> various national
> > NP processes.
> >
> > Jason Livingood
> >
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> >
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
>
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum