Subject: Re: [Enum] Summary on NoPSTN dicussion

From: Marian Durkovic <[email-masked]>
Date: Thu, 25 Mar 2004 19:07:59 +0100

Hi all,

   well, please read at the bottom what I've proposed in July last year...
I'd prefer to have a special subdomain in order not to clash with misdialed
numbers.

Jim>  BTW, what about NODATA responses from the DNS? ie The name
Jim> exists, but not as the QTYPE (NAPTR?) that was requested....

as for NODATA response - this contains "NOERROR, 0 answers, 1 authority"
so it's usable the same way as NXDOMAIN - the authority section contains
the name of the authoritative zone.

However, other problem exists here - this approach will only work if all
info is present in the same zone, which is fine for DDI ranges and 800
numbers but probably not for ENUM-only range, unless you're prepared to 
store all records for ENUM-only range in the same DNS zone. Once
you delegate something, the authoritative zone changes and you have to
rely on Tier-x to place the default records in their zones.

----- Forwarded message from Patrik F?ltstr?m <[email-masked]> -----

From: Patrik F?ltstr?m <[email-masked]>
Date: Thu, 10 Jul 2003 11:26:15 +0200
To: Marian Durkovic <[email-masked]>
Subject: Re: [Enum] Fwd: [Sipping] I-D ACTION:draft-ietf-sipping-e164-03.t xt
X-Mailer: Apple Mail (2.552)

On torsdag, jul 10, 2003, at 11:19 Europe/Stockholm, Marian Durkovic wrote:

>would you think this might be a solution?
>
>PBX prefix:   +421 5555 xxx
>
>ENUM client requests  1.1.1.5.5.5.5.1.2.4.e164.arpa.
>
>gets an answer: NXDOMAIN, authority record: 5.5.5.5.1.2.4.e164.arpa.
>
>Then the client performs a second query - either directly to
>
>5.5.5.5.1.2.4.e164.arpa.   or some well-known subdomain i.e.
>
>all.5.5.5.5.1.2.4.e164.arpa.
>
>and gets a NAPTR record with non-greedy regexpr.

The client doesn't send this second query. If it gets a NXDOMAIN that's 
it.

Or, what do I not understand?

   paf

>
>This IMHO is _no_ wildcard in DNS, is OK with DNSSEC and is one-to-many
>translation.
>
>	What do you think?
>
>
>		Thanks,
>
>			M.
>
>

----- End forwarded message -----

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: [email-masked]    ----
----                                                                  ----
--------------------------------------------------------------------------

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

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 21:59:05 +0100

Samia wrote:
==> This is the option we followed for the User-ENUM french trial : we stuck at the *real* numbering resources allocation. At Tier-1 registry we delegate blocks of E.164 numbers as they are in the real numbering plan.

Consequences :

- no "validation" problems

- no need for a ".tel" alternative root for Infrastructure-ENUM

Agreed, but the reason is that the French trial is IMHO more infrstructure ENUM than User-ENUM ;-)
Richard

§ºišŠX§‚X¬µéîš'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËb�ú?z{¦

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 22:08:34 +0100

Othmar wrote:

	>this is a cute idea, especially for DDI on PBXes. For 800 numbers,
	>this could be a replacement for freenum.org.
	 
	IMHO if it only solves this problem, it is worth pursuing it
	
	I see issues (not showstoppers) with it, though:
	
	>* I'm not sure whether the current resolver libraries are designed
	>to pass additional information returned in an error response back to
	>the calling application. The typical gethostbyname - type functions
	>certainly don't. I haven't seen a standardised API to NAPTR
	>queries yet (all the code I have seen (asterisk, ser) by now does
	>manual response parsing -- yuck.), maybe you're early enough to
	>get this added.
	 
	All proposed solution need some changes, so we could come to a result soon.
	
	>* The scheme only works on zone boundaries. If we (as 3.4.e164.arpa Tier1)
	>were to implement this on +43780 (which is under discussion as ENUM-only
	>number range) we would have to delegate 0.8.7.3.4.e164.arpa to ourselves
	>first, and then delegate individual numbers from within that zone.
	 
	Yes, Jim mentioned this already, but any solution puting a record into
	the tree has the same problem. But it can be done.
	If you want to avoid this, you need a second tree.
	
	>That violates our basic assumption that all delegation from the Tier1
	>will be within the 3.4.e164.arpa zone. Yes, one can program around
	>that, but it certainly won't make things easier for us.
	
	Who said live is easy ;-), I always thought you liked a challenge
	 
	Richard

