About

All telecom fundamentals on SIP protocol, VOIP, RTP, RTCP knowledge, Technical Youtube Videos, Linux material, Android, SSCA certification information,the sip school videos.

Friday, 28 September 2012

RAS Signaling

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:
  • 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)
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).

Reactions:

1 comments:

I get actually enjoyed account your blog posts.

Post a Comment

Note: only a member of this blog may post a comment.

Page Navigation Widget