Codian 4210 to Polycom VS4000

[AceVid]

Hi smart people,

Having a problem with connecting to a Polycom VS4000. The Codian (1.3 rev.1.3) is running the latest greatest, as well as the Polycom(6.0.5 FX ). Anywhere from 2 to about 5 minutes after being connected the Codian drops the call and reports an h.245 socket error.

I'm pretty sure it's network related...because I can have the Codian public test bridge connect to this VS4000 no problems. PtP to this VS4000 is fine. Another interesting thing is that this endpoint sits on the same subnet as a couple Tandberg 6000's that I have no problem connecting to with the Codian.

Love my 4210, but I often see h.245 socket errors going to some sites.

Thank in advance...

[trapehzoid]

Hi smart people,

Having a problem with connecting to a Polycom VS4000. The Codian (1.3 rev.1.3) is running the latest greatest, as well as the Polycom(6.0.5 FX ). Anywhere from 2 to about 5 minutes after being connected the Codian drops the call and reports an h.245 socket error.

I'm pretty sure it's network related...because I can have the Codian public test bridge connect to this VS4000 no problems. PtP to this VS4000 is fine. Another interesting thing is that this endpoint sits on the same subnet as a couple Tandberg 6000's that I have no problem connecting to with the Codian.

Love my 4210, but I often see h.245 socket errors going to some sites.

Thank in advance...


is there a firewall anywhere in this mix? could be the control channel timing out. This is a common problem with many firewall setups where they think the control channel is an old connection due to no activity and will close it. Some codecs use tricks to keep traffic on the channel to keep it active.

[senthil]

Hi
Seems to be there is a problem in your vs4000.Use telnet trace with the vs4000 and make a call to the codian mcu and find out what report trace is giving. Make sure vs4000 not selected firewall ports? and you are using any gatekeeper?.

Senthil

[AceVid]

Another telling thing is that this site also has a Tandberg MCU. When the Codian and Tandberg are cascaded and the VS4000 attached to the Tandberg MCU, the VS4000 stays in the call no problem. No Gatekeeper in the mix.

[Kevin]

Hi AceVid

h.245 socket errors simply means the MCU has lost network connectivity to the endpoint in question. (In the next release of software we have changed the error code to something more user friendly...).

What is the network infrastructure between the endpoint and the MCU - are there firewalls in the way?

Thanks
Kevin

[AceVid]

I lost my Polycom telnet commands cheat sheet. Do you happen to know which command will filter on what I want to see. I know usually it spits everything at you. Also, I need to know what to set the capture filter to on the Codian (is detailed trace overkill?) and if H.323 logging should be turned on and captured?
Once again, thank you for your offer of assistance and forgive the delay in my response.

[trapehzoid]

I'm telling you.. check your firewall. I garuntee you the problem is the control channel timing out. It doesn't fail on the tandberg because newer endpoint software put extra traffic on the control channel just so it doesn't close. PIX firewalls are notorious for this.

There is a TCP timeout variable. I think if you are using fixup the commands change. here's an example for a unit using fixup I believe

http://www.njedge.net/techsection/firewall-codecs.html

This is discussed often, I'm sure a search would find the exact commands.

[Sean Lessman]

It doesn't fail on the tandberg because newer endpoint software put extra traffic on the control channel just so it doesn't close. PIX firewalls are notorious for this..

Correct we put some specific 'traffic' on these channels to ensure the H.245 channel stays open.

Sean

[AceVid]

Thanks..this doc should prove helpful. I'm in a real fun situation <insert sarcasm> I have no eyes into or control of the LAN my systems sit on nor the Firewall or WAN devices. The Network guys here look at us video folks with a mixture of distrust, scorn and a healthy pinch of "why don't you go away??" hahaha

[Gary Miyakawa]

Glad to see you are working in a "normal" environment ! ;)

[trapehzoid]

Thanks..this doc should prove helpful. I'm in a real fun situation <insert sarcasm> I have no eyes into or control of the LAN my systems sit on nor the Firewall or WAN devices. The Network guys here look at us video folks with a mixture of distrust, scorn and a healthy pinch of "why don't you go away??" hahaha

tell them to turn on logging in the firewall and they'll see the ports being closed

[AceVid]

Got a log from the PIX....wow! getting that was like pulling teeth..anyone wanna see the log? Also have the event log from the Codian and H.323 log from the Codian..working on things from the Polycom side.

Thanks

[AceVid]

Well...had the Firewall guys change the timeouts for H.323 and H.225 to 10 hours...

Connected at 14:26, disconnected at 14:30
H.245 socket error

....issue still isn't resolved...

[AceVid]

Hi smart people,
I was wondering if anyone knew a baseline setup of Ethereal that will result in the smallest, yet most relevant trace relating to H.323 calls. I confess, I'm a Ethereal noob, so filtering correctly is somewhat confusing.


Specifically, I'm trying to diagnose some H.245 socket errors (most likey being caused by a firewall or packet shaper) occuring between my Codian 4210 and off-net Viewstations.

[Kevin]

Hi Acevid,

I emailed you some instructions to get you started.

Keep us posted.

Kevin

[trapehzoid]

first.. make sure you put the packet sniffer where its going to get the traffic. That means on a monitor port, a hub in line, or use an ethernet tap.

Then start the capture, and then run your call. Don't worry about the ethereal settings at all except to make sure you are capturing the right ethernet interface. You'll see the packet counters going up if you did it right.

After the call fails, stop the capture.

Then simply enter a display filter to only show packets you want. simpliest is simply isolate traffic to/from your codec. If your codec is 64.32.22.13 put in the filter

ip.addr == 64.32.22.13

since you are looking at the control channels, I'd simply add a expression that only shows tcp traffic (so that will hide all those media packets) so just use AND tcp

ip.addr == 64.32.22.13 and tcp

That's the simplest.. then find the control sessions and you can further filter there if you want.. but the above is probably enough to get most of the trash out of the way.

The key to filtering is.. don't go overboard :)

[AceVid]

K..That was a big help...how would I save the filtered trace? I'm looking to make it small enough to email...right now it's huge..heh.

Thanks in advance

[trapehzoid]

K..That was a big help...how would I save the filtered trace? I'm looking to make it small enough to email...right now it's huge..heh.

Thanks in advance

When you do a save, you can choose to save all packets, or just the displayed ones. By filtering, you can just say save displayed, and that will save only the ones shown by your filter

[AceVid]

Thank you very much, I appreciate your time, assistance and interest. Your replies have been very helpful. Now I'm off to share the traces with Codian and the dreaded local network admins...