Change in osmo-msc[master]: add full SDP codec information to the MNCC socket

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

neels gerrit-no-reply at lists.osmocom.org
Sun Nov 3 23:21:21 UTC 2019


neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-msc/+/15953 )


Change subject: add full SDP codec information to the MNCC socket
......................................................................

add full SDP codec information to the MNCC socket

This way osmo-msc can benefit from the complete codec information received via
SIP, which was so far terminated at osmo-sip-connector. osmo-sip-connector
could/should have translated the received SDP to MNCC bearer_cap, but this was
never implemented properly. Since osmo-msc already handles SDP towards the MGW,
it makes most sense to pass SDP to osmo-msc transparently.

To be able to send a valid RTP IP:port in the SDP upon the first MNCC_SETUP_IND
going out, move the CN side CRCX to the very start of establishing a voice
call. As a result, first create MGW conns for both RAN and CN before starting.

The voice_call_full.msc chart shows the change in message sequence for MO and
MT voice calls.

Implement cc_sdp.c, which accumulates codec information from various sources
(MS, BSS, Assignment, remote call leg) and provides filtering to get the
available set of codecs at any point in time.

Implement codec_sdp_cc_t9n.c, to translate between SDP and the various
libosmo-mgcp-client, CC and BSSMAP representations of codecs:
- Speech Version,
- Permitted Speech,
- Speech Codec Type,
- default Payload Type numbers,
- enum mgcp_codecs,
- FR/HR compatibility
- SDP audio codec names,
- various AMR configurations.
A codec_map lists these relations in one large data record.
Various functions provide conversions by traversing this map.

Add trans->cc.mnccc_release_sent: so far, avoiding to send an MNCC release
during trans_free() was done by setting the callref = 0. But that also skips CC
Release. On codec mismatch, we send a specific MNCC error code but still want a
normal CC Release: hence send the MNCC message, set mnccc_release_sent = true
and do normal CC Release in trans_free().
(A better way to do this would be to adopt the mncc_call FSM from inter-MSC
handover also for local voice calls, but that is out of scope for now. I want
to try that soon, as time permits.)

Change-Id: I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f
---
M doc/sequence_charts/voice_call_full.msc
M include/osmocom/msc/Makefile.am
M include/osmocom/msc/call_leg.h
A include/osmocom/msc/cc_sdp.h
A include/osmocom/msc/codec_sdp_cc_t9n.h
M include/osmocom/msc/gsm_04_08.h
M include/osmocom/msc/msc_a.h
M include/osmocom/msc/msc_ho.h
M include/osmocom/msc/rtp_stream.h
M include/osmocom/msc/sdp_msg.h
M include/osmocom/msc/transaction.h
M src/libmsc/Makefile.am
M src/libmsc/call_leg.c
A src/libmsc/cc_sdp.c
A src/libmsc/codec_sdp_cc_t9n.c
M src/libmsc/gsm_04_08_cc.c
M src/libmsc/mncc_call.c
M src/libmsc/msc_a.c
M src/libmsc/msc_ho.c
M src/libmsc/msc_t.c
M src/libmsc/rtp_stream.c
M src/libmsc/sdp_msg.c
M tests/msc_vlr/msc_vlr_test_call.c
M tests/msc_vlr/msc_vlr_test_call.err
M tests/msc_vlr/msc_vlr_tests.c
M tests/msc_vlr/msc_vlr_tests.h
M tests/sdp_msg/sdp_msg_test.ok
27 files changed, 5,485 insertions(+), 463 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/53/15953/1


-- 
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/15953
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I8c3b2de53ffae4ec3a66b9dabf308c290a2c999f
Gerrit-Change-Number: 15953
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20191103/173b6643/attachment.htm>


More information about the gerrit-log mailing list