Differences

This shows you the differences between two versions of the page.

--- quick_start_guide [2024/06/16 19:25] – trmg
+++ quick_start_guide [2024/06/16 22:26] (current) – [Pick a trunking technology (or two!)] trmg
@@ Line 7: / Line 7: @@
 ====== Pick a trunking technology (or two!) ======
-After you've picked a prefix, you will want to choose at least one trunking technology to use for SCDP. Trunking technology support varies among participants, but the following are used in varying degrees:
+After you've picked a prefix, you will want to choose at least one trunking technology to use for SCDP. Trunking technology support varies among participants, but the following are used in varying degrees.
+Note that if you decide to use CEMoIP or H.323 and would like to establish IP peering with the network, reach out to members to get that going as we're all happy to peer.  You may want to view a looking glass (such as TRMGTel's [[https://vofr.net/lg|here]]) to get a sense of the used IP space.  If you're using default 10. or 192.168. prefixes you may need to renumber.
 ==== CEMoIP ISDN PRI ====
@@ Line 21: / Line 23: @@
 **VPN tunnel recommended**
-This is the preferred trunking method if you have a Cisco Integrated Services Router or other H.323 capable device in your voice network. This is simpler than CEMoIP but is very similar signalling wise to Q.931.  However, it does require that you also establish IP peering with the network via VPN tunnel (WireGuard is most common, but other technologies can be supported if needed) and, preferably, BGP.  This is because H.323, at least with the common equipment found among the network, is not NAT friendly.  If you have a H.323 gateway directly exposed to the Internet, trmg has one exposed that you can peer with which would not require VPN.
+This is the preferred trunking method if you have a Cisco Integrated Services Router or other H.323 capable device in your voice network. This is simpler than CEMoIP but is very similar signalling wise to Q.931.  However, it may require that you also establish IP peering with the network via VPN tunnel (WireGuard is most common, but other technologies can be supported if needed) and, preferably, BGP.  This is because H.323, at least with the common equipment found among the network, is not NAT friendly.  If you have a H.323 gateway directly exposed to the Internet, TRMGTel US-West has one exposed which will handle these calls.
-The most common H.323 gateway used among network operators is the Cisco ISR 2800/2900/3800 and similar family of routers.  Below is a basic config that should get you started:
+The most common H.323 gateway used among network operators is the Cisco ISR 2800/2900/3800 and similar family of routers.  It is assumed your unit has a basic working IP configuration.  Below is a basic voice config that should get you started:
 <code>
 voice service voip
  allow-connections h323 to h323
- allow-connections h323 to sip
- allow-connections sip to h323
- allow-connections sip to sip
- signaling forward unconditional
 voice class codec 1
@@ Line 51: / Line 49: @@
 </code>
+The above assumes you are using 1-222 as the "prefix" or "trunk access code" for SCDP.  Feel free to change that as necessary.
 Once the above has been configured, you will need to deal with the toll fraud prevention feature that is enabled by default on most platforms.  This feature is only really necessary if your ISR is directly exposed to the Internet and is not protected by other means such as a firewall.  If you need to prevent unwanted SIP/H.323 calls from being placed through your ISR, it is recommended instead to use an ACL on the public interface to block SIP/H.323 control traffic as necessary. The toll fraud prevention feature requires you to add individual IPs to the allow list which is sub-optimal when participating in a dynamic network such as SCDP. You could choose to coordinate with larger node operators and strictly allow traffic from them and utilize the toll fraud prevention feature if you choose.  It is up to you.
@@ Line 61: / Line 61: @@
 </code>
-We need to define an ENUM lookup table.  Yes, the ISR supports ENUM NAPTR resolution!  Historically every "tandem" node has been manually defining prefixes as they've been assigned.  This centralizes these efforts.
+===== IAX2 =====
+**VPN tunnel NOT required, but is less fun**
+If you do not have a device that will speak H.323 or do not want to dive into CEMoIP stuffs, IAX2 is the simplest way (though arguably the least "fun") to trunk with the network.
-Rule 10 takes any match and performs a 1:1 lookup.  Rule 20 takes the prefix "1-222" and strips it before performing a lookup.  A few node operators internally prefix SCDP with 1-222.  This is optional.
+The sample config is for Asterisk.  A basic understand of Asterisk is assumed.  If you are familiar with how C*NET works, this will seem familiar.
-Next, we need to define at least one dial-peer.
+Add a trunk for SCDP in iax.conf
+<code>
+[scdp]
+type=user
+context=[inbound context for SCDP calls]
+sendani=yes
+requirecalltoken=no
+disallow=all
+allow=ulaw
+allow=alaw
+</code>
+Build inbound dialplan code as you see fit.
-===== IAX2 =====
+To place calls to SCDP desitnations here's a basic outbound dialplan that should work.  Node operators typically expect to receive 7 digits.
-**VPN tunnel NOT required, but is less fun**
+<code>
+[outbound-scdp]
+  exten => _NXXXXXX,1,Progress()
+  same  => n,GoSub(gosub-scdp,s,1(${EXTEN}))
+  same  => n,Goto(scdp-rls-handler,s,1)
+[gosub-scdp]
+  exten => s,1,Set(result=${ENUMLOOKUP(+${ARG1},iax2,,1,e164-scdp.vofr.net)})
+  exten => s,n,GotoIf($["${result}"!=""]?dialiax)
+  exten => s,n,Progress()
+  exten => s,n,Congestion(30)
+  exten => s,n,Return()
+  exten => s,n(dialiax),Dial(IAX2/${result},120,${DIALOPTS})
+  exten => s,n,Return()
+</code>
-If you do not have a device that will speak H.323 or do not want to dive into CEMoIP stuffs, IAX2 is the simplest way (though argubly the least "fun") to trunk with the network.
+NOTE: This is a work in progress.  The subroutine above for ENUM lookup will only act upon the first result.  Once a good subroutine with route failover is vetted this will be updated, but this will get things going in the short term.  Suggestions always welcome.
 ===== SIP =====
-We prefer to generally stay away from SIP, but many node operators can support this if needed but it is typically last restort.  As of this writing, there are no known node-to-node SIP trunks in service thus no "quick start" instructions for this.
+We prefer to generally stay away from SIP.  Some node operators can support this if needed but it is typically last resort.  As of this writing, there are no known node-to-node SIP trunks in service thus no "quick start" instructions for this.
-====== Decide who you want to peer with ======
+====== Announce Your Presence ======
-TBD
+Let the other participants know that you are ready to interoperate with the network.  The ENUM E.164 NAPTR database will need to be updated (currently operated by TRMGTel) and node operators who are not currently utilizing the ENUM database may need to add routes manually.