Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)

From: "Stastny Richard" <[email-masked]>
Date: Tue, 13 Sep 2005 16:01:27 +0200

Hi all,
 
since we still do not have a new ENUM charter and time is running out,
(ADs missing in non-action)
I want to throw in some stones in the pond to stir up the
Carrier ENUM requirements discussion:

ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To be able to use an applet you need to be able to use the applications the applet is running on.

You cannot use e.g. an applet integrating your Skype buddies in MS Outlook without having Skype and MS Outlook installed and running on your laptop.

Same with ENUM:

ENUM is useless without the possibility to enter an E.164 number in DNS and the capability to use the resulting URI, e.g. in case of real-time communications a SIP URI. 
 
For further background and rationale see:
http://voipandenum.blogspot.com/2005/09/carrier-enum-is-applet-of-ip.html
 
Executive summary:
 
The basic requirement for Carrier ENUM to work is a global IP Interconnect (VoIP peering) solution for "Carriers".

To summarize:

1. The minimum requirements and rules for IP Interconnect based on routing via SIP URIs have to be established globally. Note: if the minimum requirements are fullfilled (e.g. TLS), the calling server must be able to resolve the SIP AoR to the IP-address of the called server and also to be able to contact the called server. The called user MAY have additional agreements in his profile, e.g. to reject all anonymous calls.

2. Only if this is in place, Carrier ENUM makes sense on a global scale. This does not imply that Carrier ENUM may not be trialed and used commercially earlier, but only in a limited way.

3. Carrier ENUM must be available on a global scale. This implies that Carrier MUST be available for any carrier who wants to use it. This implies that although it is a national matter how to implement Carrier ENUM in detail and to define e.g. the entity operating the Tier 1, there should be no opt-out possible (this is IMHO the most problematic point).

4. It is a national matter to define who is entitled to enter which numbers and the corresponding NAPTRs in "Carrier" ENUM,

e.g. an entity is only allowed to enter numbers in Carrier ENUM if it is hosting the final destination of the E.164 number on behalf of the end-user (that means no signalling transit is allowed)

or if it is providing a direct gateway/SBC to the own destination network hosting the E.164 number on a private IP-based network (NGN) or on the PSTN. National number portability issues have also be taken into account here.

If an entity is assigned an E.164 number directly (e.g. an 800 number or a corporate number), and if the entity is running the SIP server on its own, it may also be allowed to enter this number and the NAPTRs in Carrier ENUM.

4. There is no user opt-in or opt-out possible in Carrier ENUM. The entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that the data in Carrier ENUM is public, therefor end-user privacy MUST be assured. This implies that either the E.164 number or a random number (userid) is used in the user-part of the SIP URI. The mapping from this number to the end-user identity used further (even if it is a public identity) MUST be done within the end-systems.

5. All SIP URIs entered in Carrier ENUM must be reachable via the minimum requirements of IP Interconnect as defined in 1. 
 
Richard

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

---

From: "Schiefner, Carsten" <[email-masked]>
Date: Wed, 14 Sep 2005 10:43:03 +0200

Hi Richard,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stastny Richard
> Sent: Tuesday, September 13, 2005 2:52 PM
> To: [email-masked]
> Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)
> 
> [...]
>  
> ENUM (Carrier and User ENUM) is an applet to IP 
> -Interconnect. [...]

as this was raised during the VOIPEER BOF in Paris already: we should come up with another term to replace "Interconnect[ion]" - this one could easily trigger (too much) interest from the regulatory front. I personally don't like "VoIP Peering" too much either because it is partly misleading and confusing with IP Peering, but for the time being it seems to me to be the better pick.

Best,

	Carsten
-- 

Carsten Schiefner                  |                 p: +49 441 234-4571
Deutsche Telekom                   |                f: +49 431 7163-3972
T-Com Zentrale TK44                |                 m: +49 151 14525458
Ammerländer Heerstr. 138           |  mailto:[email-masked]
D-26129 Oldenburg                  |    http://www.t-com.de/kundendienst

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 11:51:08 +0200

>IP endpoint discovery
 
Nice try, but this would be moe a replacement for Carrier ENUM ;-)
 
IP (Realtime Communications) Interconnect goes beyond this
it also includes (IMHO) the minimum requirements for right of access
of the IP endpoint.
 
Richard

________________________________

Von: Alexander Mayrhofer [mailto:[email-masked]]
Gesendet: Mi 14.09.2005 11:44
An: Stastny Richard
Cc: Schiefner, Carsten; [email-masked]
Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)

Stastny Richard wrote:
> I basically agree with you that both terms are inappropriate,
> but I have no better idea either.
> 
> IP Interconnect is very misleading, because it includes
> also L3.
> What we are talking here is application (signalling)
> level interconnect (and not peering)
> 
> Any better ideas out there?

What about "IP endpoint discovery"?

axelm

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 17:05:30 +0200

>IMO carrier ENUM does not define any kind of interconnect. It is a
>routing information on L7.

Correct

It does not define it, but it needs some kind of interconnect defined,
because otherwise it does not work

As I said, an applet needs an application to run on

