Telephony Interface Types

[mhansen453]

NetBox version

v3.3.9

Feature type

Data model extension

Proposed functionality

I understand the the interface types are statically coded into the application. Could a type of interface called "Telephony" be added to the list and include items like "FXO", "FXS", "ISDN", "T1", "PRI", etc....

Use case

I am a Telecom Engineer and would like to be able to document telephony connections into our equipment.

Database changes

I don't have a strong knowledge of the database design but I wouldn't think a schema change would be needed.

External dependencies

None

[arthanson]

@mhansen453 can you please expand on this, listing out all the interfaces desired or else give pointers to a reference list? If you don't have one available then you can open a discussion at https://github.com/netbox-community/netbox/discussions so others can potentially expand the list.

[sleepinggenius2]

It's been a long time since I worked with v3.3.9, so I don't remember what the options were there, but T1 is available in v3.7.8 at least. I added FXO (Foreign Exchange Office), FXS (Foreign Exchange Subscriber), and PRI (Primary Rate Interface) as types in our environment and it was relatively trivial, but it would certainly be nice to have them added in the base product. I used Voice for the group name, as that's typically how we refer to it internally, but Telephony would also be reasonable. For FXO and FXS, we have a mix of physical RJ-11 ports, as well as ones where the tip and ring come from pins on an MRJ21 connector, so you could have a similar issue to 4x10G Ethernet breakout ports in the whole physical/virtual, parent/child space. For PRI, I think it would make sense to treat it as a virtual interface, as my understanding is that it would always require an underlying T1, which should be able to be set as the parent. That is how I have it implemented currently. I've never had to deal with ISDN, so I don't know what the requirements would be there, and I can't think of anything else that would fall under the etc. in your proposal. FXO, FXS, and PRI would be the ones I would advocate for.

[mhansen453]

I did finally find T1, E1, T3, and E3 they are listed under Serial. But yes FXS, FXO and PRI would still be nice

[jeremystretch]

FXO and FXS are analog phone lines rather than network interfaces, so adding these wouldn't make sense IMO.

[sleepinggenius2]

We deploy a lot of IAD devices for our customers that use Ethernet, DSL, DOCSIS, or PON backhaul and are able to provide Ethernet, T1/PRI, FXO, and FXS connections downstream. They use SIP for the telephony backhaul and can also provide SIP and SBC functionality downstream. It is very important for us to model all these different interfaces to be able to document the services we provide and generate the appropriate device configurations.

Example products: https://www.adtran.com/en/products-and-services/business-solutions/access-routers-and-ip-gateways/total-access-900e-series The FXO, FXS, and PRI interfaces all show in an SNMP walk of the IF-MIB::if(X)Table:

IF-MIB::ifType.1 = INTEGER: ds1(18)
IF-MIB::ifType.2 = INTEGER: ds1(18)
IF-MIB::ifType.3 = INTEGER: ds1(18)
IF-MIB::ifType.4 = INTEGER: ds1(18)
IF-MIB::ifType.5 = INTEGER: voiceFXO(101)
IF-MIB::ifType.6 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.7 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.8 = INTEGER: voiceFXS(102)
IF-MIB::ifType.9 = INTEGER: voiceFXS(102)
IF-MIB::ifType.10 = INTEGER: voiceFXS(102)
IF-MIB::ifType.11 = INTEGER: voiceFXS(102)
IF-MIB::ifType.12 = INTEGER: voiceFXS(102)
IF-MIB::ifType.13 = INTEGER: voiceFXS(102)
IF-MIB::ifType.14 = INTEGER: voiceFXS(102)
IF-MIB::ifType.15 = INTEGER: voiceFXS(102)
IF-MIB::ifType.16 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.17 = INTEGER: primaryISDN(21)
...
IF-MIB::ifName.1 = STRING: t1 0/1
IF-MIB::ifName.2 = STRING: t1 0/2
IF-MIB::ifName.3 = STRING: t1 0/3
IF-MIB::ifName.4 = STRING: t1 0/4
IF-MIB::ifName.5 = STRING: fxo 0/0
IF-MIB::ifName.6 = STRING: eth 0/1
IF-MIB::ifName.7 = STRING: eth 0/2
IF-MIB::ifName.8 = STRING: fxs 0/1
IF-MIB::ifName.9 = STRING: fxs 0/2
IF-MIB::ifName.10 = STRING: fxs 0/3
IF-MIB::ifName.11 = STRING: fxs 0/4
IF-MIB::ifName.12 = STRING: fxs 0/5
IF-MIB::ifName.13 = STRING: fxs 0/6
IF-MIB::ifName.14 = STRING: fxs 0/7
IF-MIB::ifName.15 = STRING: fxs 0/8
IF-MIB::ifName.16 = STRING: giga-eth 0/1
IF-MIB::ifName.17 = STRING: pri 1

[mhansen453]

Since there has started to be a bit of a discussion around this I have started a discussion thread (as recommended by @arthanson). The discussion thread can be found at https://github.com/netbox-community/netbox/discussions/17074

[mhansen453]

FXO and FXS are analog phone lines rather than network interfaces, so adding these wouldn't make sense IMO. @jeremystretch I respect you train of thought however NetBox seems to be designed to document everything in the data center environment including power, console connections, data circuits as well as traditional data network connections like ethernet. Documenting these voice connections are just one more component on some of these devices.

As an example I have an office where all the telephony is completely VoIP except for 1 fax line and 1 line going out to an overhead paging system. These are handled by a card in the back of a network router in that office.

[dallenk]

If I may add to this one. I maintain a 911 dispatch communcations center using SBC's and MK devices which interface between mutiple technoligis and interface types.

In this case, the Mediant 1000b device is modular, which has FXO or FXS interfaces which in turn communicate over SIP.

the ability to document these interface types for the device or module would be a great enhancement IMO.

[rplodev]

Guys, I use ConsolePort for this case. It's awful for Telco guys like us, but it's actually the only solution i found. I could use RJ-11 type on my consoleport with name voice-port blabla and label FXO 0.