Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 10:35:55 -0600

Richard Shockey said:

> And as for TRIP ..been there heard that argument before ..no one is  
> going to
> deploy a BGP like function for this. Not going to happen no more  
> stacks in
> the proxy's we need to deal with the protocols we have not try and  
> invent
> new ones.

I'm starting another thread from this comment, because it raises a  
really good question.

TRIP was designed to exchange phone-number reachability information  
between SIP nodes. Nobody uses it. Why?

Is the problem with TRIP is that it's yet another protocol (as Richard  
suggests above), or is the problem that it doesn't convey the right  
information, just doesn't work, or something else?

What if the route-exchange function were done in SIP, perhaps  
something like an event package for routing?

Here's a possible model using an event package for routing. One might  
subscribe to the "routing" event package at a node, resulting in being  
NOTIFY-ed with a list of route vectors being advertised by that node.

This allows some interesting things:

1) Since SUBSCRIBE provides the information to specify "who is  
asking", the NOTIFY responses could contain route-tables customized  
for the recipient. This provides the location context sensitivity  
missing from ENUM queries.

2) Route-table entries could be vectors, something like "I, proxy B,  
have a route to proxy A, which offered me a route to example.com",  
allowing for selective route-redistribution.

3) Having gotten a preliminary routing table from subscribing to a  
peer, one could then query the peer's peers by subscribing directly to  
their routing updates. This establishes SIP reachability to those  
nodes (if the SUBSCRIBE works, you can reach them with SIP, and if  
their NOTIFY requests work, they can reach you). Further, it allows  
the peer's peer to make a determination of which routes they might  
want to offer you directly, as opposed to transitively via the first  
peer.

4) Filters in the  SUBSCRIBE could be used to indicate an interest in  
a subset of routes.

5) The routing vector syntax could easily allow for both phone numbers  
and domain-names.

--
Dean

---

From: <[email-masked]>
Date: Thu, 4 Mar 2010 17:59:40 +0100

Dear all,

I'm wondering whether it is true to say that TRIP does not provide an answer to the inter-ITAD reachability issue. Whitout going into technical details, why do we have continuous requests for TRIP ITAD identifiers?

See http://www.iana.org/assignments/trip-parameters/trip-parameters.xhtml or the IANA reports.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dean Willis
Envoyé : jeudi 4 mars 2010 17:36
À : [email-masked]
Objet : [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

--
Dean

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Daryl Malas <[email-masked]>
Date: Thu, 4 Mar 2010 10:05:39 -0700

Dean,

It has been a long time, since I read the RFC.  If I recall correctly, the biggest problem with TRIP was the issue of Number Portability.  Unlike BGP where there is a common rule of summarizing IP address blocks into class A's or B's, you cannot do the same with E.164 addresses.  Before number portability, TRIP would work good, because you can say I have NPA-NX1 through NPA-NX3.  If you want to reach them go here.  Now, there are rarely any contiguous blocks for any service provider.  If SSPs used TRIP, they would have to put in every single E.164 address (e.g. NPA-NXX-XXXX) into a route table.  This would make route tables contain millions of lines, which would slow down routing considerably...not to mention the maintenance nightmare...not to mention the route convergence would be ugly.  Perhaps there could be a 3rd party application that searches for contiguous ranges, but this too would be maintenance heavy as TNs are ported from one SSP to another; and, there is no guarantee it would significantly improve the routing database issue.

Perhaps I am just way off on this, but this is my recollection.

Regards,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Thursday, March 04, 2010 9:36 AM
To: [email-masked]
Subject: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

Richard Shockey said:

> going to deploy a BGP like function for this. Not going to happen no 
> more stacks in the proxy's we need to deal with the protocols we have 
> not try and invent new ones.

I'm starting another thread from this comment, because it raises a really good question.

TRIP was designed to exchange phone-number reachability information between SIP nodes. Nobody uses it. Why?

Is the problem with TRIP is that it's yet another protocol (as Richard suggests above), or is the problem that it doesn't convey the right information, just doesn't work, or something else?

What if the route-exchange function were done in SIP, perhaps something like an event package for routing?

Here's a possible model using an event package for routing. One might subscribe to the "routing" event package at a node, resulting in being NOTIFY-ed with a list of route vectors being advertised by that node.

1) Since SUBSCRIBE provides the information to specify "who is asking", the NOTIFY responses could contain route-tables customized for the recipient. This provides the location context sensitivity missing from ENUM queries.

