Cloud

Asterisk’s configuration consists of numerous file sets. The dial plan, routing by number, is defined in extensions.conf.

Example of a simple extension

The dial plan follows the syntax as shown below:

[internal]

exten => _1XX,1,Dial(PJSIP/${EXTEN},30)
same => n,Hangup()

The structure of a block that matches each called number is as follows:

Native gRPC relies on HTTP/2, and there is ongoing discussion regarding HTTP/3 support.

It’s not obvious whether gRPC-Web supports HTTP/3. Given its purpose of browser support, it works not only on HTTP/2 but also on HTTP/1.1.

Asterisk is the most well-known open-source VoIP server. It serves as the core for an internal telephony network with SIP softphones and can be extended to integrate with the public switched telephone network (PSTN gateways) and computer telephony integration (CTI).

Preliminary knowledge

Before diving into the setup of Asterisk itself, it is effective to phase the deployment project and build it gradually. Here are the key phases:

Google Kubernetes Engine (GKE) can expose HTTPS services using Kubernetes Gateway/Ingress.
To expose non-HTTP services, you need to separately set up External TCP/UDP Network Load Balancing and configure routing to the Service.

While each GKE cluster can be shared among multiple gateways, TCP load balancer needs to be added separately for each port you want to expose.
Also, even for HTTPS services, manual configuration may be necessary to utilize additional GCP features.

If you set the front end of Google Kubernetes Engine to ingress, a GCP health check will be automatically created and passed. Otherwise, the backend service will not open even if the pod is working properly.

The default health check behavior that is automatically created is to check that you can HTTP GET / and get 200OK. If the backend is implemented to handle this request, it will pass a health check.