Participants: Simon Horne in CA - startup doing v/c, based in Australia but work remotely; Walt - taking day off, working from home in Texas, Jason from Australia, Bob Dixon, Mark Leonard fromUniv of New Hampshire, Tyler Johnson
Internet2. Acrobat.com/avci
ACVI
Friday, April 9, 2010
11:00 AM
Ben mentioned setting up Adobe Connect room.
Ben:
Roll Call (West to East): Ben Fineman, Bob Dixon, Charles Ganzhorn, Jeannine Lim, Jason Bourdujenco, Mark Leonard, Tyler Johnson, Simon Horne, Walt TX AA&M, Laurie Kirchmeier,
Ben: This meeting continues our series of level set meetings to discussion dial plans and infrastruture plans to facilitiate realtime collaboration. This week our topic is the global dialing scheme. Fortunate to have Tyler Johnson, GDS expert, with us today to bring us up to speed, provide overview, and discuss benefits and challenges.
Tyler: Hi all, nice to hear all. He tried to use v/c but couldn't find the remote! New to this discussion, and wanted to ask if this group is a SIG. Yes, said Ben, we are a newly formed SIG, formed from the mega-conference and challenges to connect 323 endpoints and lack of cohesive dialing scheme. Decision made to formalize group to come up with best practices for the community. Hope is to come up with recommendations for H.323 and broader protocols like SIP.
Tyler said Walt asked him to speak about GDS. Tyler gave background and groups included in similar effort ten years ago. GDS - global dialing scheme was outcome. Great concise by Egon Veharen from SURFnet on Internet2 Commons page. Tyler drew distinction between dialing scheme and the implementation of that dialing scheme.
GDS was a dialing addressing scheme, protocol agnostic. Not really useful unless you implement something to support it.
Tyler explained the numbering scheme, like e164, hierarchical. Starts out with international access code 00 - except U.S. is outlyer. If you want to dial another country, there is ++ (your country's escape code, then your country code). When this was put together, telecos were quite regional.
Starts with 00 and that fully qualifies dialing scheme as a global to what follows after, the country code, followed by org prefix, followed by endpoint number. What that means, as example, in U.S. 001 then from that point downward in the dial scheme, implementation is up to the country operator. Tyler was part of the group who operated the U.S. national gatekeeper group. They aligned with e164 prefixes already in use. His Univ uses 919 followed by 962 - allocating that address space to his university. Any univ operating in a continuous block of numbers could get GDS in line with e164 numbers, reached by anyone anywhere in the world, but you were not confined to e164. It is quite possible to move beyond that and create non e164 space. Viewed important for those who didn't want their video tied to their phone numbers. This allowed for complete overlay of e164 for those running VOIP, but for those who didn't , they weren't required to do so. Created a hierarchy of the dial stream moving from left to right.
Tyler talked about how it was implemented. For 323, gatekeepers were used to parse dial stream and reroute calls to appropriate space. Global route set of gatekeepers, a couple in the US, one in UK, one in Aus. Pointed in a mesh for redundancy and speed. If someone in UK dialed 001 - global gatekeeper knew to send it to US. IN the US, it was also a cluster hosted at several universities, with knowledge of the gatekeepers under it. Call flow continued down the tree to find the lowest level gatekeeper host. Fortunate in implementation that they had low cost Radvision gatekeepers with strong routing capability, also quite easy to lookout into another zone to see if it had knowledge of the correct route for a particular number. Parallel dialing supported to allow creation of meshes. Fast and resilient. Could dial a number anywhere in the tree, wouldn't have to point to hierarchy in your parent gatekeeper, could also create a direct peering for often reached connections (TX AM used as example).
Tyler thinks it is useful. It is still around today, even though his university stopped hosting this several years ago. Tyler also doesn't think anyone tried to implement a SIP version. You could do it, you would have to use similar structure of SIP proxies, using SIO redirect. Not hard, but you would want to identify the correct SIO proxy for the job. He mentioned UNC RFP. Disappointed with interdomain proxies being built in. Lack of vision from the vendors. Why would anyone call outside our PBX?
He mentioned ways of making nice distribution with custom build, on a CD to share, then create route level and country level and domain level SIP proxies pointing to individual PBXs. Easy to replicate what was done with 323.
Downsides to GDS
Tyler described tree structure hierarchy. It needs administration at all levels for it to work. Seen as a drawback. They were successful because of a core set of individuals motivate to hold this structure for the community. Over time, without a home, the management of the infrastructure = atrophy set in. If you want to scale to world wide entities, you need a for pay system. This is a downside. Tyler doesn't have a good alternative or solution. He mentioned the work Bob Dixon and his group did.
Bob mentioned Internet2 Commons running the national and Commons gatekeeper. Still have dedicate professional people around the world, much like those who run the domain gatekeepers - it works without having a centralized staff.
Tyler mentioned the need for a fair amount of cooperation, need for a process in place, need to register the number ranges, gather IP addresses, set them up in router tables, and make sure pointers are correct over time.
Bob mentioned gatekeeper mailing list and notification if tables are out of date.
Walt? Said you could interconnect with public at large? But the GDS plan would have to be adopted. Tyler said not necessarily true, part of the goal, if you have address space and certain numbers assigned, you can bring those numbers into gateway thru PRI, anyone who dials will come into gateway, can register that same set of numbers with GDS tree. Then would have IP and e164 address space aligned. Both ring the same phone.
Walt? Asked how many actually used numbers used by their telephony network? Tyler said he didn't think many did. Folks using gateways did. Found this was implemented by 323 community - primarily a video over IP community. Not over SIP. More of a happenstance by involvement. There is an enforcement issue there. While you have a certain set of numbers assigned to your phone, and someone else in your department is operating a SIP proxy - same set on IP side that you own on the POTS (PSTN) side. If you really want to scale this globally, with malicious activity and lots at stake, need punative process and management. There is a scoping issue. What is the goal of the community? To connect R1 and all SEGPs? IF you want to scale to private sector, you need more control, more people, and funding mechanism.
Other downside, because hierarchical, it is not random access. If your university has certain numbers allocated in a block - the case for e164 and GDS. Less than ideal in Tyler's view. Should be random access like DHCP. No requirement for there to be a hierarchy. Has not seem a well structured system like that proposed.
Walt? The hierarchal system, when numbers are in a block, it simplifies the routing. Otherwise you would need 1:1 individual mapping. This is a scaling problem. Hierarchical systems are more doable.
Tyler said right now in SIP and h.323, there is authentication in the intradomain space, signaling between domains, need for security to make sure you receive legitmate requests. He thinks both are open to malicious flooding of the tree which would cause tree to forward requests on, quite deep. Vulnerable to attack. We could make protocols more secure. Or use session board controllers or smart routers with some mechanism you can utilize, but it does add to expense and complexity. Tyler does not know of an attack on GDS ever. Boot detection implement. All theoretical, but never happen. Bob may know of loop in GDS that caused a crash.
Simon asked about progress a couple of years ago? URI dialing. GDS was the stopgap until we could get to URI dialing. It works, it's been tested, solved problems really elegantly. User Interface is sticky wicket. Trying to push vendor to use alphanumeric (tlyler@unc.edu), but market has been slow to adapt. How long with telephone numbers be around? What is the timespan of the problem I am trying to solve? Short term or long term. He expected to get to URI dialing much quicker. Surprised how long telephone interface is sticking around. Admin of all of these touchscreen - iphone an ipad - when you have full QWERTY keyboard, the QE is not an obstical. Also having contact lists available cuts down.
Other obstical is generational and won't change until people die.
Simon mentioned mapping telephone numbers to URI. Walt says this takes e164 directory structure and providing backend process to achieve result.
Tyler said he is seeing some enum support . Simon dropped off. Bob Dixon mentioned migration off Radvison to GNU vision - due to cost and ability to do customized.
Simon is back. Walt asked if anyone knows of gatekeepers, h.323 centric, or done process using SIP proxy to query? Putting them at top of the tree. Tyler said you'd create a parallel infrastructure like GDS tree. Not difficult to do, Tyler thinks, but there could be institutional equipment limitations. You may find enterprise PBXs more limited. He does not see SIP intranetworking as the right way to do this. You would need to know to dial this person by SIP.
? said the same problems if you built this into enum tree. Has same problem. No need for hierarchy between proxies on SIP. Can use domain lookup. Not required, but beneficial.
Simon mentioned how enum could work to connect CISCO.com. Tyler agrees with the issue, same number verication issues as with other schemes. Which is easier to do/build overlay routing infrastructure or build it into enum. In the U.S, enum is problematic. Simon said same as in Europe.
Walt said enum discussion will be in a couple of weeks. Goal for today was to hear from Tyler. Ten minutes left in the meeting, good interaction.
Walt asked question -scheduling of the next meeting. He did additional e164 work, talked to Karen Mulberry at NewStar, owned by ATT, Verizon, Level3, Quest, etc - vendor neutral organization. Owned by telecos, but vendor neutral. Karen wrote part of the e164 addressing plan. As Tyler asked, who manages and controls. This idea, uses precips of e164 and creation of a global network service, something globally addressable. It would assign country code, which would give you access to managing the tree under it. Good thing is that it is recognized. Example of Australia and could have number routed by global pstns. Walt would like to ask Karen to give us an update, what is possible, what could be favorably received.
Simon mentioned UTP (878 space). This is a group who allocates the 87810 space. Walt asked Simon to provide an update at next meeting.
Walt will schedule the next meeting.
Walt said Internet2 meeting is in two weeks. How many on the call will be at SMM10? (Ben Fineman, Bob Dixon). Won't have critical AVCI mass in attendence . Ben said there is a side meeting scheduled - Tuesday, April 27th from 12:00 - 1:00 over lunch.
Walt asked Ben, if he brings a VOIP speaker phone, shall we do the next call at that time? Ben said he has an Adobe connect room, room mics to pump audio into Adobe connect, VOIP phone may not be able to support the room. Folks can listen thru Adobe and use the chat for comments.
Bob will be doing a collab tool session for The Commons at the same time.
Walt polled the group for next call? Ben, since it sounds like next meeting is a preso, lets do a separate call, and keep SMM10 f2f as a discussion meeting.
Walt asked when to schedule - Thursday, April 22 or Thursday, April 15th.
Next Thursday puts it back on the two week interval. Shooting for Thursday, April 15th at 2:00 PM Eastern time.
TO DO: Ben to send out invite for this meeting. Call adjourned at 12:00 PM.