2) Route-table entries could be vectors, something like "I, proxy B, have a route to proxy A, which offered me a route to example.com", allowing for selective route-redistribution.

3) Having gotten a preliminary routing table from subscribing to a peer, one could then query the peer's peers by subscribing directly to their routing updates. This establishes SIP reachability to those nodes (if the SUBSCRIBE works, you can reach them with SIP, and if their NOTIFY requests work, they can reach you). Further, it allows the peer's peer to make a determination of which routes they might want to offer you directly, as opposed to transitively via the first peer.

4) Filters in the  SUBSCRIBE could be used to indicate an interest in a subset of routes.

5) The routing vector syntax could easily allow for both phone numbers and domain-names.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Mar 2010 11:20:57 -0600

On Mar 4, 2010, at 11:05 AM, Daryl Malas wrote:

> Dean,
>
> It has been a long time, since I read the RFC.  If I recall  
> correctly, the biggest problem with TRIP was the issue of Number  
> Portability.  Unlike BGP where there is a common rule of summarizing  
> IP address blocks into class A's or B's, you cannot do the same with  
> E.164 addresses.  Before number portability, TRIP would work good,  
> because you can say I have NPA-NX1 through NPA-NX3.  If you want to  
> reach them go here.  Now, there are rarely any contiguous blocks for  
> any service provider.  If SSPs used TRIP, they would have to put in  
> every single E.164 address (e.g. NPA-NXX-XXXX) into a route table.   
> This would make route tables contain millions of lines, which would  
> slow down routing considerably...not to mention the maintenance  
> nightmare...not to mention the route convergence would be ugly.   
> Perhaps there could be a 3rd party application that searches for  
> contiguous ranges, but this too would be maintenance heavy as TNs  
> are ported from one SSP to another; and, there is no guarantee it  
> would significantly improve the routing database issue.
>

Ok, that's good input. Really good.

I attempt a rephrase:

Due to the sparse characteristic of number ranges resulting from LNP,  
route aggregation just doesn't work for phone numbers. TRIP is based  
on effective route aggregation; without it, the route-sets grow  
excessively large. Therefore, an ENUM style model of mapping phone- 
number to provider (effectively global, relatively static associations  
that are cacheable) works much better.

We expect to do at least one ENUM dip per phone-number in order to  
find out who the provider for that phone number is. I argue that doing  
further ENUM dips to find the routes to that provider are a Bad Idea,  
as this sort of information is arguably not well-suited to a DNS style  
database. Yes, one can hack together lots of heavily customized- 
locally-provisioned ENUM servers, but it's still a major operational  
suckage event.

Given this, there would appear to be no reasonable requirement for  
dynamic routing (BGP/OSPF/TRIP) based on telephone numbers. However,  
given the inter-provider peering model, there remains a requirement  
for dynamic routing based on peer identifiers (which I presume to be  
domain names).

So what we need is something that expresses the dynamic and shifting  
associations of inter-provider peerings and their associated weights  
and costs, and provides for disseminating this information to our SIP  
routing nodes. Further, the routing vectors involved are not always  
single-hops, but need to be able to express multiple-hop vectors.  
Conversely, the routing vectors need to be able to express aggregate  
weighting vectors while optionally suppressing remote hops, as such  
might be needed for masking remote peering agreements.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Mar 2010 12:52:33 -0500

