General SIP Trunk parameters

As well anticipated PJSIP is the module that implements SIP for this kind of trunks. But also the syntax chosen to generate the configuration at the Asterisk conf is pjsip wizard.

Además del link citado de la documentación oficial de Asterisk, compartimos el siguiente link que resulta de mucho interés para profundizar respecto a los parámetros disponibles dentro de pjsip wizard.

Important

We must remember very well that OMniLeads does NOT use port 5060 as the port for SIP trunks. Port 5060 is used by Kamailio in its WebRTC work in sessions against agents. When generating a SIP trunk between OML and a SIP or PBX provider, we must know that the ports to be used are and vary according to the scenarios described below.

  • Port 5161 for trunks where we must NOT warn the public IP. That is, where there is no NAT involved.
  • Port 5162 for trunks where we MUST warn the public IP, since they willaffect with NAT the SIP packets that leave OML.
  • Port 5163 for trunks used in OML architecture over Docker containers.

The following scenarios are proposed for OMniLeads instances and their connection to a SIP provider with termination to the PSTN.

OMniLeads behind NAT

Under this scenario we have the possibility of the App deployed on a Cloud provider going out to the Internet through a gateway. The NAT also affects the deployment of an on-premise instance in a corporate LAN in which the Internet is routed through the company’s router using a Public IP to perform the NAT on the packets generated from OMniLeads to the SIP provider.

_images/telephony_oml_nat.png

Here, Asterisk uses the UDP port 5162 since it is the port that implements the fact of warning in the REQUEST or RESPONSE SIP the Public IP with which the packets will go abroad and reach the other end of the SIP trunk. This adaptation of the mentioned packets is done at the SIP (signaling) and SDP (media negotiation) levels. Therefore, the external recipient of the packets does not realize that our Asterisk is behind NAT. The packets assembled arrive with the public IP of the network device that performs NAT on the sent packets.

For this scheme we analyze the PJSIP configuration Wizard template that is proposed to complete with your data:

type=wizard
transport=trunk-nat-transport
accepts_registrations=no
accepts_auth=no
sends_registrations=yes
sends_auth=yes
endpoint/rtp_symmetric=yes
endpoint/force_rport=yes
endpoint/rewrite_contact=yes
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pstn
remote_hosts=****IPADDR-or-FQDN:PORT****
outbound_auth/username=****YOUR SIP_USERNAME****
outbound_auth/password=****YOUR SIP_PASSWORD****

The last three parameters have to do with the data that the provider provides us when contracting the service. That is, the address or FQDN and corresponding port of its SIP Server where to shoot our REGISTER to register the trunk or INVITE when sending outgoing calls. In addition, the username and password values with which the provider authenticates those REQUEST are available.

Regarding the rest of the parameters, we will emphasize:

transport=trunk-nat-transport

This parameter indicates the Asterisk PJSIP stack that it must warn the public IP and public port with which the SIP packets will leave when reaching the provider’s SIP-Server.

The next 4 parameters allude to the fact that typically under this scheme OMniLeads does not request authentication from the SIP provider in case of incoming calls, but must authenticate when sending calls to the provider and that it must also send a recurring register to be able to be reached by the SIP provider when connecting incoming calls. We are specifically talking about the parameters and their values:

accepts_registrations=no
accepts_auth=no
sends_auth=yes
sends_registrations=yes

The following three parameters have to do with the codecs to use, the protocol used for the DTMF exchange. Finally the entry point (dialplan context) of the calls that arrive through the trunk.

endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pstn

Important

When declaring the SIP trunk at the other end, keep in mind that OMniLeads will use the SIP UDP port 5162 in these NAT environments.

OMniLeads in environments without NAT

Under this scenario, we have the possibility of the App deployed on a VPS with a public IP whose SIP provider is also on a public IP. Therefore, there is no NAT. This scenario includes a deployment performed on a corporate LAN (on premise) connecting to the Internet through the company’s Router or using a SBC or PSTN-GW, which is in charge (among other things) of the NAT issue.

SIP trunk on the Internet

As in the previous item, a SIP provider available on the Internet is proposed. Its public IP is now reached without the affection of the NAT, since OMniLeads is available with a public IP. Just as before, the provider facilitates us with the IP or FQDN of the SIP Server to which we must send all the REQUEST, on the one hand, and a username and password to authenticate them, on the other.

