This will go through the stage of:
* MNCC_CALL_CONF_IND (to which we create a RTP socket)
* then we might receive a MNCC_ALERT_IND
* and finally the MNCC_SETUP_CNF
For the last two we inform the other leg about the progress.
For releasing a MT-Call we will need to send a release request
and then wait for the release confirmation. Add if/else to it.
If this turns out to be too ugly we will be able to create one
MO and one MT leg.
Fix releasing of the leg in case it is not routable and make the
differentation if we initiated the invite (send CANCEL) or send
a final error. The error code was randomly picked and once we have
an enum of causes we can decide where to map it to.
* Create a new handle
* Send the invite
* Have some state transitions
* Allow to release a call in initial unconfirmed state, confirmed
one with cancel and connected with bye
* Add simple SDP parsing to find the rtpmap/codec that is used by
I had modified my code to do nothing after having sent the PROCEEDING
message. First the MS will issue a DISCONNECT.IND (which I ignored) and
then there will be REL.IND. Let's inform the other leg about this event
and let's assume the call will then be terminated.
With a bit more code the logging will print:
<0001> mncc.c:233 Created call(5001) with MNCC leg(2147483659) IMSI(274018000000001)
<0001> mncc.c:178 RTP set-up continuing with call with leg(2147483659)
<0001> mncc.c:65 Got response, stopping timer on leg(2147483659)
<0002> call.c:51 call(5001) releasing.
Use %zu for size_t arguments, e.g. returned from sizeof.
The code is not tested and might be broken. Parse the setup request
of a MO call, create a new "call" with a MNCC leg and then issue the
call to create a RTP socket. Once this has been done, release the call
as the code to open a second leg has not been written yet.
Connect, re-connect and read messages from the MNCC socket. Dispatch
the event in case the system got disconnected.
Move the app definition to app.h and use it everywhere. Begin with a
new call for mncc.