Low quality IP link in one direction

[turbo]

I hope VTC community can forgive me for these less than exciting question, but as I am discovering now vtc is not as simple as it seemed first.

I am trying to achieve acceptible video and sound quality with Tandberg 880 over IP (2Mb SDSL). My test call to another member of this board (thanks Cedi) showed good quality on his side and bad quality on my side. The image quality was very poor and the voice was breaking up.

Tandberg 880 is connected on NAT and the router has all ports forwarded to the codec's IP address.

Because the outgoing quality was good and the other end didn't have problems with other calls, I suspect that my router settings might be letting me down. Have you come across this problem?

Stas

[Entropy3XD]

The diagnostics menu is a good place to start. Place your video call, then go to CALL STATUS under the diagnostics menu. It is there that you can see information in regard to your call, such as video bandwidth, audio bandwidth, protocols, and packet loss. This screen gives excellent information on the call and how it was negotiated between the two codecs. You do not mention the speed of your test calls, or information about the far end (ie. network, equipment used, software versions).

Never use hubs, always switches. If you are new to IP the reason why can be a topic all it's own. I assume you are using a home router with a built in switch. Make sure all of your firmware is up to date on the router and software is up to date on the Tandberg. Auto-negotiation can be flaky in the VTC world, so it is recommended that you hard set the switch and the codec. Most people set it to 100/FULL, but in playing around with the settings you may find different results.

In doing VTC over the public internet, you are sometimes at the mercy of the rest of the world. The route the packets take from point A to point B can make a difference. Use traceroute commands to see the hops from your site to the far end and check for bottlenecks.

With the latest codecs from the major manufacturers you will probably find support for the H.264 algorithm. You didn't mention the software version you have, so I can't tell you if your codec supports it. This allows for greater data compression resulting in better video with less bandwidth. I highly recommend using this if your codec supports it. It works best if supported by both codecs. The same goes for audio and I usually set mine to G.728 for 16k of audio when saving bandwidth. You can find the explanations for Tandbergs algorithms on pages 140 and 141 of the 880MXP user manual, found here: .

http://www.tandbergusa.com/collateral/user_manuals/TANDBERG_990_880_770_MXP_user_man.pdf

For manuals on other Tandberg products, you can go to www.tandberg.net. Go to SUPPORT at the top of the page, then DOCUMENTATION. Just find your model.

Let us know what you find out.

[trapehzoid]

Auto-negotiation can be flaky in the VTC world

That is a false statement. The issue is Video will SHOW negotiation problems while most data connections will suffer the same issues but it will not be as obvious to the user.. as they don't recognize the performance issues. Video is less TOLERABLE to poor network conditions due to the real time and UDP nature of RTP media.

The real fact is video codecs have no more negotiation problems then any other piece of network gear. Just people in video are more aware of it. The same people who complain about their codec negotiating and say 'all ports must be forced' probably have the same issue with their PCs and don't say the PCs must be forced :)

On topic tho.. I bet the issue was probably the far-end oversubscribing his line.. or just simple internet connectivy issues. Having one way degragated performance is nothing new or strange at all.

If you can't auto-negotiate.. I bet if you toss your switch out for another.. it would work :)

[turbo]

Thank you so much for advice. It is very frustrating, since every time the other end reports "amazing" quality and I see a cheap webcam image.
Maybe it's something to do with the router setting. We are connected to a 2Mb SDSL line though a router. It uses NAT and all ports are forwarded to the internal IP of the vc system.
I am using Tandberg 880 with E2 software. Maintainance contract expired, so no software update possible. As a small educational project we received this unit as a donation and cannot afford expensive Tandberg contract.
When connected to the Tandberg test number the system reports packet loss of about between 3 and 6, both audio and video. I just changed the setting from Auto to 100/Full, but without any effect. The system does show H264, but it doesn's seem to make a difference. Below are the connection screen (with the Tandberg test IP number)

Call Status, video call
Call
In 1 Out 1
Connected: connected
Number: -Out- 12.35.161.140
Call Rate: 768.0 kbps
Video Mode: H263+ H263+
Duo Video: None None
Audio Mode: G722 G722
Data Ch. Protocol: FECC FECC
Data Channel: Off Off
Audio Rate: 64.0 64.0
Video Rate: 306.7 707.6
Duo Video Rate: 0.0 0.0
Data Rate: 0.0 0.0
Video Resolution: sif isif
Encryption: Off Off
Check Code: 0000000000000000
Microphone: On
Video Source: main cam, NTSC

LAN Status
In 1 Out 1
Audio Packet Loss: 2.0 0.0
Video Packet Loss: 4.7 0.0
Data Packet Loss: 0.0 0.0
Audio Jitter: 0 0
Video Jitter: 0 0

I connected to Yale University lately and the other end reported quality so good they couldn't believe we used ordinary internet. I could hardly see them. Can anyone help please?!

[Entropy3XD]

That is a false statement. The issue is Video will SHOW negotiation problems while most data connections will suffer the same issues but it will not be as obvious to the user.. as they don't recognize the performance issues. Video is less TOLERABLE to poor network conditions due to the real time and UDP nature of RTP media.

The real fact is video codecs have no more negotiation problems then any other piece of network gear. Just people in video are more aware of it. The same people who complain about their codec negotiating and say 'all ports must be forced' probably have the same issue with their PCs and don't say the PCs must be forced :)

On topic tho.. I bet the issue was probably the far-end oversubscribing his line.. or just simple internet connectivy issues. Having one way degragated performance is nothing new or strange at all.

If you can't auto-negotiate.. I bet if you toss your switch out for another.. it would work :)
Not necessarily a false statement, as you mentioned yourself that codecs can have auto negotiation problems just like other network equipment, but you are correct and point well taken. The bottom line, however, is if you have auto negotiation problems with Ethernet, regardless of the equipment, you should hard set the port and the device. You could toss out the switch for another, but I would prefer to save the money by taking a few minutes to set the ports. If administration is an issue however, and auto negotion is a must, then finding a switch that fits your needs would be prefered and I would agree with you on finding another switch.

[turbo]

Not necessarily a false statement, as you mentioned yourself that codecs can have auto negotiation problems just like other network equipment, but you are correct and point well taken. The bottom line, however, is if you have auto negotiation problems with Ethernet, regardless of the equipment, you should hard set the port and the device. You could toss out the switch for another, but I would prefer to save the money by taking a few minutes to set the ports. If administration is an issue however, and auto negotion is a must, then finding a switch that fits your needs would be prefered and I would agree with you on finding another switch.

do you mean NAT settings on the router or the IP settings on the codec? if it's NAT, then isn't forwarding all posts to the codec better then just a few?

it looks like every time only 'in' direction shows packet loss. i doubt it's the other end's problem. i wonder what is exceptable packet loss?

[cedi]

Hi Turbo.

One thing you could try is putting the codec directly to the internet. So there is no router or firewall in between.

If in that case same problems occur, then it either your SDSL link or the codec.
Maybe you could borrow another codec somewhere and test it.
If you have any webcam available you could install trial SW of PVX or vPoint??? from VCON.

This way you'll find out if it is the codec cousing troubles.

Good luck,
Cedi