Add the new SDP section to the MNCC socket protocol, but do not yet implement
forwarding SDP from SIP. Implementing SDP forwarding follows in a subsequent
patch.
It is still possible to establish a call with empty SDP: the new osmo-msc on
the MT side, receiving an MNCC_SETUP_REQ, will hit an error log:
"Got no information of remote audio codecs: neither SDP nor Bearer Capability.
Trying anyway."
and then hold thumbs to hit a codec match, analogous to previous behavior.
Note that osmo-sip-connector should actually always have encoded a Bearer
Capability in the MNCC protocol in the MT MNCC_SETUP_REQ message, but never
has. Now we are ready to leapfrog from zero codec info to full SDP.
This patch must be merged at the same time as osmo-msc patch
Ie16f0804c4d99760cd4a0c544d0889b6313eebb7, so that both sides have a matching
MNCC protocol version number.
Change-Id: Iaca9ed6611fc5ca8ca749bbbefc31f54bea5e925
Add function pointers to the call_leg struct for call hold and retrieve.
Add function to send re-INVITE to SIP side when MNCC side puts call on HOLD/RETRIEVES.
Add MNCC/SIP CC_HOLD to call states.
Change-Id: I2595626dfa50eb2f8e29a02540b708c9c1dce88c
SIP end points can send periodic re-INVITES. Previous to this commit,
the osmo-sip-connector would send a new call SETUP to the MSC for each
re-INVITE.
Add a function to find if we already handle this call based on the nua handle.
Use this function to detect and respond with an ACK to re-INVITES.
Add a function to extract the media mode from the SDP.
In the case the re-INVITE has a=sendonly (HOLD) respond with a=recvonly
In the case that the re-INVITE changes the media connection ip/port,
forward this to the MNCC side with an MNCC_RTP_CONNECT
Change-Id: I4083ed50d0cf1b302b80354fe0c2b73fc6e14fed
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.