_images/telephony_oml_nonat_vps.png

For this scheme we analyze the PJSIP configuration Wizard template that is proposed to complete with your data:

type=wizard
transport=trunk-transport
accepts_registrations=no
accepts_auth=no
sends_registrations=yes
sends_auth=yes
endpoint/rtp_symmetric=yes
endpoint/force_rport=yes
endpoint/rewrite_contact=yes
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pstn
remote_hosts=****IPADDR-or-FQDN:PORT****
outbound_auth/username=****YOUR SIP_USERNAME****
outbound_auth/password=****YOUR SIP_PASSWORD****

The only parameter that changes with in regard to the examples with NAT is:

transport=trunk-transport

Where the use of a PJSIP transport is indicated, where the packets simply flow through the UDP 5161 port without any NAT treatment.

Corporate SIP Trunk

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. In this scenario it is frequent that the provider does not request authentication or registration. Besides, when making calls on the provider’s private backbone the NAT issue is no longer a problem to be solved.

_images/telephony_oml_nonat.png

For this scheme we analyze the PJSIP configuration Wizard template that is proposed to complete with your data:

type=wizard
transport=trunk-transport
accepts_registrations=no
accepts_auth=no
sends_registrations=no
sends_auth=no
endpoint/rtp_symmetric=no
endpoint/force_rport=no
endpoint/rewrite_contact=no
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/timers=yes
endpoint/language=es
endpoint/context=from-pstn
remote_hosts=****IPADDR-or-FQDN:PORT****

The last two parameters have to do with the data that the provider facilitates us. That is, the IP / FQDN address and corresponding port where we should fire our REQUEST. Keep in mind that under this scheme we assume that the SIP provider does not authenticate us via SIP, therefore we do not use username or password.

Once again the transport = trunk-transport is used, implying that NAT is not affected.

The rest of the parameters were already discussed in the previous case.

OML SIP trunk with PBX on LAN

A highly implemented scheme has to do with the SIP trunk connection between OMniLeads and the company’s PBX. Under this modality, access to the PSTN is provided by the central PBX. The outgoing calls to the PSTN are made through the SIP trunk to the PBX and then the latter is in charge of routing the calls to the specific destinations through their links to the PSTN.

Under this configuration, a company can deploy a Contact Center App fully integrated with its central PBX.

_images/telephony_oml_nonat_pbx.png

The template PJSIP configuration Wizard that is proposed to be completed according to the configuration generated on the IP-PBX side is:

type=wizard
transport=trunk-transport
accepts_registrations=no
sends_auth=yes
sends_registrations=no
accepts_auth=yes
endpoint/rtp_symmetric=no
endpoint/force_rport=no
endpoint/rewrite_contact=no
endpoint/timers=yes
aor/qualify_frequency=60
endpoint/allow=alaw,ulaw
endpoint/dtmf_mode=rfc4733
endpoint/context=from-pbx
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****

Outgoing calls (from OMniLeads to the PBX) and incoming calls (from the IPPBX to OMniLeads) are proposed to be authenticated via SIP. That explains the following parameters and their values:

  • 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 take for granted the interpretation of the parameters from their suggestive names. We also highlight the fact of not involving any SIP registration -either from OMniLeads to the PBX or the other way around- since both systems are on a LAN network and with an IP address or assigned FQDN.

On the other hand, the parameters transport=trunk-transport and endpoint/force_rport=no not tell us that any type of NAT treatment is applied to the SIP packets generated from OMniLeads.

Finally the parameter related to context endpoint/context=from-pbx indicates that the calls from the PBX have an access point different that calls from PSTN, because using the context from-pbx you can call and transfer between OMniLeads agents and PBX extensions.

Important

When declaring the SIP trunk at the other end, keep in mind that OMniLeads will use SIP UDP 5161 port in these NAT-free environments.

PJSIP custom trunk

Here the Administrator will be able to customize his or her own PJSIP wizard configuration. Beyond the templates provided, the Administrator always has the possibility of adjusting the configuration according to the specific scenario and to the particularities of each case. It is therefore highly recommended to fully comprehend the parameters of the Asterisk PJSIP stack due to their high level of customization.