Endpoints use the RAS protocol in order to communicate with a
gatekeeper. Likewise, gatekeepers use RAS to communicate with peer
gatekeepers. RAS is a fairly simple protocol composed of just a few
messages. Namely:
Figure 4 - A high-level communication exchange between two endpoints (EP) and two gatekeepers (GK)
When an endpoint is powered on, it will generally send a gatekeeper
request (GRQ) message to "discover" gatekeepers that are willing to
provide service. Gatekeepers will then respond with a gatekeeper confirm
(GCF) and the endpoint will then select a gatekeeper to work with.
Alternatively, it is possible that a gatekeeper has been predefined in
the system’s administrative setup so there is no need for the endpoint
to discover one.
Once the endpoint determines the gatekeeper to work with, it will try to register with the gatekeeper by sending a registration request (RRQ), to which the gatekeeper responds with a registration confirm (RCF). At this point, the endpoint is known to the network and can make and place calls.
When an endpoint wishes to place a call, it will send an admission request (ARQ) to the gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another gatekeeper, or by querying some other network service) and return the address of the remote endpoint in the admission confirm message (ACF). The endpoint can then place the call.
Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to get permission to accept the incoming call. This is necessary, for example, to authenticate the calling device or to ensure that there is available bandwidth for the call.
Figure 4 depicts a high-level communication exchange between two endpoints (EP) and two gatekeepers (GK).
- Gatekeeper request, reject, and confirm messages (GRx)
- Registration request, reject, and confirm messages (RRx)
- Unregister request, reject, and confirm messages (URx)
- Admission request, reject, and confirm messages (ARx)
- Bandwidth request, reject, and confirm message (BRx)
- Disengage request, reject, and confirm (DRx)
- Location request, reject, and confirm messages (LRx)
- Info request, ack, nack, and response (IRx)
- Nonstandard message
- Unknown message response
- Request in progress (RIP)
- Resource availability indication and confirm (RAx)
- Service control indication and response (SCx)
- Admission confirm sequence (ACS)
Once the endpoint determines the gatekeeper to work with, it will try to register with the gatekeeper by sending a registration request (RRQ), to which the gatekeeper responds with a registration confirm (RCF). At this point, the endpoint is known to the network and can make and place calls.
When an endpoint wishes to place a call, it will send an admission request (ARQ) to the gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another gatekeeper, or by querying some other network service) and return the address of the remote endpoint in the admission confirm message (ACF). The endpoint can then place the call.
Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to get permission to accept the incoming call. This is necessary, for example, to authenticate the calling device or to ensure that there is available bandwidth for the call.
Figure 4 depicts a high-level communication exchange between two endpoints (EP) and two gatekeepers (GK).
1 comments:
I get actually enjoyed account your blog posts.
Post a Comment
Note: only a member of this blog may post a comment.