Comments on: More on the HD Communication Summit http://gipscorp.com/blog/2009/05/26/more-on-the-hd-communication-summit/ The GIPS Blog Tue, 02 Feb 2010 01:09:43 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Michael Graves http://gipscorp.com/blog/2009/05/26/more-on-the-hd-communication-summit/comment-page-1/#comment-3095 Michael Graves Wed, 27 May 2009 14:00:05 +0000 http://gipscorp.com/blog/?p=841#comment-3095 One last thought...G.722 is at least as appropriate as G.711, which as we all know is widely deployed over IP. One last thought…G.722 is at least as appropriate as G.711, which as we all know is widely deployed over IP.

]]> By: Michael Graves http://gipscorp.com/blog/2009/05/26/more-on-the-hd-communication-summit/comment-page-1/#comment-3094 Michael Graves Wed, 27 May 2009 13:58:57 +0000 http://gipscorp.com/blog/?p=841#comment-3094 While some, as yourselves, may feel that G.722 is inappropriate on IP networks my experience with it has been good. The VoIP Users Conference (http://www.voipusersconference.org/) is a weekly gathering of telecom sys admins, VARs and end-users that has been holding a weekly one hour conference call. For the past several month we have been using the ZipDX (http://www.zipdx.com) wideband (G.722) bridge as well as the Talkshoe (http://www.talkshoe.com)narrowband (G.711) bridge. We've had as many as 30 participants on the G.722 bridge, which is primarily accessible via SIP URI. We've has no serious issues of the nature you describe. Our regular members join using a variety of connection schemes, from DSL, Cable even wireless ISPs. Those problems that we have experienced are things that would be a problem for any sort of IP network, like excessive latency and poor/incompatible protocol/codec implementations. Please feel free to you us any Friday at 12 noon EDT. Connect details are at the URL given above. While some, as yourselves, may feel that G.722 is inappropriate on IP networks my experience with it has been good. The VoIP Users Conference (http://www.voipusersconference.org/) is a weekly gathering of telecom sys admins, VARs and end-users that has been holding a weekly one hour conference call. For the past several month we have been using the ZipDX (http://www.zipdx.com) wideband (G.722) bridge as well as the Talkshoe (http://www.talkshoe.com)narrowband (G.711) bridge.

We’ve had as many as 30 participants on the G.722 bridge, which is primarily accessible via SIP URI. We’ve has no serious issues of the nature you describe. Our regular members join using a variety of connection schemes, from DSL, Cable even wireless ISPs. Those problems that we have experienced are things that would be a problem for any sort of IP network, like excessive latency and poor/incompatible protocol/codec implementations.

Please feel free to you us any Friday at 12 noon EDT. Connect details are at the URL given above.

]]> By: Brett http://gipscorp.com/blog/2009/05/26/more-on-the-hd-communication-summit/comment-page-1/#comment-3052 Brett Tue, 26 May 2009 18:35:17 +0000 http://gipscorp.com/blog/?p=841#comment-3052 Is it not true that G.722--and all such codecs trying to squeeze ever-growing amounts of data through pipes that are not growing at the same pace--is it not true that all of them are terribly susceptible to packet loss? Our experience at IPeak Networks has shown that the more powerful the codec, the more pronounced the damage when even a small measure of packet loss hits. We have also observed that when it comes to best efforts IP networks (and it is clear enough that everybody wants to use best efforts networks) packet loss is a constant if unpredictable threat. By now you'll have guessed that IPeak Networks is in the business of reducing packet loss (over best efforts networks in particular) but we are very interested to know if others would agree with our assessment of the situation. It seems that the legacy methods for dealing with packet loss do worse harm to wideband, HD, hi-rez and you name it media streams that the market is demanding. FEC and block encoding add latency, a no-no in the voice world and a travesty in real-time applications like video conferencing. We just can't see any affordable way to get performance and quality out of a best efforts network without actually attacking packet loss right in the telecomms stack, the way we do it. Speaking of videoconferencing, we note that there's a good reason telepresence being restricted to custom rooms at this point. Yes, the lighting and the arrangements of cameras and microphones relative to people at the table is an importqant part of telepresence, but the other importsnt part is the fact that the high definition audio and video can't be trusted to the public Internet. It takes serious big and seriously expensive pipes to move that kind of data around and keep it together. Is it not true that G.722–and all such codecs trying to squeeze ever-growing amounts of data through pipes that are not growing at the same pace–is it not true that all of them are terribly susceptible to packet loss? Our experience at IPeak Networks has shown that the more powerful the codec, the more pronounced the damage when even a small measure of packet loss hits. We have also observed that when it comes to best efforts IP networks (and it is clear enough that everybody wants to use best efforts networks) packet loss is a constant if unpredictable threat.
By now you’ll have guessed that IPeak Networks is in the business of reducing packet loss (over best efforts networks in particular) but we are very interested to know if others would agree with our assessment of the situation. It seems that the legacy methods for dealing with packet loss do worse harm to wideband, HD, hi-rez and you name it media streams that the market is demanding. FEC and block encoding add latency, a no-no in the voice world and a travesty in real-time applications like video conferencing. We just can’t see any affordable way to get performance and quality out of a best efforts network without actually attacking packet loss right in the telecomms stack, the way we do it.
Speaking of videoconferencing, we note that there’s a good reason telepresence being restricted to custom rooms at this point. Yes, the lighting and the arrangements of cameras and microphones relative to people at the table is an importqant part of telepresence, but the other importsnt part is the fact that the high definition audio and video can’t be trusted to the public Internet. It takes serious big and seriously expensive pipes to move that kind of data around and keep it together.

]]>