H.225 keep alive for cisco endpoints and MCUs

[hashimoto.kotaro]

Hi all,

As we can see on other posts, some Polycom endpoints send H.225 keep alive after every 2 hours during a call using TCP 1720 port, to confirm if farend participants are alive.

And if it fails (almost caused by firewall or router closing 1720 port because the port is idle), calls will be disconnected by Polycom endponts.

Regarding cisco endponts and MCUs, they do not send such packets as Polycom do.

That means cisco endpoints do not have function for keep alive.

But if there is VCS on the call, it sends keep alive packet (Call time to live) periodically.

Am I correct?

Kotaro

[Amlesh Sengar]

Hi Kotaro,

   You are correct, cisco endpoint does not send any keep alive messages on port 1720.  Once the call is setup,  endpoints send 

""498.48 H323Packet   PacketDump: Proto: H323, Name: H245  request : roundTripDelayRequest : , Direction: Outgoing, RemoteAddress: Unknown (socket id: 8) (socket id: 8), GroupEntity: CallId: 1, Time: 498480, Content: !!!<

498.48 H323Packet   value MultimediaSystemControlMessage ::= request : roundTripDelayRequest "":

every round trip delay has a sequence number and it matches the sequence number when it receives round trip delay response from far end.

In this way endpoint knows that the far end connection is active.

Hope this helps.

-Amlesh

[Dharmesh Nandoria]

Hi Kotaro,

Cisco EP use standard H323 Round trip delay request / responce proedure . During call every 30 sec  EP will send RTDR ( request) to peer EP unit to determine if the peer unit is alive , In responce peer EP will send RTDR(responce).

This will confirm that H245 communication is alive and call will continue .

If no responce for the request then system will understand that peer unit is not alive and call will get disconnected .

HTH .

Kind regards,

Dharmmesh

[Tomonori Taniguchi · Accepted solution]

Cisco Endpoint utilize roundTripDelayRequest/ roundTripDelayResponse message a part of H.245 MultimediaSystemControlMessage to keep alive H.245 TCP session during the call which will use for active call management.

The roundTripDelayRequest/roundTripDelayResponse design to messure the roundtrip delay messurement, but as this will use TCP and have request/response flow, works as keep alive for active H.245 TCP session between two devices which established during call setup.

The roundTripDelayRequest/roundTripDelayResponse is option to support (not mandatory feature to support for H.323), therefore if far end device doesn’t response on first roundTripDelayRequest that sent by local site, local site will continue to transmit roundTripDelayRequest message but will ignore session timeout even there is no response.

If far end response on the roundTripDelayRequest initially and then didn’t receive response during the call, local endpoint will initiate call termination.

[hashimoto.kotaro]

Thank you Amlesh, Dharmesh and Taniguchi-san.

I see that cisco endpoints use H.245 round trip delaly request / response to keep alive.

And it is originally desinged to  determine  the  round-trip  delay  between  two communicating  terminals.

Let me ask one more question.

According to the document I attached, the ports used for H.245 are as follows.

Are the ports used for round trip delay request / response alse included here?

From VCS-C to VCS-E

  TCP/2776 (Q931/H.245 signaling)

From internet to VCS-E (in DMZ)

  TCP/15000-19999 (H.245 signaling)

VCS-C to endpoints and MCU/GW

  TCP/5555-6555 (H.245 signaling)

Endpoints to VCS-C

  TCP/15000-19999 (H.245 signaling)

Between all endpoints and MCU/GW

  TCP/5555-6555 (H.245 signaling)

Kotaro

[Danny De Ridder]

Hello,

we do have a defect open to enable keepalives on the TCP connection to the well-known port 1720 [h225]. The defect is not viewable in toolkit yet. I'll make sure it becomes viewable soon. The fix consists of enabling TCP keepalive mechanism on the h225 socket.

[Tomonori Taniguchi]

Yes, roundtrip message exchange over H.245 TCP port that negotiated during call setup.

Please note that Endpoint won’t use all of port listed above in single call, just one of H.245 TCP port that has negotiated during call setup.