Possibility to use INET socket for external MNCC
Hi list, wouldn't be useful to have the possibility to choose (at least) between UNIX and INET socket to be used for connecting to an external MNCC? If this will be the case where should the choice be made? I was thinking to add an extra option to bsc_hack but the choice can also be hard-coded (prior to compilation). cheers luca
Hi Luca, The first question is why do you need to do that? If this is to be implemented, this looks like a VTY (i.e. configuration) option to me. On Fri, Mar 21, 2014 at 7:09 PM, Luca Valtulina <valtulina.luca@gmail.com> wrote:
Hi list,
wouldn't be useful to have the possibility to choose (at least) between UNIX and INET socket to be used for connecting to an external MNCC?
If this will be the case where should the choice be made? I was thinking to add an extra option to bsc_hack but the choice can also be hard-coded (prior to compilation).
cheers luca
-- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. / ООО УмРадио https://fairwaves.co
Hi Luca,
Hi Alexander,
The first question is why do you need to do that?
Well for instance, specific network design can lead to have an external MNCC in a different location/machine than OpenBSC. I know that LCR already offer the possibility to setup a UDP socket with a SIP endpoint but what if LCR is not to be used? I think that having the option to setup a INET socket also for OpenBSC can offer more dynamic network deployments. luca
On Fri, Mar 21, 2014 at 04:09:03PM +0100, Luca Valtulina wrote:
wouldn't be useful to have the possibility to choose (at least) between UNIX and INET socket to be used for connecting to an external MNCC?
There are several problems with this: 1) the MNCC interface carries both voice and signalling. For signalling you would like something that resembles TCP/SCTP/DCCP, but for the voice you would only like UDP semantics. Choosing either a reliable protocol for voice frames or an unrealiable protocol for signalling is calling for lots of trouble and will not happen. So it would have to be multiple sockets. 2) I don't think the current protocol is endian/alignment safe. By runnign it over a unix domain socket we basically enforce that both programs on the MNCC side will run on the same architectuer and not cause any problems. If you run it over a network, making that assumption is false. So yes, it could be possible to run MNCC over IP/INET sockets, but it would require considerable effort of addressing the issues described above. Will you be working on implementing this? Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
1) the MNCC interface carries both voice and signalling. For signalling you would like something that resembles TCP/SCTP/DCCP, but for the voice you would only like UDP semantics. Choosing either a reliable protocol for voice frames or an unrealiable protocol for signalling is calling for lots of trouble and will not happen. So it would have to be multiple sockets.
Currently I am establishing RTP sockets for voice (from jolly/testing branch) while a TCP/IP socket is used for signaling. So yes MNCC socket is used only for signaling (I though also about the possibility of using it as a "backup" socket in case RTP fails but then the reliable vs unreliable issue pops up)
2) I don't think the current protocol is endian/alignment safe. By runnign it over a unix domain socket we basically enforce that both programs on the MNCC side will run on the same architectuer and not cause any problems. If you run it over a network, making that assumption is false.
The endianness can be carried in the payload of any packet to make it safer or it can be exchanged upon socket setup for instance in the MNCC_SOCKET_HELLO message. Currently I am carrying the size of the sent signaling message in order to distinguish between gsm_mncc and gsm_mncc_rtp (for now). I did it more as a try than everything but I thought it was a waste to send 840 bytes of data when gsm_mncc_rtp messages are only 24 bytes long!
Will you be working on implementing this?
I might need a certain amount of guidance due to my lack of experience. Luca
You can try playing with socat tool ( http://www.dest-unreach.org/socat/ ) to forward unix socket over ip transparently to the application using it. I'm not sure how practical it would be - I mean how big additional latencies introduced and potential throughput and such. 21.03.2014 16:09, Luca Valtulina пишет:
Hi list,
wouldn't be useful to have the possibility to choose (at least) between UNIX and INET socket to be used for connecting to an external MNCC?
If this will be the case where should the choice be made? I was thinking to add an extra option to bsc_hack but the choice can also be hard-coded (prior to compilation).
-- best regards, Max, http://fairwaves.ru
participants (4)
-
Alexander Chemeris -
Harald Welte -
Luca Valtulina -
☎