Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda items forIETF Paris)

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 11 Jul 2005 18:01:50 -0400

But, now you have partitioned the PSTN into walled gardens.

It should not be a requirement for party B to opt-in to User ENUM for
the call to go through.  If the caller is in Carrier ENUM, the call
should still go through unless party B has blocked calls from party A.

Mike

> -----Original Message-----
> From: Michael Haberler [mailto:mah at inode.at] 
> Sent: Saturday, July 09, 2005 4:33 AM
> To: Michael Hammer (mhammer)
> Cc: enum at ietf.org
> Subject: RE: Carrier ENUM Definition (was RE: [Enum] Agenda 
> items forIETF Paris)
> 
> At 23:33 08.07.2005, Michael Hammer \(mhammer\) wrote:
> 
> >Following up on the question about hiding the points of interconnect 
> >between two carriers:
> >
> >1.  Does this mean that if party A has been assigned an ENUM number 
> >directly from a national authority and A tries to call party 
> B that got 
> >his number from a carrier X in club Y, that the ENUM query 
> for the SBC 
> >to access carrier X will be null because A is not in club Y?
> 
> A will be able to call B if B has opted in to User ENUM.

The requirement should be that an ENUM lookup will reveal B's carrier's
SBC.  B should not have to opt-in to User ENUM for this to work.

What happened to the one lookup requirement?

> 
> If A, a "User", looks in the carrier tree for B, he will find 
> X's SBC URI. 
> The session setup to this URI will fail though.

It should not fail, unless you want to force all users to have to user
carriers.

Mike

> >2.  Should the RR identifying the SBC to access carrier X 
> contain both 
> >sip and sips URI?  One for public access and one for private club 
> >access?  If I scan the DNS would I find these URIs?
> 
> sip or sips, they would be for "private club access". This 
> doesnt prevent a carrier to leave their SBC/ALG openly 
> accessible, but I dont expect that to happen frequently.
> 
> You would find them in the DNS, but they will not be 
> particularly interesting beyond giving the SBC/ALG URI.
> 
> -Michael
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Haberler <[email-masked]>
Date: Mon, 11 Jul 2005 18:50:33 -0400

At 00:01 12.07.2005, Michael Hammer \(mhammer\) wrote:
But, now you have partitioned the PSTN into walled gardens.
Sorry if I was unclear - you are right, that wasnt what I intended to say.
regarding scenario 1 (I'm unsure what you mean by "ENUM number"  in that 
context):

a) If A just obtains a number from the NP administrator, and has NOT 
subcribed to any carrier for routing that number in the PSTN, then  A is 
relegated to the User ENUM scenario - in which case A will be able to call 
B if B has opted in to User ENUM and A resolves B in the User ENUM tree.

b) if A is serviced by a carrier, and passes calls by some way (POTS, ISDN, 
IP) to him for delivery, then the call will obviously succeed through 
direct PSTN interconnect or carriers'carrier service delivering to X - 
standard PSTN case.

b1)  if A's carrier decides to resolve B's number in the carrier tree, 
finds the POI information for X, and has an agreement with X, then A's 
carrier will be able to pass the call to X on IP.

b2) If A's carrier decides to resolve B's number in the carrier tree, finds 
the POI information for X, and has NO agreement with X, then A's carrier 
will probably pass the call to X via the PSTN (again direct PSTN 
interconnect or carriers'carrier service delivering to X).

b3) If A's carrier decides to resolve in the carrier tree and doesnt find 
any POI information for X (= X doesnt user the carrier ENUm tree), again 
A's carrier will probably pass the call to X via the PSTN as above.

It should not be a requirement for party B to opt-in to User ENUM for
the call to go through.  If the caller is in Carrier ENUM, the call
should still go through unless party B has blocked calls from party A.
It isnt a requirement, sorry - I hit send too fast and hoped nobody will 
notice ;)
...
The requirement should be that an ENUM lookup will reveal B's carrier's
SBC.  B should not have to opt-in to User ENUM for this to work.
What happened to the one lookup requirement?
Noted - it should say: one DNS lookup per tree (carrier or user) to resolve 
to a NAPTR.

It should not fail, unless you want to force all users to have to user
carriers.
I'm confused - are you saying that just because *user* A has some way of 
determining the POI of *carrier* X (servicing B) then X is *required* to 
accept the call from *user* A?

that's not how interconnection works - I guess this is a misunderstanding.
Nobody is forced to use a carrier just because he owns a E.164 number 
(subject to local regulatory mileage) - but it helps reachability to the 
non-user ENUM enabled part of the E.164 space a lot.

-Michael