Hi all.
One of the options for call routing for OpenBSC is LCR. They talk to each other over MNCC which is nice versioned protocol.
What puzzles me most is the version difference: OpenBSC: openbsc/include/openbsc/mncc.h:166:#define MNCC_SOCK_VERSION 4 LCR: mncc.h:333:#define MNCC_SOCK_VERSION 5
The OpenBSC is latest from git://git.osmocom.org/openbsc master branch, the LCR is latest from git://git.misdn.eu/lcr.git, master branch as well.
So, what am I missing? Where does this version difference comes from?
On a related note - the MNCC code in OpenBSC is part of libbsc but there's no such package or library when I'm building .deb for example. If we could split off MNCC implementation into separate library (libmncc? libosmocore?) and use it from both LCR, OpenBSC (and whatever else we might want to use in future) than it would solve such versioning and compatibility issues once and for all.
What do you think?
On Thu, Jul 09, 2015 at 11:41:51AM +0200, ☎ wrote:
So, what am I missing? Where does this version difference comes from?
I think this is due to jolly having a custom branch of openbsc, where he incremented the version - as well as incrementing it in lcr master. So now if you use master of both, the version number will be diferent.
But I may be mistaken here.
What do you think?
I think the MNCC code is quite different on either side of the interface: NITB as the GSM network side and LCR as the "call agent". As such I'm not sure how much shared code there would be?
On 08 Aug 2015, at 22:48, Harald Welte laforge@gnumonks.org wrote:
I think this is due to jolly having a custom branch of openbsc, where he incremented the version - as well as incrementing it in lcr master. So now if you use master of both, the version number will be diferent.
But I may be mistaken here.
LCR master has “rtp-bridge” MNCC commands (create, modify and the unused delete one). And this has lead to bumping the version number.
I have recently re-implemented RTP bridge (but different to Andreas’s original implementation in NITB). Audio can now directly flow from a BTS to .. somewhere else.
08.08.2015 22:48, Harald Welte пишет:
I think the MNCC code is quite different on either side of the interface: NITB as the GSM network side and LCR as the "call agent". As such I'm not sure how much shared code there would be?
Yes, but it's not only about 2 existing implementations. What if we'd like to add MNCC support to freeswitch? kamailio? asterisk? whatever-other-thing?
Having readily available protocol implementation as part of some library would make it a lot easier to implement. It'll also make protocol version tracking much simpler.
On Mon, Aug 10, 2015 at 12:24:17PM +0200, ☎ wrote:
Having readily available protocol implementation as part of some library would make it a lot easier to implement. It'll also make protocol version tracking much simpler.
from my point of view there is nothing as a plain 'protocol implementation', but you would basically have to invent portable/stable data structures, associated APIs, etc. Given that MNCC is not complex but rather simply a way of encoding primitives that get shoved left and right, I'm not sure what such 'yet another representation for the MNCC primitives' would bring, except more code that needs to be written, and that needs to be traversed.
From my point of view, the header file is probably everything that you
would need to share. From the very dispatch of the received primitives, everything will be very much dependent on the actual MNCC handler (lcr, freeswitch, etc.) who all have their own architecture, data structures, etc.
The issue gets even more simplified by the fact that MNCC doesn't even have a real/portable wire encoding (think of TLVs, ...) that's independent of the 'structs' that we pass around over the socket.
Feel free to convince me otherwise, but at least so far I do not see how that shared/common code would look like :)
Regards, Harald
-
Harald Welte -
Holger Freyther -
☎