PSU VoIPI'm answering this comment-question on the main blog because it's a new topic; also, because I'd be glad to hear more about this topic.
Richard Rauscher said:Bill, i have a question that's been burning inside for a while -- why do we implement separate networks for voice and data? Why not just use 802.1p/q and DiffServ?
I've been through three VoIP implementations, 2 with Cisco Phones & Call Manager and 1 with 3COM NBX's. I've always kept the phones and data on the same network with no insurmountable problems.
thanks!
The answer to this question is entirely non-technical. There may be technical reasons also, but I believe the non-technical reason fully covers it. (Note: this answer reflects my point of view from working in operations and my understanding of decisions made before my employment in the department even began. It is neither comprehensive nor authoritative.)
Cisco VoIP service offered by TNS at University Park is fully managed by TNS -- phone, jack, cabling, LAN equipment, everything. TNS also offers fully-managed data LANs but departments are not required to subscribe to this management for their data networks, and many do not. The simplicity of having one "voice network" infrastructure, as opposed to some of the infrastructure being stand-alone voice and some being integrated with a TNS-managed data LAN, is a significant factor in service management.
Data and voice packets traverse the same core network--there is not a separate physical core network for VoIP. The separation in the core is entirely logical (IP addressing/subnetting and access controls).
Richard (and others): What functionality could be gained, in Penn State's situation, by creating more of a converged data/voice network? Thanks for your question, and I look forward to hearing more.
That's a really straightforward, clear explanation. So much so, that I never would have thought to say it that way. I've heard others say it as, "{insert your alternate implementation here} doesn't scale."
What you've done is quite nimbly bypassed that argument and simply explained why it doesn't scale and why it benefits our customers to do it that way.
Now I can see that a place that was organized, or funded differently might be in just the opposite situation. I think that might be what you meant when you said the answer is entirely non-technical.
Thanks.
From my experience with Cisco's AVVID solution (admittedly three years old at this point), Cisco's architecture seemed geared towards the expectation that voice and data were on a common wire/layer two network. Specifically, the VT advantage was integrated such that the PC with the camera attached to it must be daisy-chained off the phone. (I believe that the phone talked to the PC to turn on the VT advantage software through this mechanism). Again, this was three years ago and I'm sure that some smart person has figured out how to get the video to work without having the PC attached to the phone physically.
BTW, what is PSU's opinion/plans for permit internal video conferencing integrated with AVVID? I know we have Breeze but it's not quite the same.
I don't know of any plans to do Cisco AVVID video. Besides Breeze (Adobe Connect) there's an H.323 gatekeeper available for coordinating desktop and conference room video calls as well as a soon-to-be-upgraded MCU (video conference bridge). I use an H.323 client on my Macbook Pro as often as weekly to participate in video calls/meetings. Interoperability with Polycom systems around the university is excellent. See my blog post about the H.323/SIP Xmeeting client for Mac.
Unless I'm misreading Cisco's data sheet for Video Advantage, it looks like the application will only work within the AVVID environment. That would prevent interoperability with the existing Polycom videoconference room systems and any other external system. Seems to be a large investment for a fairly small benefit.