Richard

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Mi 14.09.2005 16:41
An: Stastny Richard
Cc: Schiefner, Carsten; [email-masked]
Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)

> Any better ideas out there?

IMO carrier ENUM does not define any kind of interconnect. It is a
routing information on L7.

klaus

> Von: [email-masked] im Auftrag von Schiefner, Carsten
> Gesendet: Mi 14.09.2005 10:43
> An: [email-masked]
> Betreff: RE: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)
>
>
>
> Hi Richard,
>
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 19:58:31 +0200

Kim wrote:

>> 1. The minimum requirements and rules for IP Interconnect
>> based on routing via SIP URIs have to be established globally.
>> Note: if the minimum requirements are fullfilled (e.g. TLS),
>> the calling server must be able to resolve the SIP AoR to the
>> IP-address of the called server and also to be able to contact
>> the called server. The called user MAY have additional
>> agreements in his profile, e.g. to reject all anonymous calls.

>This is not an appropriate reflection of the minimum requirements. The statement above assumes every SIP caller will make a >direct connection to the destination network which is a false assumption. It's not realistic to expect every SIP network in the >world to interconnect directly with every other.

Note: this requirement has nothing to do with ENUM. A originating user is submitting a public user identity and this public user identity need to be resolved.

The basic problem in your reply is that you talk about a SIP "network". I am talking here only about signalling (L5). 
A public user identity is an AoR (SIP URI) and must resolve into an IP address. If a user wnats to contact sip:[email-masked],
o2.net is looked up and should bring you back some SRV records. If this srv records are pointing to gw17.grx.net and
there is a SBC accepting the call and delivering via some internal magic finally to O2, fine. But you cannot provide
a customer with a PUBLIC user identity like sip:[email-masked];context=3GPPnetworksonly

>If a customer of Network A calls a customer of Network B, it might well be the case that there is no direct Interconnection >agreement between A and B, but both A and B have interworking agreements with Carrier K. So in this example the call is >routed from A to K to B.

Again, what is a Network with big N on the Internet? As you say, it is not possible to have "Interconnect" (peering?) 
agreements between all Carriers. So you assume that there will be signalling transit providers as proposed
in UK ;-) e.g. of course C&W and BT. And then you also may have Forward Routing for ported numbers.
The PSTN operators (including the mobile operators) simply want to build their stovepipe architecture on top of the 
the Internet. This does not prevent the real traffic on L3 to be transited via K.

>ENUM as described in RFC 3761 for SIP calls does NOT describe routing. It provides the URI for the Destination.

Yes: so will Carrier ENUM

>The gap is that we need a way of specifying call routing in "Carrier DNS". Being careful about terminology this is not >something that ENUM would do.

No, you missed IETF Paris, but you should at least read the minutes. Call routing is done via SIP URIs and
this problem will be (hopefully) handled by voipeer, not in ENUM WG

If this is not provided, Carrier ENUM does not work. That why I did this post and said Carreir ENUM is an applet
to the underlying peering.

Richard

Regards,
Kim Fullbrook
O2 UK

-----Original Message-----

=====================================================
This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.
=====================================================

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stastny Richard
Sent: 13 September 2005 15:01
To: Richard Shockey; [email-masked]
Cc: [email-masked]; "Patrik Fältström"
Subject: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)

Hi all,

Same with ENUM:

Executive summary:

To summarize:

Richard

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 14 Sep 2005 20:09:34 +0200

Lawrence,
 
in principle yes, a minor point:
 
>I took this to mean that an Carrier ENUM-aware calling UAS should be 
>able to resolve the destination SIP proxy's IP address. Whether or 
>not that destination SIP proxy responded is another matter.

This is correct what was said in Paris.

I am only the opinion that this could be the case

eventually in User ENUM (and laos here it is not a 
good idea) but is would defineitely not work
very well in Carrier ENUM, because then this would
be more like a lottery.

If a carreir is queriying ENUM he would expect that
normally the call is at least accepted by the server.

If you are a carrier and get in 50% a rejection, 
such as "I do not like you at all.
1. what are you doing instead
2. why should you ask in the first place such a bad system

This does of course not imply that the call may not be rejected
because eg the user has set up a profile lto autoreject calls
e.g. from insensate.co.uk ;-)

So I proposed that the requiremnets I-D of voipeer (not enum)
should state what the minimum requirements are to be accepted
without a  L7 peering agreement (e.g. a domain certificate, or whatever.)

-richard

Von: lconroy [mailto:[email-masked]]
Gesendet: Mi 14.09.2005 18:36
An: Fullbrook Kim (UK); Stastny Richard
Cc: [email-masked]' ENUM
Betreff: Re: [Enum] Carrier ENUM an applet of Voipeer (IP Interconnect)

Hi Richard, Kim, folks,

I understood Richard's R4 to suggest that who gets to populate a 
number is a national matter, and that, FOR EXAMPLE, this policy might 
be to permit only the entity hosting the final destination number to 
populate the equivalent ENUM zone. Your Mileage May Vary.

