Feature #5436
openBRI variant of OCTOI protocol
0%
Description
right now the protocol is rather E1-centric, or at least assuming that timeslots always have the same bitrate.
For BRI we have- 2x64k B-channels (exposed to the user)
- 1x16k D-channel (exposed to the user)
- additional management channels (not exposed to the user, normally handled in the NT)
We need to find a way to express BRI in our protocol.
Misc note: DAHDI exposes the 2xB+1xD as three channels. Not sure if the D-channel runs at a non-8kHz rate, or if it simply only uses 2 bits of every byte?
The header/packet protocol overhead of course becomes even higher (proportionally) compared to PRI.
Related issues
Updated by laforge about 2 years ago
- Related to Feature #5417: S/T (S0) ISDN BRI adapter with VCXO / GPS-DO added
Updated by laforge about 1 year ago
So there's two ways to approach this:
- go for the transparent approach like we did in OCTOI for E1/PRI. This would mean transparently passing along the bit-stream of B1, B2, D (and possibly E?) channels. We could use the same mechanism for suppression of identical frames.
- go for something higher level which would terminate the HDLC-based D-channel and only pass around D-channel messages after HDLC/FCS procedures.
I think WIMPy pointed out that there is equipment using 2B+D for stuff that's not D-channel signalling (I guess primarily routers intended for leased lines), so the transparent approach is probably still the best.
On the OCTOI hub side, in the end, we will want something that resembles a virtual DAHDI BRI card. The trunkdev code could likely be extended, so that some program (like osmo-e1d right now for PRI) is receiving packets from the OCTOI-BRI protocol and feeding the "frames" into a character device which then makes each BRI port show up like a normal DAHDI device. This coul then be used 1:1 by yate, just like existing DAHDI BRI interface cards.
