Outbound SIP Trunk Requirements

These are the requirements to create an outbound SIP trunk (FROM Sharpen to a remote endpoint).

(For SIP calls sent inbound from a remote destination into Sharpen, please see Inbound SIP Trunk Requirements )

1. Customer SIP endpoint(s)

   1. Customer provides 1+ publicly accessible IP addresses for the SIP endpoints to their CSM.  Sharpen will review and enter those IP’s into the customer database (for security reasons, customers cannot create their whitelisted IP’s on their own). 

   2. Customer should provide ports for their SIP and RTP traffic to their CSM also (if different from Sharpen default ports listed in point #3)

   3. Customer should provide expected max and avg call concurrency estimates to Sharpen

   4. After configured by Sharpen, those IP’s will appear in the Admin>SIP Trunks page in Sharpen and can be given friendly names by the customer

   5. Customer then creates a SIP Trunk Group on the same admin page, and adds available SIP trunks in order they wish to have them listed (see “routing strategy” below)

2. Authentication

   1. Sharpen will whitelist the IP’s in step 1 on our outbound SBC’s. 

   2. Customer should whitelist these IP’s from Sharpen (outbound SBC gateways) - contact your CSM if you are unsure which IP list pertains to your company

      1. Main (reach out to devops team for up-to-date list)

         • 3.93.117.96

         • 52.1.60.99

         • 107.23.198.202

      2. Condo IZ1 (reach out to devops team for up-to-date list)

         • 23.21.193.93

         • 54.146.138.47

         • 3.82.140.190

3. Ports opened on customer receiving side

   1. TCP/UDP 5060 for SIP signalling (TLS not supported at this time)

   2. 10000-20000 UDP for voice traffic

4. Sharpen will send voice in the G.711 codec (additional codec support like G.729, Opus, etc, are future roadmap items)

5. Routing strategy - “Primary/Backup” with secondary/tertiary IP’s only used when the preceding IP fails.

   1. We will attempt the 1st IP address in a SIP trunk group for every call

   2. Upon failure (no IP response or 500 response), it will immediately go to the next IP in the Trunk Group and try that one. 

   3. Upon successful connection to a secondary/tertiary IP, the call will proceed as normal.

   4. Upon failure it will continue through the list of IP’s in the trunk group, in order

   5. Any IP failure will mark that trunk as offline.  Sharpen will wait 15 minutes and then attempt to restore that IP in the trunk order.  If it succeeds, it reclaims it’s spot in the order of active tries (trunk group order).  If it fails again, it will continue to be marked offline and re-tried every 15m until it successfully accepts calls, or it is removed manually from the trunk group 

   6. If customer endpoint accepts the IP traffic but does not respond with SIP signals (“soft down”), there will be a delay/timeout until it proceeds to the next IP in the list of up to 60s.  A customer could take the SIP trunk out of the group manually, which can take up to 15m for the new order to be recognized (IP order is cached on 15m interval based on first call coming into that SIP trunk group)

   7. If no connection occurs after exhausting all IP’s, the call is disconnected.  We have internal alerts setup for Sharpen to notify a customer if this is an ongoing issue.

   8. Future plans are to enable Round Robin across all IP’s in the trunk group as the default, and retain active/backup as an option to manually enable

6. Configure Dial Plan Rules

   1. Outbound formatting will be controlled with Sharpen Dial Plan and SIP Line configurations in Admin modules.  This will be enabled on a per org basis as customers require BYO.

Additional Outbound Notes:

• In active/backup mode, if a remote IP fails, the caller will hear silence until the next backup IP is connected.  Once marked “offline” the previous active IP is not tried and calls proceed normally

• Changes to Trunk Groups (add, remove, re-order) can take a maximum of 15 minutes to take effect.  For expediency on normal calls, SIP trunk configurations are cached, with a refresh every 15m (based on when a call first hits the SIP trunk).  Depending on when during the cycle the change was saved, it will take effect from a few seconds to 15m.