Project

General

Profile

Actions

Feature #6258

open

if MT call leg does not support the assigned codec, re-assign to a compatible codec

Added by neels 3 months ago. Updated about 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/16/2023
Due date:
% Done:

80%

Resolution:
Spec Reference:

Description

This is the last missing piece that allows osmo-msc to make good TFO choices.

Since the famous "codecs patches" were merged, osmo-msc properly gathers codec options and limitations.
But the MO call leg still assigns a voice channel before getting a response from the MT call leg,
and it has no capability to adjust the MO call leg's codec in case the MT side needs a different codec.

At some point I thought we would have to do the Assignment at a later time.
But now I think it would be better to implement re-assignment (BSC: Channel Mode Modify), switching the codec.
I realized that if we wait for the MT side to answer before assigning a channel,
there can never be any automated voice saying "the caller you have dialled is currently unavailable...".
(We have no such automated voice in osmocom, but it is an indicator for what would make more sense in general.)


Files

2g3g_codec_reassignment.pcapng 2g3g_codec_reassignment.pcapng 7.18 MB first ever actual dynamic codec resolution where MO adjusts to MT's codec choice with osmo-msc and SIP neels, 12/10/2023 03:17 AM
2g3g_codec_reassignment.tgz 2g3g_codec_reassignment.tgz 1.14 MB neels, 12/10/2023 03:57 AM

Related issues

Related to OsmoBSC - Bug #6328: Channel Mode Modify fails to modify the RTP payload type numberNew01/12/2024

Actions
Actions #1

Updated by neels 3 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 60

Initial patches up for testing:
https://gerrit.osmocom.org/q/topic:reass

Actions #2

Updated by neels 3 months ago

We still need to check:

  • does OsmoBSC play along nicely with the re-assignment (it should AFAICT).
  • effects on MGCP: there may now be more codecs than just the assigned one in
    the MGCP towards the MGW. See if that checks out.
  • effects on 3G: make sure the feature doesn't confuse IuUP handling.
Actions #3

Updated by neels 3 months ago

I have now successfully tested a dynamic re-assignment of codec!
I'll polish up and submit the various patches, and then we'll have bidirectional dynamic codec negotiation across call legs.
It's been a very long time that I've been waiting to achieve this... nice.

Actions #4

Updated by neels 3 months ago

  • File 2g3g_codec_reassignment.tgz added

about the attached pcap:
you can see what is cool about this pcap with this wireshark filter

sip || gsmtap_log.string contains "x MNCC MNCC_" || bssap || gsm_abis_rsl || mgcp

starting with the INVITE-OK from MT to MO in packet 5596:
It responds with only AMR in its SDP, while MO has already assigned a GSM-FR lchan.
The packets following down to 6595 show how the new codec choice ripples through MGCP and Abis while the call connects undisturbed.

I actually speak in the pcap, and confirmed that both sides sounded good.

In the pcap, you can also follow how the 3G IuUP gets converted to 2G AMR-FR.

2G was configured to use only TCH-F timeslots, with 'msc' / 'codec-list fr1 fr3' in osmo-bsc.cfg:
support GSM-FR and AMR, prefer GSM-FR (on purpose, to provoke a codec mismatch).

With a 3G hNodeB that supports AMR-HR, interop with TCH/H is also possible.

Related patches are
https://gerrit.osmocom.org/q/topic:fmtp
https://gerrit.osmocom.org/q/topic:reass

When these are merged, "the only thing" still missing: we cannot yet intelligently switch AMR rates
(on 2G: choose and switch TCH/H or TCH/F and codec mode bits; on 3G: choose matching SDUs).
That's mostly relevant to match 2G with 3G.

Actions #5

Updated by neels 3 months ago

  • File deleted (2g3g_codec_reassignment.tgz)
Actions #7

Updated by neels about 2 months ago

I just realized a curiosity in the RTP payload type numbers, visible in the attached pcap.

The codec is re-assigned successfully, and during the test, voice quality was clear on both sides.
But both BTS and BSC fail to reflect the modified RTP payload in the payload type number.

It seems that both correctly change the payload to AMR, but still stick with the unchanged payload type number PT=3.
When following an IuUP/RTP packet from the nano3G to the BTS,
  • there is a change in the payload bytes from IuUP PT=96 to plain AMR PT=112
    (packets 16090, 16093, 16103)
  • but then the identical payload is forwarded as PT=3, which would have to be GSM FR1.
    (16117, 16122)

Here is a call chain analysis:

