Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

"Stastny Richard" <Richard.Stastny@oefeg.at> Wed, 24 May 2006 16:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FivyA-0006DK-T8; Wed, 24 May 2006 12:12:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fivy8-0006D4-Ud for speermint@ietf.org; Wed, 24 May 2006 12:12:21 -0400
Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fivy7-00076e-Ed for speermint@ietf.org; Wed, 24 May 2006 12:12:20 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF
Date: Wed, 24 May 2006 18:16:20 +0200
Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4A65@oefeg-s04.oefeg.loc>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF
Thread-Index: AcZ55c9pook8AV07QCuSGZUVJZHNwAAALQwwAAMtGwAAALabEAAtwXjAAPK/xLAAAMWBMAAFEnSQAADsacAAAXIwMAAAWSswAAMILuAAATumxgAG4BNwABEZoVAADQ2DIAAC1z/9
From: Stastny Richard <Richard.Stastny@oefeg.at>
To: timothy.dwight@verizon.com, "Michael Hammer (mhammer)" <mhammer@cisco.com>, Brian Rosen <br@brianrosen.net>, "Francois D. Menard" <fmenard@xittelecom.com>, "Khan, Sohel Q [CTO]" <Sohel.Q.Khan@sprint.com>, David Meyer <dmm@1-4-5.net>, speermint@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc:
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
Errors-To: speermint-bounces@ietf.org

Tim,
 
>> ... the basic idea of Infrastructure ENUM (which will be used for service
>> providers is to provide a domain name in a SIP URI = a service provider ID
>(SPID)

>At the risk of asking an off-topic question (realizing that ENUM is not
>within scope for SPEERMINT), can I ask where the idea that Infrastructure
>ENUM queries return SPIDs, comes from?  It is my intent to provide a point
>of interconnection to be used by the requesting entity to hand to me a call
>to the specified number.  I do not intend that the only meaningful part of
>the URI returned from the ENUM query, be the domain name.
 
thank you for raising this important point. I tried to raise this some time
ago, but got no clear answer

Currently there exist two lines of thought about the usage of Infrastructure
(and also Carrier ENUM in private trees)
 
1. Put in ENUM the ingress point(s) e.g. sip:+43xxxx@sbc4711.provider.net
2. Put in ENUM the AoR only: e.g. sip:+43xxx@provider.net
(provider.net is what I meant with SPID)
 
Most currently prefer option 1, especially in private ENUM trees.
 
IMHO this is the wrong approach:
 
There should be a clear separation (and it is in the charter) between ENUM and SPEERMINT
SPEERMINT peering MUST be able to work standalone and without ENUM.

Option 1 assumes also that the user is entering ALWAYS an E.164 number as
identifier.
 
But what if he is entering an AoR?
 
SPEEMINT peering MUST be able to resolve this too
so you need to find the ingress point independant of ENUM
e.g. via RFC3263.
 
If this MUST be possible, why not enter in (any) ENUM just the AoR,
if you must be able to resolve the AoR anyway?

Otherwise you need to manage two mappings separate
1. the E.164 to ingress point
2. the AoR mapping to ingress point

this is not a good idea

This is the reason why I would prefer to enter in ENUM AoRs only
the user part in ENUM is always the E.164 number (for privacy reasons)
the domain part is the SPID, which is mapped later to find the 
ingress point

the calling user may then also use an alis AoR such as sip:name@provider.net

regards

Richard



________________________________

Von: Tim Dwight [mailto:timothy.dwight@verizon.com]
Gesendet: Mi 24.05.2006 16:46
An: Stastny Richard; 'Michael Hammer (mhammer)'; 'Brian Rosen'; 'Francois D. Menard'; 'Khan, Sohel Q [CTO]'; 'David Meyer'; speermint@ietf.org
Betreff: RE: [Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF



Stastny, Richard said:

> ... the basic idea of Infrastructure ENUM (which will be used for service
> providers is to provide a domain name in a SIP URI = a service provider ID
(SPID)

At the risk of asking an off-topic question (realizing that ENUM is not
within scope for SPEERMINT), can I ask where the idea that Infrastructure
ENUM queries return SPIDs, comes from?  It is my intent to provide a point
of interconnection to be used by the requesting entity to hand to me a call
to the specified number.  I do not intend that the only meaningful part of
the URI returned from the ENUM query, be the domain name.

tim




_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint