1K0-002 · Question #235
Videoconferencing sites, when defined as using a Gatekeeper, must successfully first communicate which of the following commands?
The correct answer is E. RRQ, RCF. See the full explanation below for the reasoning.
Question
Videoconferencing sites, when defined as using a Gatekeeper, must successfully first communicate which of the following commands?
Options
- AADM, CCF
- BARJ, ACF
- CRRQ, RRJ
- DRRQ, RGH
- ERRQ, RCF
How the community answered
(51 responses)- A14% (7)
- B4% (2)
- C2% (1)
- D6% (3)
- E75% (38)
Community Discussion
9The answer is E, RRQ and RCF. In H.323, before any videoconference call can happen through a Gatekeeper, the endpoint has to send a Registration Request (RRQ) to that Gatekeeper first, kind of like checking in at the front desk. The Gatekeeper then replies with a Registration Confirm (RCF) to say "yes, you are registered, you can make calls through me." That two-step handshake is what the question is testing. The other options trip people up because RRJ is a Registration Reject (so that would be a failure, not a success), and ARQ/ACF are for admission control which comes later in the call setup process, not at registration time. Once I drew out that flow on paper it clicked for me, hope it helps you too.
Good breakdown, just worth noting that the endpoint technically has to send a GRQ/GCF (Gatekeeper Request/Confirm) first to discover the gatekeeper before it can even send that RRQ, so the full pre-call sequence is actually three steps if auto-discovery is in play.
Saw this exact one, panicked, then remembered: register first (RRQ), get confirmed (RCF), then you're in.
RRQ goes out first, RCF comes back to confirm registration, so E.
That sequence is right, but the reason E holds up under elimination is that every other option either skips the admission step or reverses the order of those two messages, so knowing the flow is less about memorizing labels and more about understanding why the gatekeeper has to speak first.
Honestly my eye went straight to C first, because I saw RRQ and my brain autocompleted "registration" and moved on without reading the second message carefully. RRJ is a Registration Reject, which means the Gatekeeper turned the endpoint away, so that sequence describes a failed registration, not a successful one. What snapped me out of it was remembering the actual handshake flow: the endpoint sends an RRQ to the Gatekeeper, and the Gatekeeper replies with an RCF, Registration Confirm, to acknowledge the endpoint is now registered in the zone. That bilateral exchange is what puts the site on the Gatekeeper's radar and lets it participate in routed signaling and bandwidth control. E is the only option that shows both sides of a successful registration, request out and confirm back.
Solid breakdown, and it is worth drilling into why the RCF matters beyond just "you are registered," because it also carries the assigned alias list and any bandwidth ceiling the Gatekeeper wants to impose, so the endpoint actually configures itself from that confirm message rather than from anything it sent in the RRQ.
Registration sequence is RRQ first, rejection follows as RRJ, C is it.
Hey Dervla, close but RRJ is actually the rejection response, so that sequence would only apply if registration fails. Option E is correct because a successful registration goes RRQ then RCF (Registration Confirm), not RRJ.