Re: AW: [enum-wg] COCOM & ENUM ...
"Richard" == Stastny Richard <Richard.Stastny@oefeg.at> writes:
Richard> I fully agree and this is one of the problems I see by Richard> introducing carrier E**M via a backdoor in e164.arpa. If Richard> I am a carrier, especially a carrier acting on an Richard> international basis, I want to implement routing Richard> mechanisms within my network and with other networks Richard> (peers) without having to go to a NRA begging first to Richard> opt-in in e164.arpa and second to behave according to Richard> various and different national rules. Richard, these points are undoubtedly true. However they have nothing whatsoever to do with the choice of domain name for carrier ENUM. So far, nobody has presented any compelling reason why another domain name is needed for carrier ENUM. [Perhaps that discussion is going on behind closed doors at ETSI or somewhere like that.] Sure, carrier ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an operator from creating their own private e164.arpa tree, populating that with whatever it likes and then making sure the applications on the operator's net queries the private tree rather than the public one. This setup is known as split DNS and is very common. Most large companies do this. What we see on the internet for bt.com (say) will be very different from what someone inside the BT network sees. What *is* important is that there's a single domain name and a single, consistent name space. Many of the applications and services -- eg VoIP and SIP -- that will be used by telcos will also be used on the public internet. Suppose I'm developing or selling and supporting some ENUM-aware SIP application. I don't want to have the complexity and expense of needing to configure it to do ENUM-like lookups in foobar.at if the box lives in Telekom Austria's net today or vf.enum.egpp.net if that's where Vodafone's chosen to anchor its carrier ENUM tree this week. And as for an ENUM-aware SIP client in a mobile phone that roams between operators... Or flips between 802.11 and GPRS nets... Richard> A carrier E**M implementation does not need a tier 0 and Richard> tier 1, and it is questionable if it needs a tier 2. It Richard> needs a centralisized database operated by someone, and Richard> who this is will be decided by the community as will be Richard> the other rules. The Tier-N jargon is probably inappropriate. However the roles might not be. And I'm not sure a centralised database for carrier ENUM is viable. It has obvious attractions: carriers sharing a common infrastructure for example. OTOH, it brings problems too. Figuring out who operates that infrastructure and how it gets paid for will be entertaining. A centralised database could well mean telcos expose their customer and call routing data to each other. Which is unlikely to get much acceptance.
Hi Jim, Richard, folks, I beg to differ with my esteemed colleague Jim. I would be very surprised if an end user's terminal queried carrier anything, and would be even more surprised if it received a response. This is akin to suggesting that if my phone fired off an INAP query it would receive a response. With SCTP it might be theoretically possible, but I don't expect anyone would be listening. In the "new wine in old skins" world of NGNs, the infrastructure might make queries as part of a routing process, and one service provider would almost certainly get a different answer from the one responsible for the target resource (i.e. the "destination" service provider will probably be running a split horizon system), but would my SIP phone get ANY such information? Private and Public are the wrong terms - if service providers share some information to facilitate routing of communications sessions, this does not make that information public (e.g. available to anyone anywhere on the Internet). It's shared between carriers. I sure hope that their infrastructure doesn't roam - the bean counters would not be happy. all the best, Lawrence On 14 Dec 2004, at 10:15, Jim Reid wrote:
"Richard" == Stastny Richard <Richard.Stastny@oefeg.at> writes:
Richard> I fully agree and this is one of the problems I see by Richard> introducing carrier E**M via a backdoor in e164.arpa. If Richard> I am a carrier, especially a carrier acting on an Richard> international basis, I want to implement routing Richard> mechanisms within my network and with other networks Richard> (peers) without having to go to a NRA begging first to Richard> opt-in in e164.arpa and second to behave according to Richard> various and different national rules.
Richard, these points are undoubtedly true. However they have nothing whatsoever to do with the choice of domain name for carrier ENUM. So far, nobody has presented any compelling reason why another domain name is needed for carrier ENUM. [Perhaps that discussion is going on behind closed doors at ETSI or somewhere like that.] Sure, carrier ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an operator from creating their own private e164.arpa tree, populating that with whatever it likes and then making sure the applications on the operator's net queries the private tree rather than the public one. This setup is known as split DNS and is very common. Most large companies do this. What we see on the internet for bt.com (say) will be very different from what someone inside the BT network sees.
What *is* important is that there's a single domain name and a single, consistent name space. Many of the applications and services -- eg VoIP and SIP -- that will be used by telcos will also be used on the public internet. Suppose I'm developing or selling and supporting some ENUM-aware SIP application. I don't want to have the complexity and expense of needing to configure it to do ENUM-like lookups in foobar.at if the box lives in Telekom Austria's net today or vf.enum.egpp.net if that's where Vodafone's chosen to anchor its carrier ENUM tree this week. And as for an ENUM-aware SIP client in a mobile phone that roams between operators... Or flips between 802.11 and GPRS nets...
Richard> A carrier E**M implementation does not need a tier 0 and Richard> tier 1, and it is questionable if it needs a tier 2. It Richard> needs a centralisized database operated by someone, and Richard> who this is will be decided by the community as will be Richard> the other rules.
The Tier-N jargon is probably inappropriate. However the roles might not be. And I'm not sure a centralised database for carrier ENUM is viable. It has obvious attractions: carriers sharing a common infrastructure for example. OTOH, it brings problems too. Figuring out who operates that infrastructure and how it gets paid for will be entertaining. A centralised database could well mean telcos expose their customer and call routing data to each other. Which is unlikely to get much acceptance.
At 05:15 AM 12/14/2004, Jim Reid wrote:
"Richard" == Stastny Richard <Richard.Stastny@oefeg.at> writes:
Richard> I fully agree and this is one of the problems I see by Richard> introducing carrier E**M via a backdoor in e164.arpa. If Richard> I am a carrier, especially a carrier acting on an Richard> international basis, I want to implement routing Richard> mechanisms within my network and with other networks Richard> (peers) without having to go to a NRA begging first to Richard> opt-in in e164.arpa and second to behave according to Richard> various and different national rules.
Richard, these points are undoubtedly true. However they have nothing whatsoever to do with the choice of domain name for carrier ENUM. So far, nobody has presented any compelling reason why another domain name is needed for carrier ENUM.
HUH are you kidding ... its is because of the basic and orthogonal conflict between what carriers need and want and what end users need and want. The problem is administrative how do two occasionally diametrically opposed entities share a single name space. I perfectly understand the technical dilemma service providers have but if you look a what it will take to actually implement such a policy you are left with 3 basic options. Either bifurcate the tree at Tier one into two non terminal NAPTR records (public & carrier)..which BTW will break SIP applications since there is no standards any where on how to deal with this. Two merge T1 and T2 into the national registry which makes the registry operator the central repository for ALL SIP routing data for both the carriers and end users...which at least preserves the existing model of the DNS responds with an "answer" ..the carriers can still use non terminal records but normal SIP CUA's would simply ignore them. Three have two entirely separate trees ..e164.arpa for number holders e164.int for carriers. The .int tree could be designed to look into apra for answers it is not authoritative for. Problem solved.
[Perhaps that discussion is going on behind closed doors at ETSI or somewhere like that.] Sure, carrier ENUM shouldn't be in the public e164.arpa tree. This doesn't stop an operator from creating their own private e164.arpa tree, populating that with whatever it likes and then making sure the applications on the operator's net queries the private tree rather than the public one. This setup is known as split DNS and is very common. Most large companies do this. What we see on the internet for bt.com (say) will be very different from what someone inside the BT network sees.
oh no we're not going down that rat hole of split DNS
What *is* important is that there's a single domain name and a single, consistent name space.
I dont agree the applications are sufficiently orthogonal enough to argue that the administrative policies and procedures are different enough to justify two separated trees.
Many of the applications and services -- eg VoIP and SIP -- that will be used by telcos will also be used on the public internet. Suppose I'm developing or selling and supporting some ENUM-aware SIP application. I don't want to have the complexity and expense of needing to configure it to do ENUM-like lookups in foobar.at if the box lives in Telekom Austria's net today or vf.enum.egpp.net if that's where Vodafone's chosen to anchor its carrier ENUM tree this week. And as for an ENUM-aware SIP client in a mobile phone that roams between operators... Or flips between 802.11 and GPRS nets...
you forget the basic consumer or PBX edge ENUM resolver has no need to see the carrier data.
Richard> A carrier E**M implementation does not need a tier 0 and Richard> tier 1, and it is questionable if it needs a tier 2. It Richard> needs a centralisized database operated by someone, and Richard> who this is will be decided by the community as will be Richard> the other rules.
The Tier-N jargon is probably inappropriate. However the roles might not be. And I'm not sure a centralised database for carrier ENUM is viable. It has obvious attractions: carriers sharing a common infrastructure for example. OTOH, it brings problems too. Figuring out who operates that infrastructure and how it gets paid for will be entertaining.
Oh that is real simple ... the carrier of record of the TN will immediately know how to fund and manage that namesapce for their respective portions of the .int tree for instance or they will use totall out of band methods of exchanging TN to URI data like LNP data bases that push the data into carrier networks. And BTW most all the carriers I talk to these days want the data presented to them via SIP redirect/location servers not DNS.
A centralised database could well mean telcos expose their customer and call routing data to each other. Which is unlikely to get much acceptance.
Well then you have argued that LNP databases dont work and I have it on good authority that they do :-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
"Richard" == Richard Shockey <richard@shockey.us> writes:
Richard> HUH are you kidding ... its is because of the basic and Richard> orthogonal conflict between what carriers need and want Richard> and what end users need and want. I'm not convinced that really is (or will be) the case. Alice is an end user with SIP applications that lookup E.164 numbers in public e164.arpa tree to find SIP gateways. Fast-forward a few years. Bob's a telco doing VoIP and SIP and using DNS lookups of E.164 numbers to route calls in his net and to other operators. What's the difference? The applications are both using the DNS to figure out how to find the right SIP server for some VoIP session (or whatever). Carol sells SIP server and client software. Will she want to develop, sell and support different versions of the same thing to Alice and Bob? Meantime, what if Bob wants to dump calls from his network to Alice on Alice's internet SIP server so that he doesn't have to pay termination charges to Alice's telco? Richard> Either bifurcate the tree at Tier one into two non Richard> terminal NAPTR records (public & carrier)..which BTW will Richard> break SIP applications since there is no standards any Richard> where on how to deal with this. Maybe there should be a standard on this? :-) Though the bifurcation could also be realised with split DNS. Richard> Two merge T1 and T2 into the national registry which Richard> makes the registry operator the central repository for Richard> ALL SIP routing data for both the carriers and end Richard> users...which at least preserves the existing model of Richard> the DNS responds with an "answer" ..the carriers can Richard> still use non terminal records but normal SIP CUA's would Richard> simply ignore them. This is too awful for words. I think there's general consensus that end users should not see core telco routing data. Richard> Three have two entirely separate trees ..e164.arpa for Richard> number holders e164.int for carriers. The .int tree Richard> could be designed to look into apra for answers it is not Richard> authoritative for. Problem solved. This gets very ugly very quickly IMO. Operationally such setups would be very brittle and near-impossible to debug. Richard> oh no we're not going down that rat hole of split DNS It's no more of a rat hole than having yet another domain name with funky forwarding/fallback on failure modes between the 2 (or more?) domain names that you seem to favour. I suspect these could be much, much worse to administer and operate than a split DNS solution. It would be good to get hard data on the pros and cons of both approaches. And any others for that matter. Even better would be to get that data before a lasting decision is made. :-) Richard> you forget the basic consumer or PBX edge ENUM resolver Richard> has no need to see the carrier data. I've not forgotten that at all. I think you have misunderstood me. Well, I have an accent.... :-) Suppose some company is writing ENUM-aware telephony software that needs to figure out which SIP server to use when terminating a call for some E.164 number. [Note the deliberate hand-waving about where that software lives or which net the device is on.] How many DNS lookups and domain names is it going to need to do that? From a developer's perspective, how will the software know which net it's in so it knows which domain names to try (and in what order)? >> A centralised database could well mean telcos expose their >> customer and call routing data to each other. Which is unlikely >> to get much acceptance. Richard> Well then you have argued that LNP databases dont work Richard> and I have it on good authority that they do :-) You would say that, wouldn't you? :-) Does a number portability database disclose to TelcoA how TelcoB routes calls around its networK?
At 03:48 PM 12/14/2004, Jim Reid wrote:
"Richard" == Richard Shockey <richard@shockey.us> writes:
Richard> HUH are you kidding ... its is because of the basic and Richard> orthogonal conflict between what carriers need and want Richard> and what end users need and want.
I'm not convinced that really is (or will be) the case. Alice is an end user with SIP applications that lookup E.164 numbers in public e164.arpa tree to find SIP gateways. Fast-forward a few years. Bob's a telco doing VoIP and SIP and using DNS lookups of E.164 numbers to route calls in his net and to other operators. What's the difference?
a great deal .. network operators do not generally or historically expose internal network architectures or border ingress elements into something as public as the DNS. the general requirement I have been constantly told is that the result of the carrier TN2URI translation must not be publicly exposed or amenable to MiM attack and is generally hidden behind some AA which is why all the discussion on non terminal NAPTR records.
The applications are both using the DNS to figure out how to find the right SIP server for some VoIP session (or whatever). Carol sells SIP server and client software. Will she want to develop, sell and support different versions of the same thing to Alice and Bob?
Of course not that is why the carrier record would be non terminal and require out AA in fact most of the architectures I see nearly have only 1 URI for the entire network. A huge wall of SBC's surrounding the VoIP network.
Meantime, what if Bob wants to dump calls from his network to Alice on Alice's internet SIP server so that he doesn't have to pay termination charges to Alice's telco?
Richard> Either bifurcate the tree at Tier one into two non Richard> terminal NAPTR records (public & carrier)..which BTW will Richard> break SIP applications since there is no standards any Richard> where on how to deal with this.
Maybe there should be a standard on this? :-) Though the bifurcation could also be realised with split DNS.
I do not agree on either point. SIP CUA's would all have to be redesigned to accept the new DNS structure ..I dont think that is acceptable.
Richard> Two merge T1 and T2 into the national registry which Richard> makes the registry operator the central repository for Richard> ALL SIP routing data for both the carriers and end Richard> users...which at least preserves the existing model of Richard> the DNS responds with an "answer" ..the carriers can Richard> still use non terminal records but normal SIP CUA's would Richard> simply ignore them.
This is too awful for words. I think there's general consensus that end users should not see core telco routing data.
not if the URI is non terminal it only increases the requirements on the registry. The Tier 1 Tier 2 constructs were artificial in the first place to more balance the loads on the DNS and give end user more flexible options on controlling their NAPTR records.
Richard> Three have two entirely separate trees ..e164.arpa for Richard> number holders e164.int for carriers. The .int tree Richard> could be designed to look into apra for answers it is not Richard> authoritative for. Problem solved.
This gets very ugly very quickly IMO. Operationally such setups would be very brittle and near-impossible to debug.
what are you talking about ..it would work perfectly well. End user CUA's do not need to see carrier data so they would never look into carrier.foo but John is entirely right here the chances of carrier.foo getting off the ground are problematic though .MOBI did get through ICANN for some reason.
Richard> oh no we're not going down that rat hole of split DNS
It's no more of a rat hole than having yet another domain name with funky forwarding/fallback on failure modes between the 2 (or more?) domain names that you seem to favour. I suspect these could be much, much worse to administer and operate than a split DNS solution. It would be good to get hard data on the pros and cons of both approaches. And any others for that matter. Even better would be to get that data before a lasting decision is made. :-)
Richard> you forget the basic consumer or PBX edge ENUM resolver Richard> has no need to see the carrier data.
I've not forgotten that at all. I think you have misunderstood me. Well, I have an accent.... :-)
Suppose some company is writing ENUM-aware telephony software that needs to figure out which SIP server to use when terminating a call for some E.164 number. [Note the deliberate hand-waving about where that software lives or which net the device is on.] How many DNS lookups and domain names is it going to need to do that?
only one ..if the software is edge based in the case of IP-PBX's or end user devices, two if the proxy is licensed carrier based ( aka they issue phone numbers ) the definition of a carrier here is do you or do you not issue phone numbers..if you do not you will not have access to the carrier data and BTW that will not guarantee that the network provider will even give you access to the network .. the two carriers will have presumed to have a bi-lateral agreement in place covering inter network transactions.
From a developer's perspective, how will the software know which net it's in so it knows which domain names to try (and in what order)?
>> A centralised database could well mean telcos expose their >> customer and call routing data to each other. Which is unlikely >> to get much acceptance.
Richard> Well then you have argued that LNP databases dont work Richard> and I have it on good authority that they do :-)
You would say that, wouldn't you? :-)
Does a number portability database disclose to TelcoA how TelcoB routes calls around its networK?
no only the destination endpoint or LRN in the case of the US and Canada. The carrier TN2URI scheme would not expose internal network archichecture either under the current designs I've seen ..only the location of the network Session Border Element or Controller. The terminating carrier network would still need to look up into its own routing tables ..and this is where I see SIP redirect all over the place..to find the actual end point routing data. There is no doubt in my mind BTW that SIP redirect servers are being used to replicate the functionality of Service Control Points (SCP's) in the IN and that SIP is becoming the new NGN equivalent of TCAP. But even exposing the LRN does permit the originating carrier to deduce a great deal about the called party network provider...in the first case you know the number has been ported and from the LRN tables you can find out who that carrier is. In the US and Canada LIDB will give you everything else you want to know about the customer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Hi Richard, Jim, folks, OK - now I'm unhappy. I think Jim raises the point that the distinction between a carrier and an end user is going to get blurred. True and an interesting nugget, but... (i) The developer doesn't have to do anything they aren't doing already. If anyone makes an ENUM client with a hard coded #define for e164.arpa then they are dumb - everyone needs to debug the stuff as it isn't all in place yet (at least in other parts of the world :). Hence pretty much every client has some way of selecting the apex, and often the DNS server that it will query. Thus this argument is puff (and I suspect that everyone here knows it is :( (ii) Every carrier (and maybe even end users if we don't get our act together) is going to have to select the servers they query and the net address from which they will accept a request and return data - true whether its a split or they just accept queries only from "anointed" network addresses. There *is* going to be carrier configuration of the servers *AND* clients in the same way that there is now (if only to set the resolver to set/send EDNS0 queries). Thus the idea that one size fits all is just not going to play with any Ops guys in any carrier (at least I hope not any who provide ME with service). In short, a developer that doesn't allow change to the apex is even less proficient than I am at programming, and that's saying something. Similarly, each carrier is going to do configuration in any real situation; NGNs don't work out of the box [of course, this is not an official position of any vendor, but... ] Richard has managed to confuse me over the term "non-terminal NAPTR". (iii) This use of the term "non-terminal NAPTRs" is starting to grate. I suspect that the mail below doesn't talk about non-terminal NAPTRs (according to RFC3403) but instead implies a link to some kind of Service Resolution Service is triggered, or else I need the AA side of this explained in a lot more detail. If this *is* the [names deleted to protect the alleged perpetrators] idea of using non-terminals at T1/T0 then I stand corrected, but I may well be sick. Please don't use the term Non-Terminal NAPTR (i.e. one with an empty flags field) if you don't mean such a construct. 'u' with E2U+sip or sip+E2U is a kosher terminal NAPTR. If the result of sending an INVITE to the server mentioned in the URI isn't the end of the story, that's a purely non-ENUM problem - blame the cult, but not the ENUM design - 340x and 3761 are at least crystal clear on this topic. Forgive the rant, but I believe that there's nothing in the experiences draft that won't be applicable for *any* flavour of ENUM, and do not want to change it to say that non-terminal NAPTRs are nice friendly creatures that we should all grow to know and love after all. If you feel that this is necessary, I'll let you explain it in detail (just give me due warning so I can duck :) all the best, Lawrence On 14 Dec 2004, at 21:59, Richard Shockey wrote:
At 03:48 PM 12/14/2004, Jim Reid wrote:
> "Richard" == Richard Shockey <richard@shockey.us> writes: Richard> HUH are you kidding ... its is because of the basic and Richard> orthogonal conflict between what carriers need and want Richard> and what end users need and want.
I'm not convinced that really is (or will be) the case. Alice is an end user with SIP applications that lookup E.164 numbers in public e164.arpa tree to find SIP gateways. Fast-forward a few years. Bob's a telco doing VoIP and SIP and using DNS lookups of E.164 numbers to route calls in his net and to other operators. What's the difference?
a great deal .. network operators do not generally or historically expose internal network architectures or border ingress elements into something as public as the DNS.
the general requirement I have been constantly told is that the result of the carrier TN2URI translation must not be publicly exposed or amenable to MiM attack and is generally hidden behind some AA which is why all the discussion on non terminal NAPTR records.
The applications are both using the DNS to figure out how to find the right SIP server for some VoIP session (or whatever). Carol sells SIP server and client software. Will she want to develop, sell and support different versions of the same thing to Alice and Bob?
Of course not that is why the carrier record would be non terminal and require out AA in fact most of the architectures I see nearly have only 1 URI for the entire network. A huge wall of SBC's surrounding the VoIP network.
Meantime, what if Bob wants to dump calls from his network to Alice on Alice's internet SIP server so that he doesn't have to pay termination charges to Alice's telco?
Richard> Either bifurcate the tree at Tier one into two non Richard> terminal NAPTR records (public & carrier)..which BTW will Richard> break SIP applications since there is no standards any Richard> where on how to deal with this.
Maybe there should be a standard on this? :-) Though the bifurcation could also be realised with split DNS.
I do not agree on either point. SIP CUA's would all have to be redesigned to accept the new DNS structure ..I dont think that is acceptable.
Richard> Two merge T1 and T2 into the national registry which Richard> makes the registry operator the central repository for Richard> ALL SIP routing data for both the carriers and end Richard> users...which at least preserves the existing model of Richard> the DNS responds with an "answer" ..the carriers can Richard> still use non terminal records but normal SIP CUA's would Richard> simply ignore them.
This is too awful for words. I think there's general consensus that end users should not see core telco routing data.
not if the URI is non terminal it only increases the requirements on the registry. The Tier 1 Tier 2 constructs were artificial in the first place to more balance the loads on the DNS and give end user more flexible options on controlling their NAPTR records.
Richard> Three have two entirely separate trees ..e164.arpa for Richard> number holders e164.int for carriers. The .int tree Richard> could be designed to look into apra for answers it is not Richard> authoritative for. Problem solved.
This gets very ugly very quickly IMO. Operationally such setups would be very brittle and near-impossible to debug.
what are you talking about ..it would work perfectly well. End user CUA's do not need to see carrier data so they would never look into carrier.foo
but John is entirely right here the chances of carrier.foo getting off the ground are problematic though .MOBI did get through ICANN for some reason.
Richard> oh no we're not going down that rat hole of split DNS
It's no more of a rat hole than having yet another domain name with funky forwarding/fallback on failure modes between the 2 (or more?) domain names that you seem to favour. I suspect these could be much, much worse to administer and operate than a split DNS solution. It would be good to get hard data on the pros and cons of both approaches. And any others for that matter. Even better would be to get that data before a lasting decision is made. :-)
Richard> you forget the basic consumer or PBX edge ENUM resolver Richard> has no need to see the carrier data.
I've not forgotten that at all. I think you have misunderstood me. Well, I have an accent.... :-)
Suppose some company is writing ENUM-aware telephony software that needs to figure out which SIP server to use when terminating a call for some E.164 number. [Note the deliberate hand-waving about where that software lives or which net the device is on.] How many DNS lookups and domain names is it going to need to do that?
only one ..if the software is edge based in the case of IP-PBX's or end user devices, two if the proxy is licensed carrier based ( aka they issue phone numbers )
the definition of a carrier here is do you or do you not issue phone numbers..if you do not you will not have access to the carrier data and BTW that will not guarantee that the network provider will even give you access to the network .. the two carriers will have presumed to have a bi-lateral agreement in place covering inter network transactions.
From a developer's perspective, how will the software know which net it's in so it knows which domain names to try (and in what order)?
>> A centralised database could well mean telcos expose their >> customer and call routing data to each other. Which is unlikely >> to get much acceptance.
Richard> Well then you have argued that LNP databases dont work Richard> and I have it on good authority that they do :-)
You would say that, wouldn't you? :-)
Does a number portability database disclose to TelcoA how TelcoB routes calls around its networK?
no only the destination endpoint or LRN in the case of the US and Canada. The carrier TN2URI scheme would not expose internal network archichecture either under the current designs I've seen ..only the location of the network Session Border Element or Controller. The terminating carrier network would still need to look up into its own routing tables ..and this is where I see SIP redirect all over the place..to find the actual end point routing data.
There is no doubt in my mind BTW that SIP redirect servers are being used to replicate the functionality of Service Control Points (SCP's) in the IN and that SIP is becoming the new NGN equivalent of TCAP.
But even exposing the LRN does permit the originating carrier to deduce a great deal about the called party network provider...in the first case you know the number has been ported and from the LRN tables you can find out who that carrier is. In the US and Canada LIDB will give you everything else you want to know about the customer.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141@fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 <mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
participants (3)
-
Conroy, Lawrence (SMTP) -
Jim Reid -
Richard Shockey