z{�����x%��^��z��m��?�0�'�~���f��f��X��)ߣ���

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 22:31:17 +0100

T3RobWFyIHdyb3RlOg0KDQo+RXZlbiBpZiB0aGVyZSBhcmUgTkFQVFIgcmVjb3JkcywgeW91IHN0aWxsIG1pZ2h0IG5vdCBnZXQgYSBOQVBUUiB3aXRoDQo+ZW51bXNlcnZpY2UgZm9yIHZvaWNlLiBNeSBndWVzcyBpcyB0aGF0IHlvdSBzaG91bGQgaGFuZGxlIGJvdGggY2FzZXMNCj5pbiB0aGUgc2FtZSB3YXkuDQoNClRoaXMgaXMgYW4gaW1wb3J0YW50IGFyZ3VtZW50LiBDdXJyZW50bHkgdGhlIGNhbGwgaW4gdGhpcyBjYXNlIGlzIGZvcndhcmRlZA0KdG8gdGhlIFBTVE4sIHNvIHdlIHNob3VsZCBlaXRoZXIgZGVjaWRlIG5vdCB0byBkbyB0aGlzIG9yIHdlIG5lZWQgYSBzb2x1dGlvbg0KdG8gZ2V0IHRoZSBpbmZvcm1hdGlvbiBmcm9tIGRlbGVnYXRpb24gcG9pbnQuIElzIHRoZXJlIGEgd2F5IHRvIGZpbmQgdGhpcyBvdXQ/DQogDQpPZiBjb3Vyc2UsIGlmIHdlIGNob29zZSB2YXJpYW50IEIgKHRoZSBnbG9iYWwgc2hhZG93IHRyZWUpIHRoZXJlIHdvdWxkIGJlIG5vIHByb2JsZW0uDQogDQpSaWNoYXJkDQo=_______________________________________________enum mailing [email-masked]://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 29 Mar 2004 17:30:23 +0200

SGkgTWljaGFlbCwNCiANCldlIGFyZSB0cnlpbmcgdG8gZmluZCBhIHNvbHV0aW9uIGZvciB0aGUgZm9sbG93aW5nIHNjZW5hcmlvczoNCkEuIEFuIEUuMTY0IG51bWJlciByYW5nZSBpcyBvbmx5IGF2YWlsYWJsZSBhbmQgcm91dGFibGUgaW4gRU5VTQ0KQi4gQW4gRS4xNjQgbnVtYmVyIHJhbmdlIGlzIGF2YWlsYWJsZSB2aWEgUFNUTiBhbmQgdmlhIElQDQpDLiBBbiBFLjE2NCBudW1iZXIgcmFuZ2UgaXMgbm90IGFzc2lnbmVkIGF0IHRoZSBQU1RODQogDQpJZiBpbiBjYXNlcyBBIGFuZCBCIGFuIGVudHJ5IGlzIGV4aXN0aW5nIGluIEVOVU0sIG5vIHByb2JsZW0uDQpJZiB0aGUgcXVlcnkgcmV0dXJucyBOWERPTUFJTiwgdGhlIHByb2JsZW0gYXJpc2VzIGZvciB0aGUgDQpxdWVyeWluZyBzZXJ2ZXIgaG93IHRvIHByb2NlZWQuDQogDQpJbiBjYXNlIEEgdGhlIHNlcnZlciBtdXN0IG5vdCBmb3J3YXJkIHRoZSBjYWxsIHRvIHRoZSBQU1ROLCBiZWNhdXNlDQphIGxvb3AgbWF5IGJlIGNyZWF0ZWQuIEluIGNhc2VzIEIgYW5kIEMgaXQgbWF5IGZvcndhcmQgdGhlIGNhbGwgKG5vIGhhcm0pDQpidXQgaXQgaXMgbm90IG5lY2Vzc2FyeS4gSW4gY2FzZSBCIHRoZSBzZXJ2ZXIgY291bGQgdGVybWluYXRlIHRoZSBjYWxsIG9uIElQLA0KaW4gY2FzZSBDIHRoZSBzZXJ2ZXIgY291bGQgc2F5IG51bWJlciBub3QgYXZhaWxhYmxlIGFuZCBub3QgYm90aGVyIHRoZSANClBTVE4gYXQgYWxsLg0KIA0KSWYgd2UgZmluZCBhIHNvbHV0aW9uIHRoYXQgY292ZXJzIEEsIEIgYW5kIEMgbWF5IGJlIGNvdmVyZWQgYXMgd2VsbC4NCiANCkkgYWdyZWUgdGhhdCBpbiBmdXR1cmUgY2FsbCByb3V0aW5nIG1heSBiZSBpbXByb3ZlZCBmdXJ0aGVyIGluIGFjY2Vzcw0KdG8gTE5QIHNlcnZlcnMgb24gdGhlIFBTVE4gaXMgYXZhaWxhYmxlIGFuZCBhbHNvIGlmIGFjY2VzcyB0byBFTlVNDQppcyBhdmFpbGFibGUgb24gdGhlIFBTVE4gKHNvbWUgY2FycmllcnMgYXJlIGFscmVhZHkgd29ya2luZyBvbiB0aGlzKSwNCmJ1dCB0aGlzIHdpbGwgdGFrZSBzb21lIHRpbWUuDQogDQpXZSBzaG91bGQgYWxzbyBjb21lIHVwIHdpdGggYSBzc2VsZi1jb250YWluaW5nIHNvbHV0aW9uIG9uIElQIGFuZA0Kbm90IGFsd2F5cyByZWx5IG9uIHRoZSBQU1ROLg0KIA0KcmVnYXJkcw0KUmljaGFyZA0KDQoJLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLSANCglWb246IE1pY2hhZWwgSGFtbWVyIFttYWlsdG86bWhhbW1lckBjaXNjby5jb21dIA0KCUdlc2VuZGV0OiBGciAyNi4wMy4yMDA0IDE3OjQwIA0KCUFuOiBTdGFzdG55IFJpY2hhcmQgDQoJQ2M6IGlwdGVsQGlldGYub3JnOyBzaXBwaW5nQGlldGYub3JnIA0KCUJldHJlZmY6IFJlOiBbSXB0ZWxdIEZXOiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQoJDQoJDQoNCglSaWNoYXJkLA0KCQ0KCUdvaW5nIG91dCBvbiBhIGxpbWIgaGVyZSwgc2luY2UgSSBoYXZlIG5vdCBzZWVuIGFsbCB0aGUgcmVmZXJlbmNlZA0KCWRpc2N1c3Npb25zLiAgTXkgZmlyc3QgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBkZXNjcmlwdGlvbiBiZWxvdyBpcyBvdmVybGF5DQoJY29tcGxleC4NCgkNCglJIGhhdmUgYSBjb25jZXJuIHRoYXQgeW91IGFwcGVhciB0byBiZSBwcm9wb3NpbmcgdGhhdCB0aGUgRU5VTSBkaXAgd291bGQNCgloYXZlIGRlZmluaXRpdmUgYW5zd2VycyB0bzoNCglhKSB3aGV0aGVyIGEgbnVtYmVyIGhhcyBiZWVuIGFzc2lnbmVkIGFuZCB0aGVyZWZvcmUgcm91dC1hYmxlLA0KCWIpIHdoZXRoZXIgYSBudW1iZXIgdGhhdCBpcyBhc3NpZ25lZCB3YXMgZG9uZSwgYW5kIGlmIHNvIHdoZXRoZXIgdG8gYSBQU1RODQoJZW5kcG9pbnQgb3IgYW4gSVAgZW5kcG9pbnQuDQoJDQoJQW5vdGhlciBjb25jZXJuIGlzIHRoYXQsIGlmIHlvdSBkbyBnZXQgbG9vcGVkIHJvdXRpbmcgYmV0d2VlbiB0aGUgSVAgZG9tYWluDQoJYW5kIHRoZSBURE0gZG9tYWluLCB0aGlzIGlzIGxpa2VseSBhbiBpbmRpY2F0aW9uIG9mIGEgbGFjayBvZg0KCXN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBFTlVNIGRhdGFiYXNlIGFuZCB0aGUgTE5QIGRhdGFiYXNlLiAgT25lIG9yIHRoZQ0KCW90aGVyIGhhcyBpbmNvcnJlY3QgZGF0YS4gIEkgc3VzcGVjdCB0aGF0IHRoZXJlIG1heSBiZSB0aW1lIGxhZ3MgZnJvbSB3aGVuDQoJYW4gU1AgYXNzaWducyBhIG51bWJlciBhbmQgd2hlbiBpdCBnZXRzIHJlZmxlY3RlZCBpbiBvbmUgb3IgYW5vdGhlcg0KCWRhdGFiYXNlcy4gIElmIHlvdSB3YW50IHRoZSBFTlVNIGFuZCBMTlAgZGF0YWJhc2VzIHRvIGJlIHNvbWV3aGF0DQoJaW5kZXBlbmRlbnQsIHlvdSBtaWdodCB3YW50IGEgbG9vc2UgY291cGxpbmcgb2YgdGhlIHVzZSBvZiB0aGUgdHdvIHN5c3RlbXM6DQoJDQoJICAtSWYgZW5kcG9pbnQgaXMgVERNLCB0aGVuIHRoZSBFTlVNIGRhdGFiYXNlIHNob3VsZCBwb2ludCB0byB0aGUgUFNUTiwNCgl3aXRoIGRlZmF1bHQgYmVoYXZpb3IgYmVpbmcsIGlmIHVua25vd24gdG8gRU5VTSwgc2VuZCB0byBQU1ROIHRvDQoJcmVzb2x2ZS4gIChOb3RlIHRoaXMgaXMgb3J0aG9nb25hbCB0byBFTlVNcyB1c2UgdG8gc2VsZWN0IGFsdGVybmF0aXZlDQoJZW5kcG9pbnRzLikNCgkNCgkgIC0gSWYgZW5kcG9pbnQgaXMgSVAsIHRoZW4gdGhlIExOUCBkYXRhYmFzZXMgc2hvdWxkIHBvaW50IHRvIHRoZSBJUA0KCWRvbWFpbiwgd2l0aCBkZWZhdWx0IGJlaGF2aW9yIGJlaW5nLCBpZiB1bmtub3duIHRvIExOUCwgcm91dGUgaW4gdGhlIFBTVE4NCgl0byByZXNvbHZlLg0KCQ0KCVRoZSBkaWZmZXJlbmNlIGlzIGluIHRoZSBpbnRlcnByZXRhdGlvbiBvZiBhIGxhY2sgb2YgYSByZWNvcmQuICBJbiBMTlAsIGl0DQoJd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgc3RpbGwgb3duZWQgYnkgdGhlIG9yaWdpbmFsIHN3aXRjaCwNCgl3aGVyZWFzIGluIEVOVU0gaXQgd291bGQgbWVhbiB0aGF0IHRoZSBFLjE2NCBudW1iZXIgaXMgbm90IHJvdXRlLWFibGUgdG8gYW4NCglJUCBlbmRwb2ludC4gIEZyb20gYSBURE0gcGVyc3BlY3RpdmUsIHRoZSBlbnRpcmUgSVAgZG9tYWluIGNvdWxkIGJlIHZpZXdlZA0KCWFzIGEgc2luZ2xlIHN3aXRjaCBhbmQgdGhlIExOUCByb3V0aW5nIHNjaGVtZSBzaG91bGQgd29yay4gIFRoZSBjb252ZXJzZQ0KCSh3aGVuIHJlY29yZHMgZXhpc3QpIGNvdWxkIGJlIHRydWUgZm9yIEVOVU0uDQoJDQoJQSBnYXRld2F5IGJldHdlZW4gSVAtZG9tYWluIGFuZCBURE0gZG9tYWluLCB1cG9uIHNlZWluZyB0aGF0IGJvdGggYW4gTE5QDQoJYW5kIGFuIEVOVU0gZGlwIGhhdmUgbm90IHJlc29sdmVkIHRoZSByb3V0ZSwgY2FuIHNhZmVseSBjb25jbHVkZSB0aGF0IHRoZQ0KCW51bWJlciBpcyB1bmFzc2lnbmVkIGFuZCByZWxlYXNlIHRoZSBjYWxsLg0KCQ0KCUFjdHVhbGx5LCBpdCBtYXkgbm90IGJlIG5lY2Vzc2FyeSB0byBzZW5kIGEgc2V0dXAgbWVzc2FnZSB0byBhIEdXLCBub3IgaXMNCglpdCBuZWNlc3NhcnkgdG8gaGF2ZSB0aGUgRU5VTSBhbmQgTE5QIGRhdGFiYXNlcyBkdXBsaWNhdGUgZWFjaCBvdGhlci4gIEl0DQoJc2hvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIGFuIEVOVU0gREIgdG8gcXVlcnkgdGhlIExOUCBEQiBhbmQgcmVzcG9uZCB3aXRoIGFuDQoJYXBwcm9wcmlhdGUgYW5zd2VyLCBvciB0aGUgY29udmVyc2UuDQoJDQoJTWlrZQ0KCQ0KCQ0KCUF0IDA0OjIyIFBNIDMvMjUvMjAwNCArMDEwMCwgU3Rhc3RueSBSaWNoYXJkIHdyb3RlOg0KCT5Dcm9zcyBwb3N0aW5nIGZyb20gZW51bUBpZXRmLm9yZw0KCT5UaGUgZGlzY3Vzc2lvbiBpcyBnb2luZyBvbiB0aGUgZW51bS1saXN0DQoJPg0KCT5SaWNoYXJkIFN0YXN0bnkNCgk+T2VGRUcNCgk+KzQzIDY2NCA0MjAgNDEwMA0KCT4NCgk+DQoJPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJPkZyb206IFN0YXN0bnkgUmljaGFyZA0KCT5TZW50OiBUaHVyc2RheSwgTWFyY2ggMjUsIDIwMDQgMTowOCBQTQ0KCT5UbzogTWFyaWFuIER1cmtvdmljOyBsd2NAcm9rZS5jby51aw0KCT5DYzogZW51bUBpZXRmLm9yZw0KCT5TdWJqZWN0OiBbRW51bV0gU3VtbWFyeSBvbiBOb1BTVE4gZGljdXNzaW9uDQoJPg0KCT5EZWFyIGNvbGxlYWd1ZXMsDQoJPg0KCT5UaGVyZSB3YXMgYSBsb3Qgb2YgZGlzY3Vzc2lvbnMgb24tbGlzdCBhbmQgb2ZmLWxpc3Qgb24gdGhpcyBpc3N1ZSwNCgk+c28gSSB3aWxsIHRyeSB0byBzdW1tYXJpemUgYXQgbGVhc3QgbXkgdmlldyBvZiB0aGUgcHJvYmxlbS4NCgk+SSB3aWxsIGFsc28gaW5jbHVkZSBteSBjdXJyZW50IHZpZXcgb24gdGhlIDtlbnVtZGkNCgk+YW5kIHRoZSA7cHN0biBpbmRpY2F0b3IgZm9yIHRoZSB0ZWw6IFVSSQ0KCT4NCgk+RU5VTS1lbmFibGVkIFVBcyBhbmQgU2VydmVycyBhcmUgY3VycmVudGx5IHByb2Nlc3NpbmcNCgk+cmVjZWl2ZWQgRS4xNjQgbnVtYmVycyAoZWl0aGVyIGluIGEgdGVsOit4eHggVVJJIG9yIGluIGEgc2lwOiBVUkkNCgk+aW4gdGhlIGZvcm1hdCBzaXA6K3h4eHhAcHJvYy5uZXQ7dXNlcj1waG9uZSkgaW4gdGhlIGZvbGxvd2luZyB3YXk6DQoJPihmb3Igc2ltcGxpY2l0eSBJIGFtIG9ubHkgZGVhbGluZyB3aXRoIHZvaWNlIGNhbGxzKQ0KCT5QbGVhc2UgaG9sbGVyIGlmIEkgZ290IHNvbWV0aGluZyB3cm9uZyBvciB5b3UgZGlzYWdyZWUNCgk+DQoJPjEuIFF1ZXJ5IEVOVU0gKGluIGUxNjQuYXJwYSkNCgk+DQoJPjIuIGlmIGEgTkFQVFIgaXMgZm91bmQgd2l0aCBhbiAiZW51bXNlcnZpY2UiIHNpcCBvciB2b2ljZTpzaXAsDQoJPmhhbmRsZSB0aGUgY2FsbCBhcyBpZiB5b3UgaGF2ZSByZWNlaXZlZCBhIHNpcDogVVJJIGluIHRoZSBmb3JtYXQNCgk+c2lwOnVzZXJAcHJvdi5uZXQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KCT4NCgk+My4gSWYgYSBOQVBUUiBpcyBmb3VuZCB3aXRoIGFuICJlbnVtc2VydmljZSIgdm9pY2U6dGVsDQoJPjNhLiBhbmQgdGhlIHRlbDogVVJJIGlzIHBvaW50aW5nIHRvIGEgZGlmZmVyZW50IG51bWJlciwNCgk+cXVlcnkgRU5VTSBhZ2FpbiBmb3IgdGhpcyBudW1iZXINCgk+M2IuIGlmIHRoZSB0ZWw6IFVSSSBpcyB0aGUgc2FtZSBhcyB0aGUgQVVTLCBmb3J3YXJkIHRoZQ0KCT5jYWxsIHRvIHRoZSBQU1ROLCBpZiB5b3UgYXJlIGFibGUgdG8gZG8gc28uDQoJPg0KCT5Ob3RlOiBoZXJlIHRoZSBwcm9wb3NlZCA7cHN0biBpbmRpY2F0b3IgbWF5IGNvbWUgaW4gaGFuZHk6DQoJPkluIDNhIHlvdSBtYXkgdXNlIGl0IGluIHRoZSBOQVBUUiB0byBwcmV2ZW50IGEgc2Vjb25kIEVOVU0tcXVlcnkNCgk+YW5kIGZvcmNlIHRoZSBjYWxsIHRvIHRoZSBQU1ROLg0KCT5JbiAzYiB0aGUgc2VydmVyIG1heSBhZGQgO3BzdG4gdG8gaW5mb3JtIHRoZSBuZXh0IHByb3h5IGFib3V0DQoJPlRoZSBkZWNpc2lvbiB0byBmb3JjZSB0aGUgY2FsbCB0byB0aGUgUFNUTi4gT24gdGhlIG90aGVyIGhhbmQsDQoJPkluIHRoaXMgY2FzZSBhbHNvIHRoZSA7ZW51bWRpIGluZGljYXRvciBtYXkgYmUgdXNlZCBqdXN0IHRvIHByZXZlbnQNCgk+YW4gRU5VTSBxdWVyeS4gUmVzdWx0OiA7cHN0biBpcyB1c2VkIGluIEVOVU0gLSA7ZW51bWRpIGlzIHVzZWQgaW4NCgk+c2lnbmFsbGluZy4NCgk+DQoJPjQuIE5vdyB0aGUgcmVhbCBwcm9ibGVtIHN0YXJ0czogSWYgdGhlIEVOVU0tcXVlcnkgcmV0dXJucyBOWERPTUFJTiwNCgk+dGhlIGN1cnJlbnQgYXNzdW1wdGlvbiBvZiBhbGwgY2xpZW50cyBpczogdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZQ0KCT5QU1ROIGlmIHRoZSBzZXJ2ZXIgaXMgYWJsZSB0byBkbyBzbyAoZXZlbnR1YWxseSB3aXRoIHRoZSA7ZW51bWRpIHNldC4NCgk+DQoJPlRoaXMgbWVhbnMsIHdlIHJlZmVyIHRoZSBwcm9ibGVtIHRvIHRoZSBQU1ROLiBUaGlzIGlzIG5vdCBuaWNlIGZvcg0KCT52YXJpb3VzIHJlYXNvbnM6DQoJPjEuIHdlIGFyZSBib3RoZXJpbmcgdGhlIFBTVE4gaW4gc29tZSBjYXNlcyB1bm5lY2Vzc2FyaWx5DQoJPjIuIHRoZSBQU1ROIG1heSBub3Qga25vdyB3aGF0IHRvIGRvIGVpdGhlciBhbmQgYm91bmNlIHRoZQ0KCT5jYWxsIGJhY2ssIHdoaWNoIGlzIGNyZWF0aW5nIGxvb3BzDQoJPjMuIGFuZCBmaW5hbGx5OiB3aGF0IGFyZSB3ZSBkb2luZyBpZiB0aGVyZSBpcyBubyBQU1ROIGFueW1vcmUgOy0pDQoJPk9rLCB0aGlzIHNlZW1zIGZhciByZWFjaGVkLCBidXQgSW50ZXJuZXQgVGVsZXBob255IHNob3VsZCBiZSBmaW5hbGx5DQoJPnNlbGYtY29udGFpbmluZy4NCgk+DQoJPlNvIHdoYXQgYXJlIHRoZSBhZGRpdGlvbmFsIHBvbGljaWVzIHdlIG1heSB3YW50IHRvIHRlbGwgYW4gRU5VTS0NCgk+Y2xpZW50Pw0KCT4NCgk+MS4gTm8gc3VjaCBudW1iZXIgKHVuYXNzaWduZWQgbnVtYmVyKQ0KCT4xYS4gVGhlIHdob2xlIG51bWJlciByYW5nZSAobnVtYmVyIGJsb2NrKWlzIHVuYXNzaWduZWQNCgk+MWIuIFRoZXJlIGFyZSBudW1iZXJzIGFzc2lnbmVkIGluIHRoaXMgbnVtYmVyIHJhbmdlLCBidXQgaWYgeW91DQoJPmRvIG5vdCBmaW5kIG9uZSBpbiBFTlVNLCB5b3UgYWxzbyB3aWxsIG5vdCBmaW5kIG9uZSBvbiB0aGUgUFNUTiwgc28NCgk+aXQgbWFrZXMgbm8gc2Vuc2UgdG8gcm91dGUgaXQgdG8gdGhlIFBTVE4gKEVOVU0tb25seSkNCgk+Mi4gRGVmYXVsdCByb3V0aW5nIGZvciB0aGUgd2hvbGUgbnVtYmVyIHJhbmdlIChudW1iZXIgYmxvY2spIHRvIGEgVm9JUA0KCT5nYXRld2F5Lg0KCT4yYS4gVGhlIHdob2xlIGJsb2NrIGlzIHJvdXRlZCwgdGhlcmUgYXJlIG5vIGluZGl2aWR1YWwgZW50cmllcyBpbiBFTlVNDQoJPihlLmcuIDEtODAwIG51bWJlcnMpDQoJPjJiLiBUaGVyZSBhcmUgbnVtYmVycyBpbiBFTlVNLCBidXQgaWYgeW91IGRvIG5vdCBmaW5kIGFuIGVudHJ5LCByb3V0ZQ0KCT50aGUgY2FsbCB0byB0aGUgZGVmYXVsdCBnYXRld2F5IGdpdmVuLiBPbmUgZXhhbXBsZSBmb3IgdGhpcyBjYXNlIG1heSBiZQ0KCT5hIFZvSVAgcHJvdmlkZXIgb3BlcmF0aW5nIGFuIGlzbGFuZCBvbmx5IGNvbm5lY3RlZCB0byB0aGUgUFNUTi4gU29tZQ0KCT5vZiB0aGUgdXNlcnMgYXJlIGFsc28gaW4gRU5VTSAob3B0LWluKS4gSWYgaGUgcHJvdmlkZXIgbm93IG9wZW5zIHVwIGFjY2Vzcw0KCT50byB0aGUgSW50ZXJuZXQgdmlhIGEgZ2F0ZXdheSAoYm9yZGVyIGVsZW1lbnQsIC4uLiksIGhlIG1heSB3YW50IHRvIHJvdXRlDQoJPmFsbCBjYWxscyBmb3IgaGlzIHVzZXJzIG5vdCBpbiBFTlVNIHRvIHRoZSBnYXRld2F5IHByb3ZpZGVkIGJ5IGRlZmF1bHQNCgk+DQoJPkNhc2UgMWEgYW5kIDJhIGNhbiBiZSBkZWFsdCB3aXRoIGluIGUxNjQuYXJwYSB3aXRoIHdpbGRjYXJkcywgYmVjYXVzZSBubw0KCT5BZGRpdGlvbmFsIGVudHJpZXMgYmVsb3cgZXhpc3QuDQoJPkNhc2UgMWIgYW5kIDJiIGNhbm5vdCBiZSBkZWFsdCB3aXRoaW4gZTE2NC5hcnBhLCBiZWNhdXNlIHdpbGRjYXJkcyBkbw0KCT5ub3Qgc3VwcG9ydCB0aGlzLg0KCT4NCgk+VGhlIHNvbHV0aW9ucyBwcm9wb3NlZCBmb3IgdGhpcyBzb2ZhciBhcmUuDQoJPg0KCT5BLiB1c2UgdGFibGVzIGluIGVhY2ggc2VydmVyLiBUaGlzIGlzIG5vdCBhIGdvb2QgaWRlYSBhbmQgZG9lcyBub3QgaGVscA0KCT5FTlVNLWVuYWJsZSBVQS4gVGhlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBzdG9yZWQgaW4gYSBnbG9iYWwgYWNjZXNzaWJsZQ0KCT5hbmQgcHVibGljIGRhdGFiYXNlIChETlMpLg0KCT4NCgk+Qi4gdXNlIGEgKG9uZSwgY29tbW9uKSBzZWNvbmQgY29tbW9uIHRyZWUgKGUxNjRzaGFkb3cuYXJwYSwgd2hlcmUgeW91IHB1dA0KCT5pbiBvbmx5IHRoZSB3aWxkY2FyZHMgZm9yIHRoZSBudW1iZXIgcmFuZ2VzIGluIHF1ZXN0aW9uLiBUaGUgcHJvY2Vzc2luZw0KCT5hc3N1bXB0aW9uIG5vdyBzaG91bGQgYmU6DQoJPg0KCT5JZiB0aGUgRU5VTS1xdWVyeSByZXR1cm5zIE5YRE9NQUlOLCB0aGUgY2FsbCBpcyBub3Qgcm91dGVkIHRvIHRoZSBQU1RODQoJPkluIGFueSBjYXNlLCB0aGUgc2VydmVyIHF1ZXJpZXMgZTE2NHNoYWRvdy5hcnBhLCBhbmQgb25seSBpZiBubyBlbnRyeQ0KCT5pcyBmb3VuZCB0aGVyZSwgdGhlIGNhbGwgaXMgcm91dGVkIHRvIHRoZSBQU1ROLiBUaGUgbWFuYWdlbWVudCBhbmQNCgk+ZGVsZWdhdGlvbiBwcm9jZWR1cmVzIG9mIHRoZSB0cmVlIGFyZSB0aGUgc2FtZSBhcyBmb3IgZTE2NC5hcnBhLg0KCT5UaGUgc2Vjb25kIHRyZWUgd291bGQgY29udGFpbiBvbmx5IHdpbGRjYXJkIE5BUFRSIFJSIGZvciBudW1iZXIgcmFuZ2VzDQoJPg0KCT5UaGlzIHdvdWxkIGJlIHRoZSBvcHRpbWFsIHNvbHV0aW9uIHByb3Bvc2VkIHNvZmFyLiBUaGUgcHJvYmxlbSBpcyB0aGF0DQoJPmEgY29tbW9uIGFncmVlbWVudCBhbmQgYSBkZWZpbml0aW9uIG9uIHRoZSBzZWNvbmQgdHJlZSBpcyBuZWNlc3NhcnkuDQoJPg0KCT5DLiBVc2UgaW5kaXZpZHVhbCBzZWNvbmQgc2hhZG93IHRyZWVzLCBlZyBvbiBhIG5hdGlvbmFsIGxldmVsLCBlZyBpbg0KCT5BdXN0cmlhIGUxNjRzaGFkb3cuYXQgd291bGQgYmUgdXNlZC4gVGhlIHByb2JsZW0gaGVyZSBpcyBob3cgb25lIGNhbg0KCT5maW5kIG91dCB0aGUgZG9tYWluIG5hbWVzIG9mIHRoZSBpbmRpdmlkdWFsIHRyZWVzLg0KCT5PbmUgc29sdXRpb24gaXMgdG8gZG8gaXQgd2l0aCBhIHRhYmxlIGluIGVhY2ggc2VydmVyICh3aGljaCBpcyBub3QgZ29vZCkuDQoJPg0KCT5UaGUgb3RoZXIgc29sdXRpb24gaXMgdG8gcHV0IHBvaW50ZXJzIGluIGUxNjQuYXJwYSwgZWcgU1JWIFJSIG9yIGV2ZW4gTVggUlIuDQoJPlRoZSBNWCByZWNvcmQgd291bGQgZ2l2ZSBlZyB0aGUgcm9vdCBvZiB0aGUgb3RoZXIgdHJlZSwgYW5kIGVhY2ggdHJlZQ0KCT53b3VsZCBiZSBzdHJ1Y3R1cmVkIGluIHRoZSBzYW5lIHdheSBsaWtlIGUxNjQuYXJwYSwgc28gdGhlIHNhbWUgYWxnb3JpdGhtcw0KCT5jYW4gYmUgdXNlZC4NCgk+DQoJPlNpbmNlIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGRlbGVnYXRpb25zIGluIGUxNjQuYXJwYSB2YXJpZXMgKFRpZXIgMSBsZXZlbHMpLA0KCT50aGVyZSBpcyBubyBlYXN5IHdheSB0byBmaW5kIG91dCB0aGUgbGV2ZWwgb2YgdGhlIHBvaW50ZXJzLCBldmVuIGlmIHRoZXkgYXJlDQoJPm9ubHkgb24gdGhlIFRpZXIgMSBsYXllci4NCgk+DQoJPkl0IHdhcyBwcm9wb3NlZCB0byBzZWFyY2ggZWl0aGVyIHRvcCBkb3duIChmYXN0ZXIpIG9yIGJvdHRvbSB1cCAobW9yZQ0KCT5mbGV4aWJsZSksIGJlY2F1c2UgdGhpcyB3b3VsZCBhbGxvdyBzdWItcG9saWNpZXMgaW4gbnVtYmVyIHJhbmdlcy4NCgk+DQoJPkQuIEFyZSB0aGVyZSBhZGRpdGlvbmFsIHBvc3NpYmlsaXRpZXMgb3IgcHJvcG9zYWxzPw0KCT4NCgk+RmluYWxseSBJIGNvbWUgdG8gdGhlIGxhc3QgaXNzdWU6DQoJPg0KCT5Gb3IgY2FzZSAxYSBhbmQgMWIgYWJvdmUgKG5vIHN1Y2ggbnVtYmVyKSBhbiAiZW51bXNlcnZpY2UiIGlzIG5lY2Vzc2FyeQ0KCT50byBpbmRpY2F0ZSB0aGF0IHRoZXJlIGV4aXN0cyBubyBzdWNoIG51bWJlciwgbmVpdGhlciBpbiBFTlVNIG5vciBvbiB0aGUNCgk+UFNUTi4NCgk+DQoJPlByb3Bvc2FscyBzb2ZhciBhcmU6DQoJPg0KCT5Vc2UgYSBzcGVjaWFsIGZsYWcgZS5nLiAibiIgb3IgInYiDQoJPlVzZSBhICJlbnVtc2VydmljZSIgZS5nLiAiRTJVK05PTkUiIG9yICJFMlUrVk9JRCIgb3Igb25seSAiVk9JRCINCgk+DQoJPkFsc28gaGVyZSBhZGRpdGlvbmFsIHByb3Bvc2FscyBhcmUgaW52aXRlZC4NCgk+DQoJPkJlc3QgcmVnYXJkcw0KCT4NCgk+UmljaGFyZA0KCT4NCgk+DQoJPg0KCT4NCgk+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ZW51bSBtYWlsaW5nIGxpc3QNCgk+ZW51bUBpZXRmLm9yZw0KCT5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lbnVtDQoJPg0KCT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT5JcHRlbCBtYWlsaW5nIGxpc3QNCgk+SXB0ZWxAaWV0Zi5vcmcNCgk+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHRlbA0KCQ0KCQ0KDQo=_______________________________________________enum mailing [email-masked]://www1.ietf.org/mailman/listinfo/enum

---

From: "James McEachern" <[email-masked]>
Date: Tue, 30 Mar 2004 15:59:13 -0500

Mike,
In your email you state:

---snip---
The difference is in the interpretation of a lack of a record.  In LNP, it
would mean that the E.164 number is still owned by the original switch,
whereas in ENUM it would mean that the E.164 number is not route-able to an
IP endpoint.  From a TDM perspective, the entire IP domain could be viewed
as a single switch and the LNP routing scheme should work.  The converse
(when records exist) could be true for ENUM.
	
A gateway between IP-domain and TDM domain, upon seeing that both an LNP and
an ENUM dip have not resolved the route, can safely conclude that the number
is unassigned and release the call."
---end snip---

This seems to suggest that routing to an IP endpoint would require an ENUM
entry - otherwise the gateway could safely assume the number is unassigned.
Do you really mean this? What would this do to opt-in?

Thanks
Jim

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Monday, March 29, 2004 10:30 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: AW: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

Hi Michael,
 
We are trying to find a solution for the following scenarios:
A. An E.164 number range is only available and routable in ENUM
B. An E.164 number range is available via PSTN and via IP
C. An E.164 number range is not assigned at the PSTN
 
If in cases A and B an entry is existing in ENUM, no problem.
If the query returns NXDOMAIN, the problem arises for the 
querying server how to proceed.
 
In case A the server must not forward the call to the PSTN, because
a loop may be created. In cases B and C it may forward the call (no harm)
but it is not necessary. In case B the server could terminate the call on
IP,
in case C the server could say number not available and not bother the 
PSTN at all.
 
If we find a solution that covers A, B and C may be covered as well.
 
I agree that in future call routing may be improved further in access
to LNP servers on the PSTN is available and also if access to ENUM
is available on the PSTN (some carriers are already working on this),
but this will take some time.
 
We should also come up with a sself-containing solution on IP and
not always rely on the PSTN.
 
regards
Richard

	-----Ursprüngliche Nachricht----- 
	Von: Michael Hammer [mailto:[email-masked]] 
	Gesendet: Fr 26.03.2004 17:40 
	An: Stastny Richard 
	Cc: [email-masked]; [email-masked] 
	Betreff: Re: [Iptel] FW: [Enum] Summary on NoPSTN dicussion

	Richard,
	
	Going out on a limb here, since I have not seen all the referenced
	discussions.  My first impression is that the description below is
overlay
	complex.
	
	I have a concern that you appear to be proposing that the ENUM dip
would
	have definitive answers to:
	a) whether a number has been assigned and therefore rout-able,
	b) whether a number that is assigned was done, and if so whether to
