This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Luca Valtulina valtulina.luca at gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20140331/a689f65e/attachment.htm>