Asterisk DUNDI ... they use it extensively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, March 04, 2010 12:00 PM
To: Dean Willis; [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event
alternative?

Dear all,

I'm wondering whether it is true to say that TRIP does not provide an answer
to the inter-ITAD reachability issue. Whitout going into technical details,
why do we have continuous requests for TRIP ITAD identifiers?

See http://www.iana.org/assignments/trip-parameters/trip-parameters.xhtml or
the IANA reports.

Cheers,
Med

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Mar 2010 12:55:33 -0500

+1 .. you cannot route on number blocks due to LNP. 90% of the NPA NXX 1000
blocks are already broken.

How many times to I have to remind people of that? And I don't even work for
NSR anymore. 

And BGP is too heavy weight

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daryl Malas
Sent: Thursday, March 04, 2010 12:06 PM
To: 'Dean Willis'; [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event
alternative?

Dean,

It has been a long time, since I read the RFC.  If I recall correctly, the
biggest problem with TRIP was the issue of Number Portability.  Unlike BGP
where there is a common rule of summarizing IP address blocks into class A's
or B's, you cannot do the same with E.164 addresses.  Before number
portability, TRIP would work good, because you can say I have NPA-NX1
through NPA-NX3.  If you want to reach them go here.  Now, there are rarely
any contiguous blocks for any service provider.  If SSPs used TRIP, they
would have to put in every single E.164 address (e.g. NPA-NXX-XXXX) into a
route table.  This would make route tables contain millions of lines, which
would slow down routing considerably...not to mention the maintenance
nightmare...not to mention the route convergence would be ugly.  Perhaps
there could be a 3rd party application that searches for contiguous ranges,
but this too would be maintenance heavy as TNs are ported from one SSP to
another; and, there is no guaran
 tee it would significantly improve the routing database issue.

Regards,

Daryl 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Thursday, March 04, 2010 9:36 AM
To: [email-masked]
Subject: [dispatch] Why are we TRIPped out? Is there an sip-event
alternative?

> not try and invent new ones.

I'm starting another thread from this comment, because it raises a really
good question.

TRIP was designed to exchange phone-number reachability information between
SIP nodes. Nobody uses it. Why?

What if the route-exchange function were done in SIP, perhaps something like
an event package for routing?

1) Since SUBSCRIBE provides the information to specify "who is asking", the
NOTIFY responses could contain route-tables customized for the recipient.
This provides the location context sensitivity missing from ENUM queries.

2) Route-table entries could be vectors, something like "I, proxy B, have a
route to proxy A, which offered me a route to example.com", allowing for
selective route-redistribution.

3) Having gotten a preliminary routing table from subscribing to a peer, one
could then query the peer's peers by subscribing directly to their routing
updates. This establishes SIP reachability to those nodes (if the SUBSCRIBE
works, you can reach them with SIP, and if their NOTIFY requests work, they
can reach you). Further, it allows the peer's peer to make a determination
of which routes they might want to offer you directly, as opposed to
transitively via the first peer.

4) Filters in the  SUBSCRIBE could be used to indicate an interest in a
subset of routes.

5) The routing vector syntax could easily allow for both phone numbers and
domain-names.

--
Dean

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Mar 2010 13:05:17 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dean Willis
Sent: Thursday, March 04, 2010 11:36 AM
To: [email-masked]
Subject: [dispatch] Why are we TRIPped out? Is there an sip-event
alternative?

RS> Heard of LNP? 

RS> IMHO more the former rather than the latter.

RS> Nahh.. the routing paths change you want a query mechanism that can
dynamically change targets based on both internal network topology as well
as source identification.

RS> You are on to something here which is the dynamic "who is asking" but
the response could be lots of things including a SPID or network identifier
if the target is truly PSTN and the target URI is a matter of bilateral
agreement. This is really about the function of the local proxy directory in
a carrier network. I want to simply send an invite but not get back a 302
..something else which may be some form of routing meta data. 

RS> maybe but gee .. ITS ALL ABOUT PHONE NUMBERS. :-) 

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 04 Mar 2010 23:19:04 -0600

