RE: [Enum] sipping-e164 comments

[Richard Shockey <[e-mail]>]

>
>
>And of course, its too much concentrated on telephony and SIP issues, as the
>title suggests.
>Here I also agree with Lawrence with his comments to:
> > *     A general sip service should be used, not separate entries
> > for different
> >       media types ...
>IMHO opinion it should be the users choice, if he wants to have all services
>behind SIP or if he wants separate services (providers). Guidance should be
>given for both cases.
>
>I also see SG16 jumping up and down, but that may be resolved easily:
>First, many statements regarding SIP are also valid for h323,
>Second, its up to SG16 to write a similar paper, or even better, to upgrade
>this paper to a generic paper dealing with both (this would be a nice job
>for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever)

Personally I totally agree ... I think we'd welcome any document that looks 
at the issues surrounding ENUM and H.323 from SG16, TIPHON or any other 
source especially in light of SG16's work on the URL


http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-04.txt



>Taking the volume of the paper, there will be a lot of discussions
>necessary, on the first reading I have the follwing main issues:
>
>1. Policy:
>ENUM can only operate on full numbers, no private dialling plans ...
>I fully understand (and this is also (now) the understanding in SG2 and
>ETSI), that ENUM according to RFC2916 (currently) only is e164.arpa and full
>E.164 numbers. In ETSI we start to call this public ENUM.
>
>Also nobody prevents my company to implement within our network an IN-like
>ENUM-like service, which is totally separate from the public ENUM (called
>operator ENUM), eventually running in an extranet with other operators.

Correct ...



>The only way I see is, that the client returns a "incomplete number
>indication", if no NAPTR records are found in a query of an ENUM domain. The
>example Lawrence brought up is common with most companies in Germany and
>Austria. I like the proposal he made with the NAPTR record to the pilot
>number in Tier 1, but this raises a whole new issue in the administration
>theater. I would prefer this on Tier 2.


This is a good point for many reasons.  One additonal note that we all 
should keep in mind is that since 2916 is a global service using DNS all 
records will be esposed to the global internet ..therefore it is worth 
noting that only the minimal set of records necessary to set up a call 
should be exposed in the NAPTR records.


>4. "Tel" URLs
>
>I always had some problems with the "tel" URLs. In my understanding up to
>this point I could use "tel" URLs only if I had an operator providing a
>gateway to the GSTN. To use the tel: to make another lookup to ENUM for that
>number in ENUM was new for me. (Remark: I fully agree, that ENUM is not a
>system to change your forwardings every hour). So the "tel" URL is used in
>this case to point from your secondary number to your primary number, e.g.
>you have 2 E.164 numbers, but you want to put your NAPTRs only in the
>primary number, and in the other you have only permanetely the "tel" URL to
>the primary.

I dont like this either ... using tel URL's for call forwarding exposed 
personal preferences to the global internet ant those functions should be 
executed by either the SIP proxy.

Using Tel URL's for gateway location is also a bad idea since there may be 
N companies offering gateway services and that could increase the number of 
NAPTR records by an order of magnitude and create complexities for Client 
UA's on how to select a GW, not to mention pushing the DNS query into TCP.


>When I talked with Patrik last week on this issue, he confirmed, that this
>can be done (should be done?) also with CNAME Records.
>
>If this is the case, than I would propose only to use CNAME for this
>purpose. I also propose the following for "tel:"
>If a "tel:" is selected as the outcome of a query by the client on what
>preference ever, NO additonal ENUM query SHALL be done, the "Tel: Number"
>SHALL be used to set up a connection to this E.164 number, where ever it is
>(contact address in SIP terminology). Do not forget, a E.164 number may also
>terminate on IP (especially with h.323 ;-).


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: [phone]
<mailto: [e-mail]> or
<mailto: [e-mail]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


_______________________________________________
enum mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/enum