General SIP trunk parameters
Última actualización
Última actualización
As anticipated, PJSIP is the module that implements SIP for this type of trunks. But also, the syntax chosen to generate the configuration at the Asterisk level is pjsip wizard.
In addition to the link cited from the official Asterisk documentation, we share the following link which is of great interest to learn more about the parameters available within the pjsip wizard.
The following scenarios are proposed for OMniLeads instances and their connection to a SIP provider terminating to the PSTN.
In this scenario, we have the possibility of the application deployed on a cloud provider going out to the Internet through a gateway. Also, the deployment of an on-premise instance in a corporate LAN is affected by NAT, in which the Internet is accessed through the company router, using a public IP to perform the NAT on the packets generated from OMniLeads to the SIP provider.
Here, Asterisk uses UDP port 5060, since it is the port that implements the fact of notifying in the REQUESTs or SIP RESPONSES the public IP with which the packets will go out to the outside and arrive at the other end of the SIP trunk. This adaptation of the mentioned packets is done at the SIP level (signaling) and SDP (media negotiation). Therefore, the external recipient of the packets does not realize that our Asterisk is behind NAT, the packets arriving assembled with the public IP of the network device that performs the NAT on the sent packets.
For this scheme, we analyze the PJSIP configuration wizard template that is proposed to complete with your data:
Regarding the rest of the parameters, let's emphasize: The last 3 parameters are related to the data provided by the supplier when contracting the service. These are the IP address or FQDN and the corresponding port of their SIP server to which we send our REGISTERs to register the trunk or the INVITEs when sending outbound calls. Additionally, the values of username and password are used, which the supplier uses to authenticate these REQUESTs.
The following 4 parameters refer to the fact that typically under this scheme, OMniLeads does not request authentication from the SIP provider for incoming calls, but must authenticate when sending calls to the provider. Additionally, it must send a recurring registration to be located by the SIP provider when connecting incoming calls. Specifically, we are talking about the following parameters and values: This parameter indicates to the Asterisk PJSIP stack that it must advertise the public IP and public port with which SIP packets will be sent to reach the provider's SIP server.
The following 3 parameters are related to the codecs to be used, the protocol used for DTMF exchange, and finally the entry point (dialplan context) for the calls arriving via the trunk:
When declaring the SIP trunk on the other end, keep in mind that OMniLeads will use the SIP UDP port 5162 in these NAT environments. Important
In this scenario, we have the possibility of an application deployed on a VPS with a public IP whose SIP provider is also on a public IP, so there is no NAT. This scenario also includes a deployment carried out on a corporate LAN (on premise) going out to the Internet through the company router, or using an SBC or PSTN-GW, which takes care of (among other things) the NAT issue.
As in the previous item, a SIP provider available on the Internet is proposed, whose public IP is now reached without the impact of NAT, since our OMniLeads is available with a public IP. The provider, as before, provides us with the IP or FQDN of the SIP server to which we must send all REQUESTs on the one hand, and a user and password to authenticate them, on the other.
For this scheme, we analyze the PJSIP configuration wizard template that is proposed to complete with your data:
Where the only parameter that changes with respect to the examples with NAT is:
Where the use of a PJSIP transport is indicated, in which packets simply flow through UDP port 5060 without performing any NAT processing.
Under this classification, we have SIP link providers that arrive with their own connectivity backbone to the physical location where the data center is located. It is usually typical in this scenario that the provider does not ask for authentication or registration, and also when routing calls over the provider's private backbone, the NAT issue is no longer a factor to be resolved on our side.
For this scheme, we analyze the PJSIP configuration wizard template that is proposed to complete with your data:
Where the last 2 parameters have to do with the data that the provider provides us. That is, the IP address or FQDN and corresponding port to which we must send our REQUESTs. Keep in mind that under this scheme, we assume that the SIP provider does not authenticate us via SIP, so we do not use username or password. Again, transport=trunk-transport is used, implying that NAT is not affected. The rest of the parameters were already discussed in the previous case.
A widely implemented scheme involves the connection via SIP trunk between OMniLeads and the company's PBX. Under this modality, access to the PSTN is provided by the PBX, so that outgoing calls to the PSTN are routed through the SIP trunk to the PBX and then the PBX is responsible for routing the calls to specific destinations through its links to the PSTN. In the case of incoming calls, the PBX can derive calls from various of its own resources (IVR options, incoming routes, announcements, time conditions, etc.) to OMniLeads' incoming routes. Under this configuration, a company can deploy a Contact Center application fully integrated with its PBX.
The PJSIP configuration wizard template that is proposed to be completed according to the configuration generated on the IP PBX side is:
It is proposed to authenticate outgoing calls (from OMniLeads to the PBX) and incoming calls (from the IP PBX to OMniLeads) via SIP. Therefore, the following parameters and their values are used:
sends_auth=yes
accepts_auth=yes
remote_hosts=****IPADDR-or-FQDN:PORT****
inbound_auth/username=****SIP_USER PBX -> OML****
inbound_auth/password=****SIP_PASS PBX -> OML****
outbound_auth/username=****SIP_USER OML -> PBX****
outbound_auth/password=****SIP_PASS OML -> PBX****
endpoint/from_user=****SIP_USER OML -> PBX****
We assume the interpretation of the parameters from their suggestive names. In addition, it is highlighted the fact that they do not imply any SIP registration, neither from OMniLeads to the PBX nor vice versa, since both systems are in a LAN network and with an assigned IP address or FQDN. On the other hand, the parameters transport=trunk-transport and endpoint/force_rport=no tell us that no type of NAT treatment is applied to the SIP packets generated from OMniLeads. Finally, we highlight the parameter endpoint/context=from-pbx that indicates that calls coming from the IP PBX have a different access point than those coming from the PSTN, since among other possibilities it allows direct contact with the agents, making it possible for an extension of the IP PBX to dial or transfer to an agent.
Important!
When declaring the SIP trunk on the other end, keep in mind that OMniLeads will use SIP UDP port 5161 in these NAT-FREE environments.
Here, the administrator will be able to write his own custom PJSIP wizard configuration. Beyond the templates provided, the administrator always has the possibility of adjusting the configuration according to the specific scenario and the particularities of each case, so it is highly recommended to study the parameters of the Asterisk PJSIP stack carefully, since it has a high level of customization.
