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