Tandberg MXP3000 no video after first session

rosensweigj · ‎11-13-2012

I have this strange case that is happening with my Tandberg MXP3000 running 9.1. I have been running some tests with it using an open source telepresence tool called opal. Initially after starting up the 3000 and connecting to it with a simple echo test, the connect works just fine. I am able to see the MXP3000's echo image. However if I disconnect and reconnect again all I get is a black screen.

If I reboot the system and try again the image comes back no problem. But after the first time it will start to fail again. What I've noticed is that on success the tandberg will show an incoming image of 1280x720 on the first successful connection. Past that it will show an existing H.264 stream and a bit rate, but no resolution will show up.

I know that I can telnet into these devices, but are there any logs or such that would help diagnose this? I tried using the syslog for tracking the call flwo but haven't noticed anything too strange. The only thing that caught my eye was the missing resolution and this cryptic message:

DEC_ReceiveDataTransfer: Transfercount 192 >= WindowSize 192, discarding data

It sounds like this might be my problem, but I don't really get why its discarding the data.

Any insight would be appreciated.

Thanks.

crisalex · ‎11-14-2012

Hi,

That sounds really interesting

I would suggest that you start with a basic set of logs + netwrok trace from both ends ( the first call attempt and the second one failing one ) and compare the setup messages and the Capabilities Set / Open logical channels

It might be the case that on the second call attempt one of the device it's trying to open a channel not supported by the other one ( just assuming now )

I would also recommend to adress this in a TAC SR since a deep logs review is necesarry . Please let me know once the SR it's opened and I'll follow it up internally

Regards

Cristian

mubakhta · ‎11-14-2012

Hi,

It is possible that this is a firewall issue where the firewall is only opening the channels once and not the second time.

Do you have any other working codec which is working as designed? Can you swap this codec and put it on the location of the working device to see if it still behaves in the same way?

As Cristian suggested, it would be a good practice to have a sniffer from the switch where the 3000 MXP is connected and then open a TAC Case. If you need general information, I can give you the ports which are used in the MXP devices which you can check on your firewall to make sure they're open:

For H.323:

Gatekeeper Discovery (RAS) Port 1719 UDP

Q.931 call Setup Port 1720 TCP

H.245(Static) Port Range 5555-5574 TCP

H.245(Dynamic) Port Range 11000-65535 TCP

Video Port Range 2326-2485 UDP

Audio Port Range 2326-2485 UDP

Data/FECC Port Range 2326-2485 UDP

For SIP:

SIP messages Port 5060 UDP/TCP

SIP messages Port 5061 TLS(TCP)

Video Port Range 2326-2485 UDP

Audio Port Range 2326-2485 UDP

Hope this helps.

Regards,

Mubashshir Akhtar

Thanks Mubashshir Akhtar

rosensweigj · ‎11-14-2012

Just to answer some of the questions. This test was performed in a private network over switched traffic. So its doubtful that the firewall is to blame here.

I actually did some analysis of the issue and I got the packet capture in the failure scenario. I was actually able to extract the H264 data from the packet capture and view the video that was not showing up in the end point. SO I know that data is getting sent and that a logical channel is opened.

I can open a TAC case. I don't remember where to do that though. Anyone got a link =D?

What would be best for me to include? I was thinking

#1 Packet capture covering working scenario and then immediately after the failure scenario

#2 Any logs from the tandberg?

Would appreciate advice here.

rosensweigj · ‎11-14-2012

Well it appears my company does not have a service contract with Cisco. So I can't open a TAC case anyways. We bought this unit used.

mubakhta · ‎11-14-2012

Okay. Great to hear that Joseph. So if you have the packet capture, maybe you can check the ports where the data is being received and you can track it down to check if it is coming back to the switch. Also it is important to confirm as to where the capture was taken from?

Was it taken from the switchport of the device who is the sender or the from the switchport of the device which is the receiver i.e MXP device. This would confirm if we're just seeing the packets sent out or also seeing them received on to your switch.

I think its easy to track it down and we now need to check if it is coming till the switch or not and then we would know that the problem is with the MXP and not with the network.

Also, I had asked earlier what is the far end device? Also have you confirmed that the video packets are H.264 and not something else like H.263+, etc.

Please confirm. If you dont have a contract its fine, we can try and help you out here as much as we can.

Regards,

Mubashshir Akhtar

Thanks Mubashshir Akhtar

Bryan Deaver · ‎11-15-2012

the 3000 system is pretty old. Trying to do 720p I could imagine that we may be seeing an issue with it being able to process the H264 stream depending on the level and the mbs that is coming in.

Now, I am not sure why it would work on the first call and not the second call if we assume that nothing else changes in the call parameters. Have you tried leaving the first call up for awhile to see if the issue happens?

I would suggest that you trying lowering the rate you are making the call to see if there is any dependency there.

Tomonori Taniguchi · ‎11-15-2012

Does packet length shows same on first successful call and 2^nd failure call?
The log message, MXP Endpoint is discarding receive the payload therefore it makes sense there is no video on screen (as MXP is not processing incoming video payload).

Possibility video channel didn’t close properly after first call termination?

rosensweigj · ‎12-04-2012

Sorry that I'm so late to reply to all of these. I was on vacation .

So I was able to figure out at least a piece of this puzzle. It turns out that the MCU unit was not setting some encoder fields like the protocol type or adjusting the MBPS like it needed to. Once I fixed these issues. The MXP 1700, 3000, and Edge all worked great. My guess is that these units were able to handle my faulty packets in the first try and then something didn't clean up correctly so subsequent tries failed.

But even with this change I am now seeing weird behavior with certain tandberg C20s! I have two C20s in my office. One of them is running 4.2.0 with HD enabled and the other is running 4.2.1 with no HD. They are both registered with the same gatekeeper and in the same subnet. However I see two different results from them.

#1 In the 4.2.0 case, video is JUST fine. I get two way audio and video.

#2 In the 4.2.1 case when I connect. I only get one way video and two way audio. When I take a look at the logs I see these error messages:

Dec 4 16:51:03 arm2 video2: 399.50 DEC_FSM-1 I: Decode Err: frame 1: ERROR 0x00009050|Corrupt Header|Concealment NOT Applied|H264D_ERR_IMPL_PICSIZE_BEYOND_ALLOCATED_MEM

Dec 4 16:51:03 arm2 video2: Sending FLUX intra req (sno=0)

Dec 4 16:51:03 arm2 video2: H264D_TI: IS_IDR_EXPECTED_ERROR

Dec 4 16:51:03 arm2 video2: 399.50 DEC_FSM-1 I: Decode Err: frame 2: (packets lost) ERROR 0x00008860|Corrupt Data|Concealment NOT Applied|H264D_ERR_IMPL_PPSUNAVAIL

Dec 4 16:51:03 arm2 video2: H264D_TI: IS_IDR_EXPECTED_ERROR

Dec 4 16:51:03 arm2 video2: 399.51 DEC_FSM-1 I: Decode Err: frame 3: ERROR 0x00008860|Corrupt Data|Concealment NOT Applied|H264D_ERR_IMPL_PPSUNAVAIL

Dec 4 16:51:03 arm2 video2: H264D_TI: IS_IDR_EXPECTED_ERROR

Dec 4 16:51:03 arm2 video2: 399.51 DEC_FSM-1 I: Decode Err: frame 4: ERROR 0x00008860|Corrupt Data|Concealment NOT Applied|H264D_ERR_IMPL_PPSUNAVAIL

Its very strange that one is working and the other is not. But it looks like the logs are more useful. Here is a link to the full log in case you want to see it:

https://www.box.com/s/d9i6yonhmpyot355odji