> as source identification.
an event package could satisfy both of those.

> ..something else which may be some form of routing meta data. 
But hoe does the local proxy learn this stuff? This still calls for a
dynamically modeled routing topology.

> RS> maybe but gee .. ITS ALL ABOUT PHONE NUMBERS. :-) 
but you just said route aggregationon phone numbers doesn't work due to lnp!

--
dean

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 08:38:19 +0100

Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnect at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp). Partners involved in that study all agreed that a more distributed mode and dynamic mode is suitable to meet the global reachability requirement and also to allow for a more flexible interconnection model. A consensus has been reached among participant, that placing communications would involve several ITAD in the path and thus this characteristic should be known before selecting the next ITAD domain for the delivery of a call (e.g., avoid domains of competing SPs, avoid black listed ITADs, avoid congested links, allow multiple IP telephony paths, minimize interconnection cost, and in general allow for more traffic engineering at the telephony level, etc.) 

Below is listed a set of recommendations that has been proposed but the P1853 study when specifying and designing an interconnection model for session-based services. These recommendations have been drawn from the perspective of IP telephony services but are valid for presence, Instant Message, etc:

1.	Adopt the same interconnection model for various services relying on lookup function. Particularly: IP telephony, video, IM and presence.
2.	Implement a cascaded model (i.e., several ITAD hop for placing a call):
.	For flexibility and scalability reasons;
.	Offers both peering and transit modes;
.	Does not lead to a frozen service architecture;
3.	Functional separation between the lookup service and session management (i.e., initiation, terminating, modify, etc.). In particular, SIP is a session management protocol and ** not ** a telephony routing protocol;
4.	Activate dynamic means to exchange telephony routing information:
.	Abolish the usage of static practices and "file" based model;
.	The protocol can be used to interconnect internal service platforms and also with external ones;
.	Convey information to assess the telephony routes.
5.	Encourage aggregation-based advertisement model:
.	Optimise the telephony routing tables/ENUM records, etc.;
.	Check how number portability affects aggregation;
.	How to support roaming.
6.	Adopt a model supporting both closed and open communities which supports the federation scheme and compatible with IP telephony Exchange points presence;
7.	Investigate means to assess the stability and the convergence of the overall IP telephony interconnection model;
8.	Promote interconnection practices which are ** agnostic ** to the used signaling and media protocol;
9.	Use "Media trunks" instead of individual streams: reduce messages overhead, bandwidth optimisation, etc.;
10.	Standardize/share/promote SIA (Service Interconnection Agreement) template and its technical clauses;
11.	Investigate means/procedures to negotiate SIAs;
12.	Adapt the billing/charging model for inter-domain IP telephony services;
13.	Elaborate an inter-domain monitoring model including a template, methodology, etc.;
14.	Specify means to enable sophisticated service engineering: load balancing, SIA optimisation, cost optimisation, avoid congestion and loops, enhance QoS, etc.;
15.	Activate automatic failure/degradation detection and recovery means at the service level;
16.	Promote means to ensure synchronization between the service and network layers;
17.	Provisioning considerations: routing information, access control, policies, SIA to network nodes;
18.	Consider legal recommendations (e.g. legal intercept);
19.	Encourage a "Service Provider SIP/H.323 profile": this reduces the complexity of required functions in SBC nodes, protocol repair functions may be obsolete, etc.;
20.	Interconnection model/solution should support planned maintenance operations (e.g. update physical card, link, add new node, etc.);
21.	Extended TRIP protocol is suggested to be used as base for IP Telephony routing;
22.	Use simple coherent SIA profiling for homogeneous traffic and to avoid added complexity in routing optimisation. Interconnection Agreements should constantly be reviewed and a minimum utilization threshold defined. Interconnections with low usage should be cancelled to reduce cost and complexity;
23.	Employ active, non-intrusive measurements on live traffic with probes to ensure that interconnections meet the agreed requirements, maintain high service quality, increase reliability, detect and avoid failures even before they occur, avoid misuse (e.g. SPIT) in the network, etc. A monitoring template should be determined before deployment;
24.	In the SIAs to ensure quality, with a minimum MOS score of 3.6, preferably above 4.0, one-way delay less than 250 ms (even for transatlantic links) and packet loss below 2%. Active measurements should be employed to update and confirm SIAs.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dean Willis
Envoyé : jeudi 4 mars 2010 18:21
À : Daryl Malas
Cc : [email-masked]
Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

