The Audio Video Communication Infrastructure Group is a forum for collaboration regarding audio/video communication infrastructure issues including dial plan, directory, scheduling, and related topics.
Dialing Plans
In this section we will enumerate the potential dialing plans that are available to our community, including how they work, how they would be implemented, and advantages/disadvantages.
Problems to Solve
- Adoption: target user base for GDS was higher education, did not become ubiquitous in higher ed, never got adoption in business, who stuck to E.164
- Compatibility: URI and IP works for a subset of cases, where as a solution like GDS works for legacy cases
Next Steps
At this time we have had a chance to discuss some options that may lead to a dial plan that has the ability to be more or less universal. While it may not be possible to ever have anything be able to connect to everything in the world, it would be beneficial if at least a limited dial plan was not a part of the problem.
In terms of devices that should be supported, the group has agreed that the list should include at least:
- Any device on the PSTN
- SIP Voice
- H.323 Video
- SIP Video
- Telepresence Video
It is understood that communicating between disparate systems will result in least common denominator communications and may require transcoding and/or signaling protocol gateways.
A global solution appears to require three architecture components, being:
- Dial Plan - this involves the defining digits/characters that would be dialed in order to complete a call. Options would include:
- URI dialing utilizing DNS
- GDS dialplan
- E.164 utilizing existing campus numbers
- E.164 with a combination of campus numbers and E.164 Global Service numbers assigned to Internet2 by the ITU
- Devices that would contain global route plans in order to simplify end user dial plans. Options include:
- Peer-to-Peer dialing with no route aggregation
- Gatekeeper peering
- SIP redirect server
- Cisco IME server
- MCU or bridge to support multiple connections and transcoding when needed. Options include:
- Use campus MCUs and register them by assigning and documenting an address from which ever dial plan is selected.
- Have Internet2 provide and support a central MCU for supporting interoperability.
From this list of components, one could define a matrix that would list the service connections between two dissimilar systems and specify which connections would be supported and which would not. It is my recommendation that the next steps include:
-
- Have a sub group define the matrix possibilities and from there specify supported combinations.
- Have the sub group go back to the larger group for approval
- Have the sub group do a deeper dig of the solutions that seem to support the most connectivity. For these options we would document:
- Architecture components including cost estimates.
- Issues that would have to be resolved.
- Pros and Cons of this solution.
- From this step, we would have the group come up with a recommended solution(s)
- Submit a written recommendation to Internet2 leadership.
If the group agrees that this is the path, I would like to schedule a track session for the Fall Members meeting in November. This would mean weekly meetings for the subgroup for the month of August.
Meetings
April 27th, 2010
Face to face, no minutes, sorry
Mailing list
To join the mailing list, visit https://mail.internet2.edu/wws/subrequest/avci or email sympa@internet2.edu with subject "subscribe avci"
Navigate space
 |
|