Skip to main content

Provider iinet (Australia)

iinet.net.au​

Last update: 9 August 2011

<include>
  <gateway name="iinet">
    <param name="username" value="YOURPHONENUMBER"/>
    <param name="from-domain" value="iinetphone.iinet.net.au"/>
    <param name="password" value="YOURPASSWORD"/>
    <param name="extension" value="YOURPHONENUMBER"/>
    <param name="realm" value="iinetphone.iinet.net.au"/>
    <param name="proxy" value="sip.YOURSTATE.iinet.net.au"/>
    <param name="register" value="true"/>
    <param name="caller-id-in-from" value="true"/>
  </gateway>
</include>

For outbound calls to work!​

The above example says that "caller-id-in-from" is required. This is NOT actually required. In fact, even with this set it will still fail. The crucial thing you need to do if you want to place calls is that you must set two variables in your outbound dialplan:

<action application="set" data="effective_caller_id_number=***your number***"/>
<action application="set" data="effective_caller_id_name=***your number***"/>

You will need these in every dialplan entry that uses this gateway.

The reason for this is that iinet will reject any call that comes to it from anywhere other than the callerid that is registered with them. By default, freeswitch will send the caller id of your extension with the outgoing call, therefore iinet will reject the call. By setting these variables you override that default behaviour and iinet sees what it wants to see.

A more elegant way to achieve this is to set the following in your extension definitions:

<variable name="outbound_caller_id_name" value="***your number***"/>
<variable name="outbound_caller_id_number" value="***your number***"/>

And then in your outbound dialplan set:

<action application="set" data="effective_caller_id_number=${outbound_caller_id_number}"/>
<action application="set" data="effective_caller_id_name=${outbound_caller_id_name}"/>

WARNING​

Users have reported that iinet delivers calls with Max-Forwards=4 rather than the usual setting of 70.

This has been observed to cause FreeSWITCH to be unable to do much with the call before Max-Forwards has been exceeded. If you have strange behaviour of calls from iinet to FreeSWITCH it would be worth considering this. For instance, if you process the call through IVRs or other call logic before delivering it to a phone it is possible that it will not be able to deliver the call to a phone as Max-Forwards may have already been exceeded.