Adds cause field to the call_leg and sip_call_leg structs.
Translates the SIP status to MNCC cause and vice versa and
uses this information in the SIP/MNCC messages at call leg
release time.
Change-Id: Ic1b80dff7e583cd6fff2b662bc6cc4bad3f81cd4
We are not using the RTP telephony-event here but the older dtmf
relay. We also only have a fixed DTMF duration for now.
Change-Id: Icf770fae89f7aedf6eba9a119db9b8acc7f938df
In preparation of a better show calls VTY command it is of interest
to know which number has been dialed by whom. For that store the
source/dest in there.
MNCC: Change the talloc root context to the call and don't try to
free the strings after calling the routing code
SIP: Use talloc_strdup to duplicate them.
Call: Add null check because the talloc_strdup of the SIP layer
could have failed.
Start with a show call summary that lists simple data about the
current set of calls:
Call(5002) initial(type=SIP,state=CONFIRMED) remote(type=MNCC,state=INITIAL)
Call(5001) initial(type=MNCC,state=PROCEEDING) remote(type=SIP,state=CONFIRMED)
Related: OS#1680
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.
* 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
gsm
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.
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.
In case the MNCC server is crashing we need to release all calls,
use the event emitted by the MNCC connection and iterate over all
calls and call the release function.
Right now a call has two legs, the initial one and the remote. In
general this will allow a SIP to SIP, SIP to MNCC and MNCC to MNCC
structure in the future.