Skip to main content

Prefix_dialing

About​

Sometimes you may have multiple customers sending unauthenticated from a common IP. An example of an environment where this can occur is a wholesale trading floor system such as Arbinet.

Customers will arrive from the same IP(s) (so cannot be authenticated by CIDR) and will be unauthenticated (so cannot be authenticated by username & password).

They can be differentiated if they send using different prefixes. An ACL will be required to prevent anyone else sending using the same prefix to avoid fraud.

Click here to expand Table of Contents

Sofia configuration​

You should should then configure a Sofia profile that does not use an ACL and does not require calls to be authenticated.

Configure dialplan routing:

<param name="dialplan" value="XML"/>
<param name="context" value="default"/>

No ACLs (comment this out, prefix x- or remove):

<x-param name="apply-inbound-acl" value="domains"/>
<x-param name="apply-register-acl" value="domains"/>

Disable authentication:

<param name="auth-calls" value="false"/>
<param name="auth-all-packets" value="false"/>

Since you can create multiple profiles, it would be possible to create a profile for handling prefix dialling, alongside others which authenticate purely on IP/username. If so you should separate the calls by setting a dialplan context other than default, for instance:

<param name="context" value="prefix_dialling"/>

Dialplan​

You should create an ACL for each customer and add the IPs each can send from. The ACL is checked from within the dialplan.

The following dialplan can then be used. The customer_known context separates the call logic from the. It would also be possible to have a different context for each customer, to handle each one differently.

<context name="default">
  <extension name="customer_1">
    <condition field="destination_number" expression="^1111(.*)$">
      <action application="check_acl" data="${network_addr} customer_customer1"/>
      <action application="set" data="accountcode=customer1"/>
      <action application="transfer" data="$1 XML customer_known"/>
    </condition>
  </extension>
  <extension name="customer_2">
    <condition field="destination_number" expression="^2222(.*)$">
      <action application="check_acl" data="${network_addr} customer_customer2"/>
      <action application="set" data="accountcode=customer2"/>
      <action application="transfer" data="$1 XML customer_known"/>
    </condition>
  </extension>
  <extension name="customer_3">
    <condition field="destination_number" expression="^3333(.*)$">
      <action application="check_acl" data="${network_addr} customer_customer3"/>
      <action application="set" data="accountcode=customer3"/>
      <action application="transfer" data="$1 XML customer_known"/>
    </condition>
  </extension>
  <extension name="customer_4">
    <condition field="destination_number" expression="^4444(.*)$">
      <action application="check_acl" data="${network_addr} customer_customer4"/>
      <action application="set" data="accountcode=customer4"/>
      <action application="transfer" data="$1 XML customer_known"/>
    </condition>
  </extension>
</context>

<context name="customer_known">
  <extension name="e164">
    <condition field="destination_number" expression="^(\d+)$">
      <action application="bridge" data="sofia/gateway/gw001/$1"/>
    </condition>
  </extension>
</context>

Note: a side-effect of this method is that if the call hangs up very quickly, it may hangup before executing the dialplan. This will mean the CDRs for these call will show no account.

This won't cause any billing issues, but may mean your customer cannot see some of their calls. This is very rare, since it means the hangup must arrive as soon as the INVITE is received.

mod_xml_curl​

Alternatively if using mod_xml_curl, you can perform the prefix+IP matching within the HTTP application since both destination_number and network_addr values are provided.

A side-effect of this method is that if the call hangs up very quickly, it may hangup before executing the dialplan. This will mean the CDRs for these call will show no account. This won't cause any billing issues, but may mean your customer cannot see some of their calls. This is very rare, since it means the hangup must arrive as soon as the INVITE is received.