Re. R1 - IIUC, at the VoIPPEER and ENUM meetings in Gay Paree,there 
was a general agreement that Carrier ENUM meant, in the IETF context, 
that the entries in such a system were URIs that were able to be 
queried and any resulting URI could be resolved via the Internet. 
Whether or not the SBC/SIP Proxy responsible for the domainpart in a 
SIP URI actually responded to an incoming request was another matter.

I took this to mean that an Carrier ENUM-aware calling UAS should be 
able to resolve the destination SIP proxy's IP address. Whether or 
not that destination SIP proxy responded is another matter.

If a Carrier chooses to use some private DNS system to map from a 
destination domainpart to a different intermediate system (using, for 
example, private SRV records or other schemes) is it's own business - 
this has nothing to do with the globally accessible Carrier ENUM as 
envisaged in the IETF.

I must be missing something, so clarification required, please.

all the best,
   Lawrence

On 14 Sep 2005, at 17:10, Fullbrook Kim (UK) wrote:
> Richard Stastny wrote:
> <snip>
> This is not an appropriate reflection of the minimum requirements. 
> The statement above assumes every SIP caller will make a direct 
> connection to the destination network which is a false assumption. 
> It's not realistic to expect every SIP network in the world to 
> interconnect directly with every other.
>
> If a customer of Network A calls a customer of Network B, it might 
> well be the case that there is no direct Interconnection agreement 
> between A and B, but both A and B have interworking agreements with 
> Carrier K. So in this example the call is routed from A to K to B.
>
> ENUM as described in RFC 3761 for SIP calls does NOT describe 
> routing. It provides the URI for the Destination.
>
> The gap is that we need a way of specifying call routing in 
> "Carrier DNS". Being careful about terminology this is not 
> something that ENUM would do.
>
> Regards,
> Kim Fullbrook
> O2 UK
>
> This electronic message contains information from O2 which may be 
> privileged or confidential. The information is intended to be for 
> the use of the individual(s) or entity named above. If you are not 
> the intended recipient be aware that any disclosure, copying 
> distribution or use of the contents of this information is 
> prohibited. If you have received this electronic message in error, 
> please notify us by telephone or email (to the numbers or address 
> above) immediately.
> ENUM (Carrier and User ENUM) is an applet to IP -Interconnect. To 
> be able to use an applet you need to be able to use the 
> applications the applet is running on.
>
> You cannot use e.g. an applet integrating your Skype buddies in MS 
> Outlook without having Skype and MS Outlook installed and running 
> on your laptop.
>
> Same with ENUM:
>
> ENUM is useless without the possibility to enter an E.164 number in 
> DNS and the capability to use the resulting URI, e.g. in case of 
> real-time communications a SIP URI.
>
> The basic requirement for Carrier ENUM to work is a global IP 
> Interconnect (VoIP peering) solution for "Carriers".
>
> To summarize:
>
> 1. The minimum requirements and rules for IP Interconnect based on 
> routing via SIP URIs have to be established globally. Note: if the 
> minimum requirements are fullfilled (e.g. TLS), the calling server 
> must be able to resolve the SIP AoR to the IP-address of the called 
> server and also to be able to contact the called server. The called 
> user MAY have additional agreements in his profile, e.g. to reject 
> all anonymous calls.
>
> 2. Only if this is in place, Carrier ENUM makes sense on a global 
> scale. This does not imply that Carrier ENUM may not be trialed and 
> used commercially earlier, but only in a limited way.
>
> 3. Carrier ENUM must be available on a global scale. This implies 
> that Carrier MUST be available for any carrier who wants to use it. 
> This implies that although it is a national matter how to implement 
> Carrier ENUM in detail and to define e.g. the entity operating the 
> Tier 1, there should be no opt-out possible (this is IMHO the most 
> problematic point).
>
> 4. It is a national matter to define who is entitled to enter which 
> numbers and the corresponding NAPTRs in "Carrier" ENUM,
>
> e.g. an entity is only allowed to enter numbers in Carrier ENUM if 
> it is hosting the final destination of the E.164 number on behalf 
> of the end-user (that means no signalling transit is allowed)
>
> or if it is providing a direct gateway/SBC to the own destination 
> network hosting the E.164 number on a private IP-based network 
> (NGN) or on the PSTN. National number portability issues have also 
> be taken into account here.
>
> If an entity is assigned an E.164 number directly (e.g. an 800 
> number or a corporate number), and if the entity is running the SIP 
> server on its own, it may also be allowed to enter this number and 
> the NAPTRs in Carrier ENUM.
>
> 4. There is no user opt-in or opt-out possible in Carrier ENUM. The 
> entities allowed to enter NAPTRs in Carrier ENUM MUST be aware that 
> the data in Carrier ENUM is public, therefor end-user privacy MUST 
> be assured. This implies that either the E.164 number or a random 
> number (userid) is used in the user-part of the SIP URI. The 
> mapping from this number to the end-user identity used further 
> (even if it is a public identity) MUST be done within the end-systems.
>
> 5. All SIP URIs entered in Carrier ENUM must be reachable via the 
> minimum requirements of IP Interconnect as defined in 1.
>
> Richard
>
>