Copy the m_mode before freeing the parser.
Address sanitizer aborted with:
20210601033017695 DSIP INFO re-INVITE for call 854A5CDA8037073 (sip.c:192)
=================================================================
==8583==ERROR: AddressSanitizer: heap-use-after-free on address 0x612000003250 at pc 0x55c3b4624dc5 bp 0x7ffe8a4464d0 sp 0x7ffe8a4464c8
READ of size 8 at 0x612000003250 thread T0
#0 0x55c3b4624dc4 in sdp_get_sdp_mode ../../../src/osmo-sip-connector/src/sdp.c:72
#1 0x55c3b462be9e in sip_handle_reinvite ../../../src/osmo-sip-connector/src/sip.c:202
#2 0x55c3b462d676 in nua_callback ../../../src/osmo-sip-connector/src/sip.c:397
[...]
Change-Id: I4c48832f01e61e98536de8f164ab5a3caa64f34a
Also removes a comment in sdp_create_file() about the
IP address in o= and c= having to be the same.
It is completely legal in SDP and often normal for the
originator and the connection information IP to be different.
Change-Id: I057573467c335fc27ead391c0bb4c775f2f6ba0a
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
This enables call hold implemented by subsequent commits
Prior to this commit, osmo-sip-connector would not send
any media mode attribute in the sdp. After this commit
we will by default always include a=sendrecv.
Given that a media mode attribute of "sendrecv" is default
and implicit it its absense, this does not represent any
functional change.
Change-Id: Ib4212d0174955042e7d80d3744ce632a4942ccb2
rfc4867 8.2:
octet-align: Permissible values are 0 and 1. If 1, octet-aligned
operation SHALL be used. If 0 or if not present,
bandwidth-efficient operation is employed.
We don't have any support for AMR BE mode, but if we don't
send this the other end expects BE mode and can't decode the stream
Change-Id: I938758ac4ec55db9223e3da6c3c277e8fa670055
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.
Neels Hofmeyr
Pau Espin
Keith Whyte