Shadytel CDP

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
This document is a work in progress.

====== Pick a prefix ======

The first step in joining SCDP is to pick a prefix.  This is as simple as adding an entry to the table on the main page and self-assigning a prefix that does not conflict with those already listed.  It is recommended that you create a page for yourself so you can share details about your network.

====== 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.

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 ====

**VPN tunnel required**

This trunking method requires a Cisco Integrated Services Router or similar that can support a Channelized T1/E1 Circuit Emulation Module like the [[https://www.ebay.com/sch/i.html?_from=R40&_nkw=NM-CEM-4TE1&_sacat=0&_sop=15|NM-CEM-4TE1]].  This is a close as we can get to a "TDM" trunking experience.  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 will require you to choose a node to peer with.  You will want to work through the config with said node operator.

==== H.323 ====

**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 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.  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

voice class codec 1
 codec preference 10 g711ulaw
 codec preference 20 clear-channel

voice vad-time 65536

voice enum-match-table 1
 rule 10 1 /^(.*)/ /\1/ e164-scdp.vofr.net.
 rule 20 1 /^1222\(.*\)/ /\1/ e164-scdp.vofr.net.

dial-peer voice 12220 voip
 description SCDP ROUTE
 preference 1
 destination-pattern 1222.......
 session target enum:1
 voice-class codec 1 

</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.

If you decide to disable it, here's how you do it:

<code>
voice service voip
no ip address trusted authenticate
</code>

===== 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.

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.

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.

To place calls to SCDP desitnations here's a basic outbound dialplan that should work.  Node operators typically expect to receive 7 digits.

<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>

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.  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.

====== Announce Your Presence ======

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.