--- Call chain 1
192.168.2.78:16384<->192.168.2.52:20004<->192.168.2.52:20006<->127.0.0.6:10006<->127.0.0.6:10004<->127.0.0.6:10008<->127.0.0.6:10010<->192.168.2.52:40006<->192.168.2.52:40004<->192.168.2.218:1028
rtpbridge/1@bsc0
 | 892B666D: r:192.168.2.78:16384 <-> l:192.168.2.52:20004 None 'audio 20004 RTP/AVP 3' tx<-{'-': 1, '3': 272} rx->{'3': 874}
    - CRCX None None                                                          only payload-type-nr=3 ^^^^^^^^^^^^^^^^^^^^^^^
    - CRCX-OK audio 20004 RTP/AVP 3 None                                      between BTS and BSC, both directions
    - MDCX audio 16384 RTP/AVP 3 None
    - MDCX-OK audio 20004 RTP/AVP 3 None
 | 573D6998: l:192.168.2.52:20006 <-> r:127.0.0.6:10006 None 'audio 20006 RTP/AVP 3' tx->{'3': 868} rx<-{'-': 2, '3': 5, '112': 267}
    - CRCX audio 10006 RTP/AVP 3 None                             sending only PT=3 to MSC ^^^^^^  from MSC: chg to PT=112 ^^^^^
    - CRCX-OK audio 20006 RTP/AVP 3 None
         <--- missing MDCX to AMR, from BSC to MGW@BSC
rtpbridge/1@msc
 | 8A4A8CA2: r:192.168.2.52:20006 <-> l:127.0.0.6:10006 'AMR' 'audio 10006 RTP/AVP 112' tx<-{'-': 2, '3': 5, '112': 267} rx->{'3': 867}
    - CRCX None None                            MSC receives only PT=3, sends a few PT=3 and then switches to AMR PT=112 ^^^
    - CRCX-OK audio 10006 RTP/AVP 112 None
    - MDCX audio 20006 RTP/AVP 3 None
    - MDCX-OK audio 10006 RTP/AVP 3 None
    - MDCX audio 20006 RTP/AVP 112 AMR
    - MDCX-OK audio 10006 RTP/AVP 112 AMR
 | E605366F: l:127.0.0.6:10004 <-> r:127.0.0.6:10008 'AMR' 'audio 10004 RTP/AVP 112' tx->{'-': 1, '112': 611} rx<-{'112': 272}
    - CRCX None None                                  The received PT=3 magically all turn to PT=112 ^^^^^^^^
    - CRCX-OK audio 10004 RTP/AVP 112 None
    - MDCX audio 10008 RTP/AVP 112 AMR
    - MDCX-OK audio 10004 RTP/AVP 112 AMR
rtpbridge/2@msc
 | 07415E8C: r:127.0.0.6:10004 <-> l:127.0.0.6:10008 'AMR' 'audio 10008 RTP/AVP 112' tx<-{'-': 1, '112': 272} rx->{'-': 1, '112': 611}
    - CRCX None None
    - CRCX-OK audio 10008 RTP/AVP 112 None
    - MDCX audio 10004 RTP/AVP 3 112 AMR
    - MDCX-OK audio 10008 RTP/AVP 112 AMR
 | 331727C8: l:127.0.0.6:10010 <-> r:192.168.2.52:40006 'VND.3GPP.IUFP' 'audio 10010 RTP/AVP 96' tx->{'96': 604} rx<-{'96': 273}
    - CRCX None None
    - CRCX-OK audio 10010 RTP/AVP 96 None
    - MDCX audio 40006 RTP/AVP 96 VND.3GPP.IUFP
    - MDCX-OK audio 10010 RTP/AVP 96 VND.3GPP.IUFP
rtpbridge/1@hnbgw
 | 452D9227: r:127.0.0.6:10010 <-> l:192.168.2.52:40006 'VND.3GPP.IUFP' 'audio 40006 RTP/AVP 96' tx<-{'96': 273} rx->{'96': 604}
    - CRCX audio 10010 RTP/AVP 96 VND.3GPP.IUFP
    - CRCX-OK audio 40006 RTP/AVP 96 VND.3GPP.IUFP
 | 77C10E76: l:192.168.2.52:40004 <-> r:192.168.2.218:1028 'VND.3GPP.IUFP' 'audio 40004 RTP/AVP 96' tx->{'96': 604} rx<-{'96': 273}
    - CRCX None None
    - CRCX-OK audio 40004 RTP/AVP 96 None
    - MDCX audio 1028 RTP/AVP 96 VND.3GPP.IUFP
    - MDCX-OK audio 40004 RTP/AVP 96 VND.3GPP.IUFP

Things to look at:

  • osmo-bts: on Channel Mode Modify to a different codec, do we fail to change the PT number in outgoing RTP?
  • osmo-bsc: on Assignment Request from the MSC that modifies the codec, send MDCX to the MGW to adjust
  • osmo-mgw: how can AMR magically become GSM-FR between two endpoint conns

osmo-msc is doing the right thing, but we're lucky that it even works.

Actions #8

Updated by neels about 2 months ago

neels wrote in #note-7:

  • osmo-bts: on Channel Mode Modify to a different codec, do we fail to change the PT number in outgoing RTP?

osmo-bts receives the payload type number in ip.access CRCX or MDCX, so this is also osmo-bsc's task.

  • osmo-bsc: on Assignment Request from the MSC that modifies the codec, send MDCX to the MGW to adjust

Apparently osmo-bsc should do both MGCP MDCX to MGW and ipacc.MDCX to BTS to change the PT number, --> #6328

Actions #9

Updated by neels about 2 months ago

  • Related to Bug #6328: Channel Mode Modify fails to modify the RTP payload type number added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)