I attempt a rephrase:

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 5 Mar 2010 12:15:53 -0600

On Mar 5, 2010, at 1:38 AM, <[email-masked]> <[email-masked] 
 > wrote:

>
> Dear Dean, all,
>
> In the last year, we have undertaken a study about IP telephony  
> interconnect at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp) 
> .

I'm having a hard time resolving this link, as it appears to be 404.  
Perhaps there's a typo?

> 21.	Extended TRIP protocol is suggested to be used as base for IP  

We've heard here that TRIP, as currently modeled, doesn't work due to  
the LNP problem. What sorts of extensions id you have in mind? Were  
they intended to address this problem?

--
Dean

---

From: Bob Penfield <[email-masked]>
Date: Fri, 5 Mar 2010 13:25:22 -0500

It does not like the trailing ")", this one worked for me:

http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, March 05, 2010 1:16 PM
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

On Mar 5, 2010, at 1:38 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnect at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp).

I'm having a hard time resolving this link, as it appears to be 404. Perhaps there's a typo?

With respect to:

We've heard here that TRIP, as currently modeled, doesn't work due to the LNP problem. What sorts of extensions id you have in mind? Were they intended to address this problem?

--
Dean

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 15:32:46 +0100

Dear Dean, all,

Please see inline.
Cheers,
Med

________________________________
De : Dean Willis [mailto:[email-masked]]
Envoyé : vendredi 5 mars 2010 19:16
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Daryl Malas; [email-masked]
Objet : Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

Dear Dean, all,

In the last year, we have undertaken a study about IP telephony interconnect at large scale (URL: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp).
Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp<http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp)>
I'm having a hard time resolving this link, as it appears to be 404. Perhaps there's a typo?

With respect to:

We've heard here that TRIP, as currently modeled, doesn't work due to the LNP problem. What sorts of extensions id you have in mind? Were they intended to address this problem?
[Med] An alternative would be to use TRIP in conjunction with a the current Number Portability infrastructure as used in PSTN infrastructure for placing inter-ITAD calls (this means that the owner domain will always advertise its aggregate in TRIP, but a NPDB (Network Portability Database) should questioned first).

Examples of extensions to TRIP (or whatever dynamic telephony routing) would be:
- Avoid AS (Autonomous System) spiral: the media traffic can cross the same AS several times
- Ability to maintain multiple inter-ITAD paths
- Ability to enforce some advanced TE such as: Avoid that my VoIP traffic to cross a given AS domain (TRIP only maintain an ITAD list)
- Ability to avoid congestionned links
- etc.

BTW, TRIP is only considered as starting point, this does not preclude to investigate any new solution to meet the recommendations we identified. BTW, In the recommendations list we have identified the need to encourage aggregation-based models.

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 8 Mar 2010 18:26:49 -0500

Just a word of caution re number portability. In some countries access to this data is restricted to legally qualified carriers.  Will ITADs always correspond to such entities? Looking at the IANA list so far that's not my impression. You may find that the entities that do have access to NP databases may not be the ones interested in a TRIP-like mechanism and vice versa.

Penn Pfautz

AT&T Access Management