a PSTN
	endpoint or an IP endpoint.
	
	Another concern is that, if you do get looped routing between the IP
domain
	and the TDM domain, this is likely an indication of a lack of
	synchronization between the ENUM database and the LNP database.  One
or the
	other has incorrect data.  I suspect that there may be time lags
from when
	an SP assigns a number and when it gets reflected in one or another
	databases.  If you want the ENUM and LNP databases to be somewhat
	independent, you might want a loose coupling of the use of the two
systems:
	
	  -If endpoint is TDM, then the ENUM database should point to the
PSTN,
	with default behavior being, if unknown to ENUM, send to PSTN to
	resolve.  (Note this is orthogonal to ENUMs use to select
alternative
	endpoints.)
	
	  - If endpoint is IP, then the LNP databases should point to the IP
	domain, with default behavior being, if unknown to LNP, route in the
PSTN
	to resolve.
	
	The difference is in the interpretation of a lack of a record.  In
LNP, it
	would mean that the E.164 number is still owned by the original
switch,
	whereas in ENUM it would mean that the E.164 number is not
route-able to an
	IP endpoint.  From a TDM perspective, the entire IP domain could be
viewed
	as a single switch and the LNP routing scheme should work.  The
converse
	(when records exist) could be true for ENUM.
	
	A gateway between IP-domain and TDM domain, upon seeing that both an
