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.
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 StepsAt 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.
Next Meeting: TBDH.323 Video, GDS: 0011 89 780 0199999
H.323 Video IP: 220.127.116.11, pin 0199999#
NEW CONNECTION METHOD Vidyo Desktop (PC/Mac, just need webcam and headphones): http://vidyo.internet2.edu/flex.html?roomdirect.html&key=G2nrrkHCNHxk
Web collaboration: http://internet2.acrobat.com/avci
Voice only: Dial +1-734-615-7474 or +1-866-411-0013, then enter 0117920#
May 13th, 2010Audio and slides recording
April 27th, 2010Face to face, no minutes, sorry
April 15th, 2010Minutes
April 9th, 2010Minutes
To join the mailing list, visit https://mail.internet2.edu/wws/subrequest/avci or email email@example.com with subject "subscribe avci"