+1-732-420-4962

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 08, 2010 9:33 AM
To: Dean Willis
Cc: [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

Dear Dean, all,

Please see inline.

Cheers,

Med

On Mar 5, 2010, at 1:38 AM, <[email-masked]> <[email-masked]> wrote:

Dear Dean, all,

Med: http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp <http://www.eurescom.eu/message/messageMay2009/Interconnection_challenges_of_IP_telephony_Eurescom_study_P1853.asp)>   

With respect to:

- etc.

---

From: <[email-masked]>
Date: Tue, 9 Mar 2010 08:16:44 +0100

Dear Penn,

I fully agree with you about this "legal" frontier.

Then, do such ITADs (which have no access to NPDB) concerned about NP? Do these operators offer telephony services or only VoIP (i.e., no emergency calls, no NP, no legal intercept, and all the legal requirements)?

If these domains want to offer global telephony reachability they must have contract(s) with one or several PSTN (or mobile) operators (seen as default route). NP should be handled downstream.

Cheers,
Med

________________________________
De : PFAUTZ, PENN L (ATTCORP) [mailto:[email-masked]]
Envoyé : mardi 9 mars 2010 00:27
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Dean Willis
Cc : [email-masked]
Objet : RE: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

Penn Pfautz
AT&T Access Management
+1-732-420-4962

Dear Dean, all,

Please see inline.
Cheers,
Med

Dear Dean, all,

With respect to:

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 10 Mar 2010 16:44:04 +0100

Penn,

On 09.03.2010 00:26, PFAUTZ, PENN L (ATTCORP) wrote:
> Just a word of caution re number portability. In some countries access
> to this data is restricted to legally qualified carriers.  Will ITADs
> always correspond to such entities? Looking at the IANA list so far
> that's not my impression. You may find that the entities that do have
> access to NP databases may not be the ones interested in a TRIP-like
> mechanism and vice versa.

This is indeed a relevant point.

>From my perspective, this is, while true, mostly a red herring erected by
carriers who try to shield the actual market numbers from the public.

For example, in Austria NP data used to be private and carriers (plus their
lobbyists) worked hard to keep it that way. Then one day we finally
implemented mobile NP in Austria. As calling towards mobiles is
comparatively expensive and the tariff varies by destination network, the
regulator mandated that callers have to be notified via a voice
announcement if a number has been ported. (The price for a call might have
changed from 0 cents/min (on-net for some deals) to 30 cents/min due to a
porting operation. So this was a legitimate consumer protection issue.)

In other words, we went from a "keep this info private" mindset to a "annoy
end-users with this information on each call" within a year.

So: if there is a legitimate reason why the general public needs this
information (e.g. to do correct least-cost routing on multi-homed PBXs)
then this can change quickly.

otmar
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Wed, 10 Mar 2010 11:23:05 -0500

Otmar:
I hear you (although in the US we didn't do calling-party-pays and
carriers generally don't reflect different termination rates in their
retail toll prices so we won't have *that* problem.)

But I'd really like to raise what I think is a larger issue - just what
are we trying to accomplish?

All the LRF and TRIP stuff seems to be tending toward a kind of
link-by-link call routing model that to me seems redolent of the kind of
trunk group by trunk group routing in the PSTN. I thought that that was
what we were trying to get away from in moving to IP! 
The original promise of ENUM was that it would identify the target and
basic Internet connectivity would then get you there.
As you've pointed out elsewhere, that original vision didn't really work
for most carriers, but carriers have tried to replicate parts of it with
approaches like the GSMA IPX to provide a secure IP fabric for
connecting. That allows connectivity management via selective
advertising in BGP so that the SIP INVITES based on same ENUM query
response is appropriately routed from different originating networks.
The same techniques support direct bilateral interconnection which is
how much of the traffic will flow anyway.

So, when would you want something TRIP like? To me the remaining case
seems to be when you're searching for the best intermediary when you're
neither directly connected nor linked to some kind of IPX like fabric
that can get to the target. I expect intermediaries to compete and scale
to matter. When I need an intermediary I'll generally prefer that they
handle the whole job. Some pricing tables will let me choose and I'm not
sure I need/want those coming across the NNI as reachability
advertisements. 

Add to this the downward pressure on rates that is only going accelerate
and I wonder how much need there really is. I may be biased from my
vantage point though and perhaps someone can provide the compelling use
case.

Penn Pfautz
AT&T Access Management
+1-732-420-4962
-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2010 10:44 AM
To: PFAUTZ, PENN L (ATTCORP)
Cc: [email-masked]; Dean Willis; [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event
alternative?

Penn,

For example, in Austria NP data used to be private and carriers (plus
their
lobbyists) worked hard to keep it that way. Then one day we finally
implemented mobile NP in Austria. As calling towards mobiles is
comparatively expensive and the tariff varies by destination network,
the
regulator mandated that callers have to be notified via a voice
announcement if a number has been ported. (The price for a call might
have
changed from 0 cents/min (on-net for some deals) to 30 cents/min due to
a
porting operation. So this was a legitimate consumer protection issue.)

In other words, we went from a "keep this info private" mindset to a
"annoy
end-users with this information on each call" within a year.

otmar

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Wed, 10 Mar 2010 12:10:29 -0500

...taking this discussion onto a related tangent....

These regulatory and contractual limitations on access to TN->Carrier assignments are one of the reasons that existing systems that currently provide the envisioned LUF feature (query a TN to find out the responsible carrier currently assigned to that TN, more or less) are *required* to allow the LUF responses to vary based on the querier.  Additional requirements that necessitate this are:

(1)     This TN->CarrierAssignment data set is often/usually "layered", in the sense that the a country code's Based Number Plan TN->CarrierAssignments comprise the foundation layer, that is then overlaid by (but not co-mingled with) number portability TN->CarrierAssignmens, that is then overlaid by (but not comingled with) TN->CarrierAssignments for TNs that are leased across carriers, that is then overlaid by TN->CarrierAssignments for TNs that override any of the proceeding for any number of business or operational reasons (although this last overlay is less structured and less relevant to the overall point).
(2)     Regulatory, contractual, and business reasons currently determine, for each country code, the layers and subsets of layers of TN->CarrierAssignments that any given querier is allowed to "see".
(3)     Some queriers simply do not want to see certain layers of TN->CarrierAssignemnts for given country codes.
(4)     Because many country codes do not have a regulatory or any well defined source for TN->CarrierAssignments, the data is sourced from multiple parties.  So even within a given country code, only portions of a given layer may be allowed to be seen by some queriers.

So one way of looking at the problem space of the LUF is that the above requirements are not what we want to solve and standardize.  What we want to solve and standardize is the much simpler and pristine end goal of ... all TN->CarrierAssignment information is queriable by any organization and all those organizations have legal access to all of it.  We solve and standardize this with the view of "build it and they will come".

The other way of looking at the problem is that we solve the requirements stated above.

Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L (ATTCORP)
Sent: Monday, March 08, 2010 6:27 PM
To: [email-masked]; Dean Willis
Cc: [email-masked]
Subject: Re: [dispatch] Why are we TRIPped out? Is there an sip-event alternative?

Penn Pfautz
AT&T Access Management
+1-732-420-4962

Dear Dean, all,

Please see inline.
Cheers,
Med

Dear Dean, all,

With respect to:

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Mar 2010 17:37:48 -0600

> what we were trying to get away from in moving to IP!

Excellent point. We're moving towards application-specific routing  
infrastructure and an "intelligent network." It rather turns my  
stomach. But building tools for this model that actually work well  
turns my stomach less than hacking up DNS to commit the same atrocities.

On the other hand, "trunking" seems to be what people are actually  
willing to pay for. A democracy will get the government it deserves,  
and a market economy will get the products it buys.

--
Dean

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 11 Mar 2010 23:23:42 +0100

Penn,

> are we trying to accomplish?

Good question: what kind of interconnection model is the right one? That is
the 1 M $ question.

> link-by-link call routing model that to me seems redolent of the kind
> of trunk group by trunk group routing in the PSTN. I thought that that
> was what we were trying to get away from in moving to IP! The original
> promise of ENUM was that it would identify the target and basic Internet
> connectivity would then get you there. As you've pointed out elsewhere,

(For those who have not followed the discussions in speermint, my arguments
are laid out in draft-lendl-speermint-background-02 )

> that original vision didn't really work for most carriers, but carriers
> have tried to replicate parts of it with approaches like the GSMA IPX to
> provide a secure IP fabric for connecting. That allows connectivity
> management via selective advertising in BGP so that the SIP INVITES
> based on same ENUM query response is appropriately routed from different
> originating networks. The same techniques support direct bilateral
> interconnection which is how much of the traffic will flow anyway.

That the carriers seem to be falling for this blatant monopoly play by the
IPX advocates is something that never fails to amaze me.

I just don't see how bilateral peerings outside the IPX can be visible in
the Layer 3 routing map of the IPX and thus be eligible to be used as
transit links. All this fancy BGP trickery only works if *all* players in
the VoIP routing space are IPX members (will the IPX admit corporate PBxs
into their net?) and all transit-capable links between them are within the
IPX framework.

> that can get to the target. I expect intermediaries to compete and
> scale to matter. When I need an intermediary I'll generally prefer that
> they handle the whole job. Some pricing tables will let me choose and
> I'm not sure I need/want those coming across the NNI as reachability 
> advertisements.

If the main problem is that you can't fully mesh all SSPs (which includes
PBXs), then shifting the interconnection duty to "intermediaries" does
simplify the problem a bit, but it does not solve it. That step only works
if all the intermediaries are members of the IPX.

This is not realistic.

There will be competing peering infrastructures. Starting from other
commercial undertakings in the western world (Xconnect & co) to perhaps a
Chinese peering platform and an Arabic one.

Now, will all intermediaries join all those platforms? Will any two of them
share at least one? Or will there be a hierarchy of intermediaries (just
like the tiers in the PSTN and the Internet world)? How will routing
information be passed between the tiers? Across multiple fabrics?

Maybe the IPX proponents have a plan for that. I haven't seen it.

> Add to this the downward pressure on rates that is only going
> accelerate and I wonder how much need there really is. I may be biased
> from my vantage point though and perhaps someone can provide the
> compelling use case.

>From my point of view, the pressure on rates will continue, and in the long
term they will be replaced by the cost the destination places on his attention.

A hardcore end to end interconnection model will run into the same problems
email faces these days. The price I pay to my voice operator will shift
from paying for the transmission capacity to what additional trust and
accountability he can confer the called party.

What I can imagine for the future is a scenario where PBXs/carriers will
allow calls from trusted parties (however that is defined) to reach their
ingress points without settlement. But I doubt that I will allow my phone
to ring just because some punk in Indonesia sends my PBX a few IP packets.
That will be one of the jobs of a carrier: I will want to get the call
either directly from someone who falls under my criteria of a trusted
communication partner or from some carrier that either pays me to let the
phone ring, guarantees that he polices his users, or simply charges his
users for calling me.

We're entering a phase where attention is more valuable than the 64kbit/s
transmission capacity of a traditional voice channel.

The business model of carriers might need to adjust to that, and I
definitely think there is a role for them here. If not, voice will move
from being a service to being a product that I buy at my local electronics
discounter just as I buy a wlan AP there.

(And no, Skype / Google Talk / <insert you favorite walled garden> won't
cut it. Not for replacing a word-wide, ubiquitous medium that can act as a
global default communication path.)

But we're getting slightly off tangent here ...

Anyway, I few years ago I proposed a scheme that tried to integrate both
RFC 3263-style end-2-end routing, controlled opportunistic peering, and
old-style PSTN-like transit routing into one overall scheme. This would
have allowed SSPs full control over their peering/interconnection
strategies and would have allow mixed mode arrangements and thus gradual
changes in policy to allow for an evolution of the interconnection ecosystem.

Speermint wasn't interested.

otmar