LNP
	and an ENUM dip have not resolved the route, can safely conclude
that the
	number is unassigned and release the call.
	
	Actually, it may not be necessary to send a setup message to a GW,
nor is
	it necessary to have the ENUM and LNP databases duplicate each
other.  It
	should be sufficient for an ENUM DB to query the LNP DB and respond
with an
	appropriate answer, or the converse.
	
	Mike

	At 04:22 PM 3/25/2004 +0100, Stastny Richard wrote:
	>Cross posting from [email-masked]
	>The discussion is going on the enum-list
	>
	>Richard Stastny
	>OeFEG
	>+43 664 420 4100
	>
	>
	>-----Original Message-----
	>From: Stastny Richard
	>Sent: Thursday, March 25, 2004 1:08 PM
	>To: Marian Durkovic; [email-masked]
	>Cc: [email-masked]
	>Subject: [Enum] Summary on NoPSTN dicussion
	>
	>Dear colleagues,
	>
	>There was a lot of discussions on-list and off-list on this issue,
	>so I will try to summarize at least my view of the problem.
	>I will also include my current view on the ;enumdi
	>and the ;pstn indicator for the tel: URI
	>
	>ENUM-enabled UAs and Servers are currently processing
	>received E.164 numbers (either in a tel:+xxx URI or in a sip: URI
	>in the format sip:[email-masked];user=phone) in the following way:
	>(for simplicity I am only dealing with voice calls)
	>Please holler if I got something wrong or you disagree
	>
	>1. Query ENUM (in e164.arpa)
	>
	>2. if a NAPTR is found with an "enumservice" sip or voice:sip,
	>handle the call as if you have received a sip: URI in the format
	>sip:[email-masked] in the first place.
	>
	>3. If a NAPTR is found with an "enumservice" voice:tel
	>3a. and the tel: URI is pointing to a different number,
	>query ENUM again for this number
	>3b. if the tel: URI is the same as the AUS, forward the
	>call to the PSTN, if you are able to do so.
	>
	>Note: here the proposed ;pstn indicator may come in handy:
	>In 3a you may use it in the NAPTR to prevent a second ENUM-query
	>and force the call to the PSTN.
	>In 3b the server may add ;pstn to inform the next proxy about
	>The decision to force the call to the PSTN. On the other hand,
	>In this case also the ;enumdi indicator may be used just to prevent
	>an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in
	>signalling.
	>
	>4. Now the real problem starts: If the ENUM-query returns NXDOMAIN,
	>the current assumption of all clients is: the call is routed to the
	>PSTN if the server is able to do so (eventually with the ;enumdi
set.
	>
	>This means, we refer the problem to the PSTN. This is not nice for
	>various reasons:
	>1. we are bothering the PSTN in some cases unnecessarily
	>2. the PSTN may not know what to do either and bounce the
	>call back, which is creating loops
	>3. and finally: what are we doing if there is no PSTN anymore ;-)
	>Ok, this seems far reached, but Internet Telephony should be
