RE: New I-D:draft-kaplan-enum-source-uri-00.txt
Hadriel Kaplan <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
Yes exactly - it lets you do this:
+--------------+
| PSTN routing |
| logic & DB |
+--------------+
|
|
+------------+ INVITE +--------+ ENUM+EDNS query +--------+
| Call | --------> | SIP | --------------> | ENUM |
| Processing | | app | | server |
| Device | <-------- | server | <-------------- | |
+------------+ 302 +--------+ ENUM response +--------+
OR, this:
+--------------+
| PSTN routing |
| logic & DB |
+--------------+
|
|
+------------+ ENUM+EDNS +--------+
| Call | --------> | ENUM |
| Processing | | server |
| Device | <-------- | |
+------------+ ENUM resp +--------+
-hadriel
> -----Original Message-----
> From: Dwight, Timothy M (Tim) [mailto:[email protected]]
> Sent: Wednesday, December 12, 2007 2:12 PM
> To: [email protected]
> Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>
> I agree with Richard as to the need. There are many cases in which the
> response to the ENUM query needs to be different, depending on "where
> the query came from". The latter phrase sometimes refers to the
> caller's telephone number (e.g., in the case of selecting a PSTN gateway
> to which to terminate the call, you need to determine whether calling
> and called party are in the same rate center and if so, select an
> ingress point to the appropriate class 5 exchange; otherwise select an
> ingress point to the long distance network) and sometimes to the
> "administrative entity" from which you received the call (carriers may
> have business arrangements that they need to honor, e.g., a special set
> of ingress points for business partners).
>
> Today there are products that can vary the ENUM query response based on
> information not present in a standard DNS/ENUM query. Usually they
> combine an application server that supports both PSTN routing and SIP
> redirect, and an ENUM server. Sorta like this:
>
> +--------------+
> | PSTN routing |
> | logic & DB |
> +--------------+
> |
> | (augmented?)
> +------------+ INVITE +--------+ ENUM query +--------+
> | Call | --------> | SIP | --------------> | ENUM |
> | Processing | | app | | server |
> | Device | <-------- | server | <-------------- | |
> +------------+ 302 +--------+ ENUM response +--------+
>
>
> I suppose there must be a proprietary interface between the two; which
> Hadriel's proposal might standardize. That seems useful.
>
> I agree that SIP redirect overhead is much higher than that of a
> DNS/ENUM query. As diagrammed above this wouldn't go away, because the
> "dumb" call processing device still needs to talk to the "smart" app
> server, and SIP redirect is typically the only way to do so. However
> obviously there are "smart" call processing devices that implement, or
> can implement, PSTN routing logic. In that case performance might
> improve substantially.
>
> Whether this has to be done by enhancing the DNS/ENUM query as the draft
> suggests, I'm not close enough to the implementation to say.
>
> Tim
>
>
> > -----Original Message-----
> > From: Richard Shockey [mailto:[email protected]]
> > Sent: Wednesday, December 12, 2007 12:05 PM
> > To: 'Hadriel Kaplan'; 'Otmar Lendl'
> > Cc: [email protected]; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja Gopal'
> > Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
> >
> >
> > Chair hat off..
> >
> > It is worth noting again that this is NOT intended for
> > e164.arpa or probably
> > any domain within the single root DNS.
> >
> > Adding a new protocol for this function would guarantee it
> > would not be
> > used...ever.
> >
> > The DNS protocols have been "fiddeled" with so long they are barely
> > recognizable as it is. I don't see what the problem is.
> >
> > The issue of identifying where the query is coming from was
> > an issue in my
> > CNAM draft. Though it did not require identification and
> > authentication it
> > just as easily could have. The issue in using 3761 for CNAM
> > queries was much
> > more practical.
> >
> > No vendor at this stage of ENUM deployments is ever going to
> > put another
> > protocol stack in the softswitches or SMB's for this type of number
> > translation function. In order to deploy a working protocol
> > to deal with a
> > specific use case like this you deal with the cards your
> > dealt and in this
> > case again that is 3761.
> >
> > Obviously people using SIP redirect for number translations
> > don't have this
> > problem but we all know what the issues with SIP redirect
> > are, for one you
> > get a 10X performance hit on query-response time.
> >
> > The first order issue to resolve is, does this proposal identify a
> > practical problem in ENUM deployments that needs to get
> > fixed, and IMHO the
> > answer to that is unquestionably YES.
> >
> > >
> > > > As this is not for e164.arpa, but private trees instead, do you
> > > actually
> > > > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just
> > > used
> > > > as a simple query protocol into a single database?
> > >
> > > Both. The sub-tree model is incredibly useful for scaling
> > in bigger
> > > networks or handling federations/registries, and it's also the case
> > > that it sometimes is just a simple query protocol to a single DB.
> > >
> > > -hadriel
> > >
> > > _______________________________________________
> > > enum mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/enum
> >
> >
> > _______________________________________________
> > enum mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/enum
> >
>
> _______________________________________________
> enum mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/enum