Re: [GnomeMeeting-list] Unexpected behavior between GM and RadVision MCU after MCU upgrade

["Kevin Oberman" <oberman es net>]

> Date: Sat, 28 Feb 2004 09:53:35 +1100
> From: Craig Southeren <craigs postincrement com>
> 
> On Fri, 27 Feb 2004 14:40:44 -0800
> "Kevin Oberman" <oberman es net> wrote:
> 
> =2E.deleted
> 
> > > 1) You changed the MCU, and the behaviour changed. GM did not change. S=
> o
> > > why do you think this is a GM problem?
> >=20
> > I don't think it's a GnomeMeeting problem, but ViaVideo works the same
> > as before while GnomeMeeting does not. So there is something in GM that
> > is interacting with the new MCU differently from other clients (or at
> > least, ViaVideo).
> 
> I have to disagree. The MCU is behaving differently, whereas GM has not
> changed. So the changed behaviour is in the MCU, not in GM.

Sorry. I am not blaming GM nor am I claiming that it has changed. I
meant that using GM to connect to the new MCU shows a changed behavior
while ViaVideo connected to the same MCU does not show a change in
behavior. I do not have any reason to believe that GM is doing anything
wrong, but some thing that is undesirable from my perspective.

> > > 2) The endpoint has no control over the video being sent to it - it can
> > > only display what the MCU sends.
> >
> > Clearly this is not the case as ViaVideo does display a screen with four
> > images in a 2x2 array while GM only displays a single image the size of
> > one quadrant in previous version.
> 
> As one of the authors of the OpenH323 protocol stack, trust me when I
> say that the client only displays the video that is sent to it.
> 
> This could be something as simple as the ViaVideo client using the H.263
> video codec, which allows larger video sizes than the H.261 codec
> supported by GM. Perhaps the new MCU does not support split screen for
> H.261 endpoints?

Now we are getting somewhere. This is just what I was looking for. I've
looked at debug logs for connects to both the old and new MCUs and see
the following for the new MCU:
 H323    Started receiving logical channel: H.261-QCIF <2>
 RTP     First data: ver=2 pt=PCMA psz=160 m=0 x=0 seq=58609 ts=0 src=401727233 ccnt=0
 RTP     Receive statistics:  packets=101 octets=16160 lost=0 tooLate=0 order=0 avgTime=19 maxTime=36 minTime=0 jitter=20 maxJitter=21
 H323RTP Receive H.261 thread started.
 H323RTP Transmit G.711-uLaw-64k thread started: rate=240 time=30ms size=30*8=240
 H323RTP Transmit H.261 thread started: rate=0 time=0ms size=1*2000=2000
 RTP     First data: ver=2 pt=H261 psz=1184 m=0 x=0 seq=12764 ts=218665302 src=478721 ccnt=0

The old MCU shows:
 H323    Started receiving logical channel: H.261-CIF <9>
 H323RTP Receive H.261 thread started.
 H323RTP Transmit G.711-uLaw-64k thread started: rate=240 time=30ms size=30*8=240
 H323RTP Transmit H.261 thread started: rate=0 time=0ms size=1*2000=2000
 RTP     First data: ver=2 pt=H261 psz=1196 m=0 x=0 seq=20160 ts=2948509420 src=258513665 ccnt=0
 RTP     First data: ver=2 pt=PCMA psz=480 m=0 x=0 seq=3383 ts=0 src=398768641 ccnt=0

So the old MCU is sending CIF while the new is doing QCIF. The question
is why? I presume it's something in the negotiation of the link, but I
don't know quite what to look for. I can set he debug level higher and
get all of the details, but it would be great to have some idea what to
look for. --debug=5 generates a LOT of stuff, most of which is not too
meaningful to me.

Again, thanks so much for your comments. At least I'm now moving in the
right direction.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman es net			Phone: +1 510 486-8634