finally
	>self-containing.
	>
	>So what are the additional policies we may want to tell an ENUM-
	>client?
	>
	>1. No such number (unassigned number)
	>1a. The whole number range (number block)is unassigned
	>1b. There are numbers assigned in this number range, but if you
	>do not find one in ENUM, you also will not find one on the PSTN, so
	>it makes no sense to route it to the PSTN (ENUM-only)
	>2. Default routing for the whole number range (number block) to a
VoIP
	>gateway.
	>2a. The whole block is routed, there are no individual entries in
ENUM
	>(e.g. 1-800 numbers)
	>2b. There are numbers in ENUM, but if you do not find an entry,
route
	>the call to the default gateway given. One example for this case
may be
	>a VoIP provider operating an island only connected to the PSTN.
Some
	>of the users are also in ENUM (opt-in). If he provider now opens up
access
	>to the Internet via a gateway (border element, ...), he may want to
route
	>all calls for his users not in ENUM to the gateway provided by
default
	>
	>Case 1a and 2a can be dealt with in e164.arpa with wildcards,
because no
	>Additional entries below exist.
	>Case 1b and 2b cannot be dealt within e164.arpa, because wildcards
do
	>not support this.
	>
	>The solutions proposed for this sofar are.
	>
	>A. use tables in each server. This is not a good idea and does not
