Use gsm48_cc_cause_name() in logging messages
Depends-On: I296f208581ce2550805f9d96e20f7319e1199023
Change-Id: I6e3541b66cb3407f0cb23fb6e00a04685fe90757
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
Implements a cause_map, mapping the SIP status codes
to GSM48_CC_CAUSE_* that are defined in libosmocore.
The map at the same time implements the Q.850 cause texts
that are subsequently used in the SIP Reason: header.
Implements two functions cause2status() and status2cause()
to read the map and return the the mapped status.
The mapping mostly follows the implemention in the LCR program,
so that any implementation relying on that mapping should
continue to work as expected with osmo-sip-connector.
Change-Id: Id82be8603a30a6aec28fc0258236c1746973db58
sofia-sip allows applications to register a log backend function
which will be called every time the library wants to log something.
We register such a call-back and make it log using the libosmocore logging
framework.
The problem is that sofia-sip has its own log level management, and by
the time the message hits libosmocore, we don't know which log level we
shall use :(
Change-Id: Ib269b6b50f9d79bbd13acc43a626834921f05edb
Related: OS#3105
Parse the media from session in progress and if present in alerting
connect the call early. Sadly this sets RTP to the sendrecv mode even
if we would like to keep it as recvonly.
Change-Id: I98d173abc46c67b87666ed2f193a581d6e72344b
Related: OS#1784
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
So far the remote_port has never been used. sofia-sip did the right
thing and put the port into the "Contact" and the rport option for
the via. But we would have never been able to connect a PBX on a
different port (as sofia-sip seems to parse the destination from the
to address).
Change-Id: Ifbd49b4aa6b01b118fe67e39dddef50b2946159c
It doesn't fix early media yet but brings us one step
closer to it:
The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified. The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.
Change-Id: Ibf264f251e41c06a7b4839acc0d0853e6400291c
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.
The codec negotiation is still a huge todo and the initial version
will be far from perfect. We will use whatever MNCC has decided on
and then see if it is compatible in the end.
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.
Check if the SDP file has any codec potentially supported by GSM.
The topic of codec selection is a complicated one and we will not
support it correctly in the beginning.
* 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
This code is capable of creating an agent that will bind on the
configured local address. The next steps are to configure the
library in terms of allowed features and prepare call handling.