Feature #6258
openif MT call leg does not support the assigned codec, re-assign to a compatible codec
80%
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
Related issues
Updated by neels 5 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
Updated by neels 5 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.
Updated by neels 5 months ago
- File 2g3g_codec_reassignment.pcapng 2g3g_codec_reassignment.pcapng added
- % Done changed from 60 to 80
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.
Updated by neels 5 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 || mgcpstarting 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.
Updated by neels 4 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.
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.
Updated by neels 4 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