help
	>ENUM-enable UA. The information should be stored in a global
accessible
	>and public database (DNS).
	>
	>B. use a (one, common) second common tree (e164shadow.arpa, where
you put
	>in only the wildcards for the number ranges in question. The
processing
	>assumption now should be:
	>
	>If the ENUM-query returns NXDOMAIN, the call is not routed to the
PSTN
	>In any case, the server queries e164shadow.arpa, and only if no
entry
	>is found there, the call is routed to the PSTN. The management and
	>delegation procedures of the tree are the same as for e164.arpa.
	>The second tree would contain only wildcard NAPTR RR for number
ranges
	>
	>This would be the optimal solution proposed sofar. The problem is
that
	>a common agreement and a definition on the second tree is
necessary.
	>
	>C. Use individual second shadow trees, eg on a national level, eg
in
	>Austria e164shadow.at would be used. The problem here is how one
can
	>find out the domain names of the individual trees.
	>One solution is to do it with a table in each server (which is not
good).
	>
	>The other solution is to put pointers in e164.arpa, eg SRV RR or
even MX RR.
	>The MX record would give eg the root of the other tree, and each
tree
	>would be structured in the sane way like e164.arpa, so the same
algorithms
	>can be used.
	>
	>Since the structure of the delegations in e164.arpa varies (Tier 1
levels),
	>there is no easy way to find out the level of the pointers, even if
they are
	>only on the Tier 1 layer.
	>
	>It was proposed to search either top down (faster) or bottom up
(more
	>flexible), because this would allow sub-policies in number ranges.
	>
	>D. Are there additional possibilities or proposals?
	>
	>Finally I come to the last issue:
	>
	>For case 1a and 1b above (no such number) an "enumservice" is
necessary
	>to indicate that there exists no such number, neither in ENUM nor
on the
	>PSTN.
	>
	>Proposals sofar are:
	>
	>Use a special flag e.g. "n" or "v"
	>Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID"
	>
	>Also here additional proposals are invited.
	>
	>Best regards
	>
	>Richard
	>
	>
	>
	>
	>Iptel mailing list
	>[email-masked]
	>https://www.ietf.org/mailman/listinfo/iptel

z{x%^ᦞzrmᨶ?
0u'~ffX)n

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 30 Mar 2004 23:34:04 +0200

SmltIHdyb3RlOg0KPlRoaXMgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHJvdXRpbmcgdG8gYW4gSVAgZW5kcG9pbnQgd291bGQgcmVxdWlyZSBhbiBFTlVNIGVudHJ5IC0gb3RoZXJ3aXNlIHRoZSBnYXRld2F5IGNvdWxkIHNhZmVseSA+YXNzdW1lIHRoZSBudW1iZXIgaXMgdW5hc3NpZ25lZC4gRG8geW91IHJlYWxseSBtZWFuIHRoaXM/IFdoYXQgd291bGQgdGhpcyBkbyB0byBvcHQtaW4/DQogDQpGb3IgRU5VTS1vbmx5IG51bWJlcnMgeWVzLCBmb3Igb3B0LWluIG51bWJlcnMgbm90Lg0KIA0KU29tZSBudW1iZXIgcmFuZ2VzIGFyZSBvcHQtaW4gKHRoYXQgbWVhbnMgdGhleSBhbHNvIGV4aXN0IG9uIHRoZSBQU1ROKSwgc29tZSBudW1iZXIgcmFuZ2VzIGFyZSANCkVOVU0tb25seSAodGhhdCBtZWFucyB0aGV5IGRvIG5vdCBleGlzdCBvbiB0aGUgUFNUTikuDQogDQpXaGF0IEkgYW0gc2F5aW5nIGlzIHRoYXQgdGhlcmUgbmVlZCB0byBleGlzdCBzb21lIG1lYW5zIG9uIElQIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIHR3bw0Kb3B0aW9ucy4NCiANCnJlZ2FyZHMNClJpY2hhcmQNCg0KCSAgICAgIA0KDQo=_______________________________________________enum mailing [email-masked]://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Hammer <[email-masked]>
Date: Tue, 30 Mar 2004 17:47:21 -0500

James,

I guess I have to curb my desire to get the call onto the IP network as 
soon as possible rather than as late as possible.

In today's environment, I think we have pockets of IP networks 
interconnected by the global PSTN.  One of the characteristics of the PSTN 
is that I can dial a number from anywhere in the world and it will get 
routed to the destination where that number resides.  When going from PSTN 
to IP, it might be expected that the PSTN-IP GW has all the telephone 
number to SIP/IP address mappings associated with that IP pocket 
provisioned into it.

Now reverse the situation.  We have pockets of TDM interconnected to the 
"Network".  A user in that TDM pocket dials a number it goes to a nearby 
gateway and then routed to anywhere in the Network.  I don't expect that 
gateway to have a mapping from all of the telephone numbers in the world to 
a SIP or IP address in the IP domain.  So, given only a telephone number, 
how do I get routing information for the IP domain?  I assumed the ENUM 
database would get them started on doing that translation, or at least 
going in the right direction.

I don't see that this changes opt-in.  What it probably does mean is that, 
lacking any ENUM entry, the call must be routed mostly through the PSTN to 
the (one?) GW that has a mapping to the called party in the last IP 
domain.  That is likely to delay crossing into the IP domain, be a more 
expensive call, and one which perpetuates the TDM backbone.

I was also conjecturing what it means to "own" a telephone number.  In the 
PSTN, the number is owned by the SP and assigned to an end-user.  The LNP 
rulings stretch that a bit by allowing a number to be carried to another 
SP, but technically it is still owned by the original carrier.  If it is 
ever given up, it reverts back to that carrier.  How is this going to work 
in IP?  Are E.164 number blocks going to be assigned to an ITSP?  Does a 
TDM carrier that becomes an ITSP get to move them over without 
restriction?  Could an ITSP own a block of numbers, yet have no GW to the 
PSTN?  Are there going to be restrictions on how the network evolves?

I would hope that even if an individual number was unlisted, if a block of 
numbers belonged to an ITSP, there would be a higher-level node entry in 
the ENUM tree, and the call could be routed to an IP-GW, which might have 
additional information to route the call, or at least determine that the 
number is unassigned.

I confess I have not been watching the ENUM list, but perhaps should 
join.  My apologies if this has all been figured out.

Mike

At 03:59 PM 3/30/2004 -0500, James McEachern wrote:

>whereas in ENUM it would mean that the E.164 number is not route-able to 
>an IP endpoint.  From a TDM perspective, the entire IP domain could be 
>viewed as a single switch and the LNP routing scheme should work.  The 
>converse (when records exist) could be true for ENUM.
>
>
>A gateway between IP-domain and TDM domain, upon seeing that both an LNP 
>and an ENUM dip have not resolved the route, can safely conclude that the 
>number is unassigned and release the call."
>
>---end snip---
>
>entry - otherwise the gateway could safely assume the number is 
>unassigned. Do you really mean this? What would this do to opt-in?
>
>Thanks
>Jim
>
>[<mailto:[email-masked]>mailto:[email-masked]]
>but it is not necessary. In case B the server could terminate the call on IP,
>         -----UrsprÃ¼ngliche Nachricht-----
>         Von: Michael Hammer 
> [<mailto:[email-masked]>mailto:[email-masked]]
>         discussions.  My first impression is that the description below 
> is overlay
>         complex.
>
>         I have a concern that you appear to be proposing that the ENUM 
> dip would
>         b) whether a number that is assigned was done, and if so whether 
> to a PSTN
>         Another concern is that, if you do get looped routing between the 
> IP domain
>         synchronization between the ENUM database and the LNP 
> database.  One or the
>         independent, you might want a loose coupling of the use of the 
> two systems:
>
>         domain, with default behavior being, if unknown to LNP, route in 
> the PSTN
>         to resolve.
>
>         A gateway between IP-domain and TDM domain, upon seeing that both 
> an LNP
>         Actually, it may not be necessary to send a setup message to a 
> GW, nor is
>         should be sufficient for an ENUM DB to query the LNP DB and 
> respond with an
>         >2. Default routing for the whole number range (number block) to 
> a VoIP
>         >gateway.
>         >2a. The whole block is routed, there are no individual entries 
> in ENUM
>         >(e.g. 1-800 numbers)
>         >of the users are also in ENUM (opt-in). If he provider now opens 
> up access
>         >to the Internet via a gateway (border element, ...), he may want 
> to route
>         >Case 1b and 2b cannot be dealt within e164.arpa, because 
> wildcards do
>         >not support this.
>         >
>         >A. use tables in each server. This is not a good idea and does 
> not help
>         >B. use a (one, common) second common tree (e164shadow.arpa, 
> where you put
>         >If the ENUM-query returns NXDOMAIN, the call is not routed to 
> the PSTN
>         >This would be the optimal solution proposed sofar. The problem 
> is that
>         >C. Use individual second shadow trees, eg on a national level, 
> eg in
>         >One solution is to do it with a table in each server (which is 
> not good).
>         >
>         >Since the structure of the delegations in e164.arpa varies (Tier 
> 1 levels),
>         >there is no easy way to find out the level of the pointers, even 
> if they are
>         >to indicate that there exists no such number, neither in ENUM 
> nor on the
>         >PSTN.
>         >
>         >Proposals sofar are:
>         >
 > ><https://www1.ietf.org/mailman/listinfo/enum>https://www1.ietf.org/mailman/listinfo/enum 
>
>         >
 > ><https://www.ietf.org/mailman/listinfo/iptel>https://www.ietf.org/mailman/listinfo/iptel 
>
>
>
>
>z{x%^á¦žzrmá¨¶?
>0u'~ffX)n

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 31 Mar 2004 05:17:29 +0200

Hi Mike,

>number to SIP/IP address mappings associated with that IP pocket
 
Not with a generic gateway using ENUM: any gateway may route any call
to any number in ENUM. This is by definition all numbers living in ENUM-only.

>going in the right direction.
 
Correct

>expensive call, and one which perpetuates the TDM backbone.
 
Again: For opt-in ENUM entries yes, for ENUM-only entries no, because
it does not make sense to route them to the PSTN, becasue there is no
one specific gateway having the mapping, all GWs are equal, so the call
can be routed on the PSTN only again to a generic gateway, and this GW
will find out again that there is no entry in ENUM.

>ever given up, it reverts back to that carrier. 
 
Only for geographic numbers, and that has mostly technical reasons
(onward routing)
 
First, no number is owner by anybody, it is assigned by ITU-T to the NRA,
and assigned in turn to the SP, and the SP assignes it to the end-user (for
geographic numbers. Service numbers are already assigned one-by-one
to the end-user by the NRA, no blocks, no anchor SP. 
 
>How is this going to work
 
With ENUM-only numbers there is no need to assign blocks of numbers.
An ENUM-only number is the equivalent of a domain name. It is assigned
to the end-user directly, who chooses the SP, like with a service number.
You also do not assign domain names in blocks.

If you look at the mostly used ENUM structure, there is only a Tier 0 (delegations
of CC, then there is a tier 1 (delegation of single numbers to end users) and
a tier 2, holding the data (NAPTR). No need for an additional block structure
(except in France, but they are different anyway)

>join.  My apologies if this has all been figured out.
 
good idea
 
Richard

Mike

---

From: Michael Hammer <[email-masked]>
Date: Wed, 31 Mar 2004 14:01:35 -0500

>to any number in ENUM. This is by definition all numbers living in ENUM-only.

This was my pre-ENUM view, probably now dated.

>will find out again that there is no entry in ENUM.

Understood.  If it ENUM-only, then it should never go to a GW.

>to the end-user by the NRA, no blocks, no anchor SP.

How does this work for numbers that were assigned to an SP, that used to be 
TDM-only, but then (over time) converts to an IP-only network?  The SPs are 
very guarded about the E.164 numbers assigned to them.  That is what I 
meant by "owned."  You are suggesting that when a person with a phone 
number assigned by an SP moves to an IP-based "phone" that the SP will 
relinquish that phone number back to the NRA?  Or are you saying that 
number portability doesn't work between TDM and IP worlds?

>You also do not assign domain names in blocks.

I think there is an issue here.  If the SPs hold most of the current NPA 
blocks, and there is a migration of many users from TDM to IP, then do you 
lengthen the number to 11 digits to get more, or do the SPs have to 
relinquish numbers?

>(except in France, but they are different anyway)

I now understand the plan for ENUM, just need to understand how currently 
assigned E.164 numbers move from current SPs to ENUM users.

Mike