Feature #5436
open
BRI variant of OCTOI protocol
Added by laforge about 2 years ago.
Updated about 1 year ago.
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 to Feature #5417: S/T (S0) ISDN BRI adapter with VCXO / GPS-DO added
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.
Also available in: Atom
PDF
