Project

General

Profile

Actions
Copy link

Bug #6216

closed

mobile: MT calls not working anymore

Added by fixeria 7 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
fixeria
Category:
OsmocomBB mobile (host)
Target version:
-
Start date:
10/10/2023
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

With recent osmocom-bb (22e79a87faaa8137e559908d4f90037603fb377a) mobile originating calls work, but mobile terminated do not.

From what I can see, the mobile fails to send CC messages, likely due to "Message unhandled at this state" errors:

DMNCC INFO mnccms.c:114  half rate v3 not supported
DMNCC INFO mnccms.c:127  net suggests unknown speech version 11
DMNCC INFO mnccms.c:104  net suggests full rate v1
DMNCC INFO mnccms.c:439  only supported full rate codec is given, using it
DMNCC INFO mnccms.c:455 Incoming call (from 15843 callref 80000001)
DMNCC INFO mnccms.c:149  support TCH/F only
DCC INFO gsm48_cc.c:894 sending CALL CONFIRMED (proceeding)
DCC DEBUG gsm48_cc.c:237 new state CALL_PRESENT -> MO_TERM_CALL_CONF
DCC INFO gsm48_cc.c:176 Sending 'CALL_CONF' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96) 
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state.  <-- (!)
DMNCC INFO mnccms.c:476 Ring!
DCC INFO gsm48_cc.c:925 sending ALERTING
DCC DEBUG gsm48_cc.c:237 new state MO_TERM_CALL_CONF -> CALL_RECEIVED
DCC INFO gsm48_cc.c:176 Sending 'ALERTING' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96) 
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state.  <-- (!)

Same happens when I try to answer the call:

DCC INFO gsm48_cc.c:956 sending CONNECT
DCC INFO gsm48_cc.c:340 starting timer T313 with 30 seconds
DCC DEBUG gsm48_cc.c:237 new state CALL_RECEIVED -> CONNECT_REQUEST
DCC INFO gsm48_cc.c:176 Sending 'CONNECT' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96)
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state.  <-- (!)

Please find a PCAP (with GSMTAP logging) attached.

Files

obb_mobile_mt_fail.pcapng.gz obb_mobile_mt_fail.pcapng.gz 33 KB fixeria, 10/09/2023 07:58 PM
obb_mobile_mt_release.pcapng.gz obb_mobile_mt_release.pcapng.gz 69.8 KB fixeria, 10/10/2023 12:53 PM

Related issues

Related to OsmocomBB - Feature #4396: Circuit Switched Data (CSD) Support in osmocom-bbResolvedfixeria02/13/2020

Actions
Actions
Copy link
 #1

Updated by fixeria 7 months ago

  • Related to Feature #4396: Circuit Switched Data (CSD) Support in osmocom-bb added
Actions
Copy link
 #2

Updated by fixeria 7 months ago

  • Category set to OsmocomBB mobile (host)
  • Status changed from New to Feedback
  • Assignee set to fixeria
  • % Done changed from 0 to 100

This is a regression caused by recently merged patch:

https://gerrit.osmocom.org/q/I12454cab06c105ccd9e2495e3a6f0640f2884885

Here is a patch from jolly, which fixes the problem for me:

https://gerrit.osmocom.org/c/osmocom-bb/+/34705 Provide create_conn_and_push_mm_hdr() with correct SAPI [NEW]

The MT calls are still not working and getting dropped immediately, but this is another problem.

Actions
Copy link
 #3

Updated by fixeria 7 months ago

fixeria wrote in #note-2:

The MT calls are still not working and getting dropped immediately, but this is another problem.

This time it looks more like a problem on the network side.
As can be seen from the attached PCAP, it's actually the network sending CC Release (see frame 1765).

GSM A-I/F DTAP - Release
    Protocol Discriminator: Call Control; call related SS messages (3)
        .... 0011 = Protocol discriminator: Call Control; call related SS messages (0x3)
        0... .... = TI flag: allocated by sender
        .000 .... = TIO: 0
    00.. .... = Sequence number: 0
    ..10 1101 = DTAP Call Control Message Type: Release (0x2d)
    Cause - (47) Resources unavailable, unspecified
        Element ID: 0x08
        Length: 2
        1... .... = Extension: No Extension
        .11. .... = Coding standard: Standard defined for the GSM PLMNS (3)
        ...0 .... = Spare bit(s): 0
        .... 0001 = Location: Private network serving the local user (0x1)
        1... .... = Extension: No Extension
        .010 1111 = DTAP Cause: Cause: (47) Resources unavailable, unspecified
Actions
Copy link
 #4

Updated by fixeria 7 months ago

What I also noticed is that the Bearer Capability IE (see frame 1586) looks unusual and does not match what the calling side is sending:

    Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
        Element ID: 0x04
        Length: 5
        Octet 3
            0... .... = Extension: Extended
            .11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
            ...0 .... = Coding standard: GSM standardized coding
            .... 0... = Transfer mode: circuit
            .... .000 = Information transfer capability: Speech (0x0)
        Octets 3a - Speech Versions
            0... .... = Extension: Extended
            .0.. .... = Coding: octet used for extension of information transfer capability
            ..00 .... = Spare bit(s): 0
            .... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
            0... .... = Extension: Extended
            .0.. .... = Coding: octet used for extension of information transfer capability
            ..00 .... = Spare bit(s): 0
            .... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
            0... .... = Extension: Extended
            .0.. .... = Coding: octet used for extension of information transfer capability
            ..00 .... = Spare bit(s): 0
            .... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
            1... .... = Extension: No Extension
            .0.. .... = Coding: octet used for extension of information transfer capability
            ..00 .... = Spare bit(s): 0
            .... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)

The calling SE K800i definitely does not support GSM half rate speech version 6(OHR AMR)...

Actions
Copy link
 #5

Updated by fixeria 7 months ago

The reason why MT call fails is actually codec mismatch:

  • the calling phone gets assigned a TCH/AFS (AMR) channel;
  • the called phone responds to paging and indicates that only TCH/FS is supported;
  • the called phone gets assigned a TCH/FS channel;
  • osmo-msc detects codec mismatch and aborts the call.

This is a problem on the core network side, and there's nothing we can do about that here.

Actions
Copy link
 #6

Updated by fixeria 7 months ago

  • Status changed from Feedback to Resolved

The patch has been merged. MT calls work again for me.

Actions
Copy link

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)