21 Mar
2014
21 Mar
'14
4:09 p.m.
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
21 Mar
21 Mar
5:24 p.m.
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(a)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
24 Mar
24 Mar
11:18 a.m.
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
31 Mar
31 Mar
4:54 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5:34 p.m.
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
5:38 p.m.
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
3690
days inactive
3700
days old
5 comments
4 participants
participants (4)
-
Alexander Chemeris -
Harald Welte -
Luca Valtulina -
☎