Tomonori Taniguchi написал(а):
Are you sure you getting ping reply from 4500 series MCU while packet size set to 104 bytes?
Due to kernel limitation (limited to save the box from failing over), the max size of ping response that 4500 series MCU support should be 76 byte payload…
=========================================================

Yes, I am shure. I get ping from Cisco router and its size parameter set full packet size not only payload size. From OS ping is absolutely the same:

WINDOWS>ping 10.50.2.8 -l 76

Pinging 10.50.2.8 with 76 bytes of data:

Reply from 10.50.2.8: bytes=76 time=2ms TTL=255

Reply from 10.50.2.8: bytes=76 time=3ms TTL=255

Reply from 10.50.2.8: bytes=76 time=3ms TTL=255

Reply from 10.50.2.8: bytes=76 time=1ms TTL=255

Ping statistics for 10.50.2.8:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 3ms, Average = 2ms

>ping 10.50.2.8 -l 77

Pinging 10.50.2.8 with 77 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 10.50.2.8:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

> Yes, I am shure. I get ping from Cisco router and its size parameter set full packet size not only payload size.

> From OS ping is absolutely the same:

OK, then it makes sense why you see ping success with size=104.

IOS able to specify data size which include some of overhead packet length not pure ping data length.

Ping from Router/Switch run IOS with size option parameter.

=============================

Size = 104

Overall frame length: 118 bytes

Ping data length: 76 bytes

Size = 105

Overall frame length: 119 bytes

Ping data length: 77 bytes

=============================

So overall same result that 4500 series MCU has kernel level limitation for reply the ping request depend on ping data length as I explained above.

Anthony Thomson написал(а):
Interestingly enough, I tried this on my own, and ICMP echoes over 76 bytes fail to my 4505 (even smaller than yours!).  I don't know what is causing this behavior.  (Edit: answer to this from Tomonori above!!)

See my answer to Tomonori above.

Anthony Thomson написал(а):
You probably need to look more at the usual suspects: traffic congestion, and speed/duplex mismatches a long the path that video takes. 

See my answer to Tomonori below.

Thank you all for answers!

I didn't tell but my participants connect throw WAN links (L2 VPN by ISP network). And I see packet loss on MCU.

I am going to present a complete picture of my issue before I make a request to my ISP.

On MCU I have see Packet errors and Frame errors, what is the difference between them?

FUR message what is it?

> On MCU I have see Packet errors and Frame errors, what is the difference between them?

The packet errors are reported when there is a problem with error in receiving packets, for example, a discontinuation of a sequence or incorrect RTP information (e.g. a payload has changed mid-stream but the endpoint hasn't sent a keyframe), etc.

Frame errors are reported when the actual frame is suffering either due to packet loss or actual video errors. So this will most often trigger FURs if MCU is unable to recover.

> FUR message what is it?

FUR is "Fast Video Update". Device sends this message for requesting new key frame from far end device.

When there are number of packet loss on video stream, Endpoint may not decode incoming video payload because of already lose several previous update video payload/frame.

To recover it, Endpoint request new key frame which doesn't require previous video frame to decode the picture.

Here is a little more explanation about FUR.

For H.323 call, you should see H.245 Miscellaneous Command message with “videoFastUpdatePicture :” information.

For example:

=====================================================================

sysl H245LO-1 Incoming MESSAGE START

value MultimediaSystemControlMessage ::= command : miscellaneousCommand :

{

logicalChannelNumber 2,

type videoFastUpdatePicture : NULL

=====================================================================

For SIP call, you should see SIP INFO message with “picture_fast_update” information.

For example:

=====================================================================

CSeq: 108 INFO

Contact: <127.0.0.1:5071>

From: <>user1@demo.com>;tag=24a8c7987aeba7c8

To: <>tuser2@demo.com>;tag=a6d6c9c194ed9dc9

Max-Forwards: 68

Content-Type: application/media_control+xml

Content-Length: 168

=====================================================================

Where you can see this messages? Any log file, from data port, by telnet?

I will try to watch this during the conference.

On MCU, you should see the FUR message in Logs > H.323/SIP log (Enable H323/SIP logging).

Please note this log on Web GUI able to display latest 2000 entries.

You may monitor FUR by using VCS diagnostic log as well.

Under Maintenance > Diagnostics > Diagnostic logging, change Network log level to "Debug" and click "Start new log".

After your conference, click "Stop logging" then "Download log" to download log file (text base).

Probably this will be more recommended method as allow to capture log during your conference call.

Thank you Tomonori for your detailed response! Now I know a little more about MCU working.

Can I see the RTCP stats of a call somewhere in the logs / debug info of the MCU?