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

From: "Fullbrook Kim \(UK\)" <[email-masked]>
Date: Wed, 14 Sep 2005 17:10:38 +0100

Richard Stastny wrote:
<snip>

>> 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.

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

-----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,
 
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

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

---

From: lconroy <[email-masked]>
Date: Wed, 14 Sep 2005 17:36:30 +0100

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:
> 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
>
>