Bug #6110
closedmodem-to-modem data call establishment failure
Added by fixeria 10 months ago. Updated 9 months ago.
100%
Description
I am trying to establish a modem-to-modem data call, but somehow it fails even before paging procedure completes. Please see the attached PCAP file, which contains GSMTAP logging of osmo-{msc,bsc}, GSMTAP Um logging of osmo-bts-trx, and all the related signalling between the RAN/CNI components.
osmo-bts-trx 0a2b0a20b3de24b6c93ce2551f0e08c23c2f62db
osmo-bsc 1ad32f74305a36e36be975d9be9e31f94748d010
osmo-msc 482f0bd5a1812838c4ae1a2546dedaddc5fff87d
osmo-mgw af67178581bbbb89cf63ffc5af162b9f82fa6cdd
osmo-msc is configured to use the built-in MNCC.
Both osmo-bsc and osmo-msc are talking to one osmo-mgw instance.
Looking at the PCAP, I would say everything goes as usual until frame 1174:
1173 13.531659593 127.0.0.1 → 127.0.1.1 GSMTAP 191 (call 80000001) Received message MNCC_RTP_CREATE
1174 13.531670651 127.0.0.1 → 127.0.1.1 GSMTAP 194 (call 80000001) Message 'MNCC_RTP_CREATE' unhandled
1175 13.531681217 127.0.0.1 → 127.0.1.1 GSMTAP 301 msc_a(IMSI-901700000015843:MSISDN-15843:TMSI-0x7D64D922:GERAN-A-4:CM_SERVICE_REQ)[0x563de7902d30]{MSC_A_ST_COMMUNICATING}: - msc_a_ran_dec: now used by 1 (cc)
1176 13.531712766 127.0.0.1 → 127.0.1.1 GSMTAP 257 MGW(mgw) Tx MGCP: r=127.0.0.1:2428<->l=127.0.0.1:2427: len=167 'MDCX 3 rtpbridge/1@mgw MGCP 1.0\r\nC: 2\r\nI: '...
1177 13.531719487 127.0.0.1 → 127.0.0.1 MGCP/SDP 209 MDCX 3 rtpbridge/1@mgw MGCP 1.0
1178 13.531820600 127.0.0.1 → 127.0.0.1 MGCP 54 534 3 FAIL
1179 13.531867115 127.0.0.1 → 127.0.1.1 GSMTAP 178 MGW(mgw) MGCP client: Rx 534 3 FAIL
1180 13.531887548 127.0.0.1 → 127.0.1.1 GSMTAP 237 MGCP_CONN(RTP_TO_RAN)[0x563de79017f0]{ST_MDCX_RESP}: MGW/MDCX: response yields error: 534 FAIL
1181 13.531898548 127.0.0.1 → 127.0.1.1 GSMTAP 237 MGCP_CONN(RTP_TO_RAN)[0x563de79017f0]{ST_MDCX_RESP}: Terminating (cause = OSMO_FSM_TERM_ERROR)
osmo-msc sends an MDCX message, which gets rejected by osmo-mgw:
MDCX 3 rtpbridge/1@mgw MGCP 1.0 C: 2 I: 27F4102A M: sendrecv v=0 o=- 2 23 IN IP4 127.0.0.1 s=- c=IN IP4 127.0.0.1 t=0 0 m=audio 4006 RTP/AVP 3 a=ptime:20
Below is the related osmo-mgw logging (sorry, I forgot to enable GSMTAP logging for it):
Started Osmocom Media Gateway (MGW). DLGLOBAL NOTICE telnet_interface.c:88 Available via telnet 127.0.0.1 4243 DLCTRL NOTICE control_if.c:1014 CTRL at 127.0.0.1 4267 DLMGCP NOTICE mgw_main.c:397 Configured for MGCP, listen on 127.0.0.1:2428 DLMGCP INFO mgcp_protocol.c:441 CRCX: executing request handler "CreateConnection" for endpoint resource "rtpbridge/1@mgw" DLMGCP NOTICE mgcp_protocol.c:881 endpoint:rtpbridge/1@mgw CRCX: creating new connection ... DLMGCP NOTICE mgcp_protocol.c:1135 endpoint:rtpbridge/1@mgw CI:1163B083 CRCX: connection successfully created DLMGCP INFO mgcp_protocol.c:441 CRCX: executing request handler "CreateConnection" for endpoint resource "rtpbridge/1@mgw" DLMGCP NOTICE mgcp_protocol.c:881 endpoint:rtpbridge/1@mgw CRCX: creating new connection ... DLMGCP NOTICE mgcp_protocol.c:1135 endpoint:rtpbridge/1@mgw CI:27F4102A CRCX: connection successfully created DLMGCP INFO mgcp_protocol.c:441 CRCX: executing request handler "CreateConnection" for endpoint resource "rtpbridge/2@mgw" DLMGCP NOTICE mgcp_protocol.c:881 endpoint:rtpbridge/2@mgw CRCX: creating new connection ... DLMGCP NOTICE mgcp_protocol.c:1135 endpoint:rtpbridge/2@mgw CI:565BD5B6 CRCX: connection successfully created DLMGCP INFO mgcp_protocol.c:441 MDCX: executing request handler "ModifiyConnection" for endpoint resource "rtpbridge/2@mgw" DLMGCP NOTICE mgcp_protocol.c:1169 endpoint:rtpbridge/2@mgw MDCX: modifying existing connection ... DLMGCP NOTICE mgcp_sdp.c:432 endpoint:rtpbridge/2@mgw CI:565BD5B6 Got media info via SDP: port:16384, addr:127.0.0.1, duration:20, payload-types:120=CLEARMODE DLMGCP NOTICE mgcp_protocol.c:1372 endpoint:rtpbridge/2@mgw CI:565BD5B6 MDCX: connection successfully modified DLMGCP INFO mgcp_protocol.c:441 CRCX: executing request handler "CreateConnection" for endpoint resource "rtpbridge/2@mgw" DLMGCP NOTICE mgcp_protocol.c:881 endpoint:rtpbridge/2@mgw CRCX: creating new connection ... DLMGCP NOTICE mgcp_sdp.c:432 endpoint:rtpbridge/2@mgw CI:92F4A92C Got media info via SDP: port:4002, addr:127.0.0.1, duration:20, payload-types:120=CLEARMODE DLMGCP NOTICE mgcp_protocol.c:1135 endpoint:rtpbridge/2@mgw CI:92F4A92C CRCX: connection successfully created DRTP ERROR mgcp_network.c:978 (rtpbridge/1@mgw I:27F4102A) RTP packet too short (1 < 12) DLMGCP INFO mgcp_protocol.c:441 MDCX: executing request handler "ModifiyConnection" for endpoint resource "rtpbridge/1@mgw" DLMGCP NOTICE mgcp_protocol.c:1169 endpoint:rtpbridge/1@mgw MDCX: modifying existing connection ... DLMGCP NOTICE mgcp_sdp.c:432 endpoint:rtpbridge/1@mgw CI:27F4102A Got media info via SDP: port:4006, addr:127.0.0.1, duration:20, payload-types:3=GSM DLMGCP ERROR mgcp_protocol.c:833 endpoint:rtpbridge/1@mgw CI:27F4102A MDCX: codec negotiation failure DLMGCP INFO mgcp_protocol.c:441 DLCX: executing request handler "DeleteConnection" for endpoint resource "rtpbridge/1@mgw" DLMGCP NOTICE mgcp_protocol.c:1403 endpoint:rtpbridge/1@mgw DLCX: deleting connection(s) ... DLMGCP NOTICE mgcp_protocol.c:1526 endpoint:rtpbridge/1@mgw DLCX: connection successfully deleted DLMGCP INFO mgcp_protocol.c:441 DLCX: executing request handler "DeleteConnection" for endpoint resource "rtpbridge/1@mgw" DLMGCP NOTICE mgcp_protocol.c:1403 endpoint:rtpbridge/1@mgw DLCX: deleting connection(s) ... DLMGCP NOTICE mgcp_protocol.c:1526 endpoint:rtpbridge/1@mgw DLCX: connection successfully deleted DLMGCP INFO mgcp_protocol.c:441 DLCX: executing request handler "DeleteConnection" for endpoint resource "rtpbridge/2@mgw" DLMGCP NOTICE mgcp_protocol.c:1403 endpoint:rtpbridge/2@mgw DLCX: deleting connection(s) ... DLMGCP NOTICE mgcp_protocol.c:1526 endpoint:rtpbridge/2@mgw DLCX: connection successfully deleted DLMGCP INFO mgcp_protocol.c:441 DLCX: executing request handler "DeleteConnection" for endpoint resource "rtpbridge/2@mgw" DLMGCP NOTICE mgcp_protocol.c:1403 endpoint:rtpbridge/2@mgw DLCX: deleting connection(s) ... DLMGCP NOTICE mgcp_protocol.c:1526 endpoint:rtpbridge/2@mgw DLCX: connection successfully deleted
Files
| modem2modem_call_failure.pcapng.gz | modem2modem_call_failure.pcapng.gz | 92.6 KB | fixeria, 07/21/2023 07:20 PM | ||
| modem2modem_call_failure3.pcapng.gz | modem2modem_call_failure3.pcapng.gz | 120 KB | fixeria, 07/25/2023 12:25 PM | ||
| modem2modem_call_connect_rlp.pcapng.gz | modem2modem_call_connect_rlp.pcapng.gz | 281 KB | fixeria, 07/25/2023 08:24 PM | ||
| modem2modem_call_connect_rlp_gsmtap.pcapng.gz | modem2modem_call_connect_rlp_gsmtap.pcapng.gz | 306 KB | fixeria, 07/26/2023 09:42 PM | ||
| modem2modem_call_connect_rlp_gsmtap_v2.pcapng.gz | modem2modem_call_connect_rlp_gsmtap_v2.pcapng.gz | 330 KB | fixeria, 07/26/2023 11:04 PM |
Related issues
Updated by fixeria 10 months ago
- Related to Feature #4394: Circuit Switched Data (CSD) Support in osmo-msc added
Updated by fixeria 10 months ago
- Blocks Feature #1572: Circuit Switched Data (CSD) Support in osmo-bts added
Updated by osmith 10 months ago
- Status changed from In Progress to Feedback
- Assignee changed from osmith to fixeria
GSMTAP 194 (call 80000001) Message 'MNCC_RTP_CREATE' unhandled
This looks unrelated, I would assume it happens with regular call as well.
So it seems the problem is, that OsmoMSC establishes two legs with CRCX payload-types:120=CLEARMODE as expected for CSD. But then the MDCX has payload-types:3=GSM which is wrong, leading to the codec negotiation failure in OsmoMGW.
I've tried to trace the code where this comes from in OsmoMSC (and specifically the internal MNCC handler). Due to the several abstraction layers until reaching the log message in packet 1176 from libosmo-mgcp, "MGW Tx MGCP: r=127.0.0.1:2428<->l=127.0.0.1:2427: len=167 'MDCX 3 rtpbridge/1@mgw MGCP 1.0\r\nC: 2\r\nI: '..." it is hard to do that without more logging.
Can you do the following?- Create another pcap with DCC debug logging enabled in OsmoMSC, as LOG_RTPS from rtp_stream.c logs there.
- Try it with an external MNCC and if it fails elsewhere open another issue with pcap
Updated by fixeria 10 months ago
Hi Oliver,
osmith wrote in #note-5:
GSMTAP 194 (call 80000001) Message 'MNCC_RTP_CREATE' unhandled
This looks unrelated, I would assume it happens with regular call as well.
I don't remember seeing this message with a regular voice call. It might be related the the problem, so this is why I mentioned it.
So it seems the problem is, that OsmoMSC establishes two legs with CRCX payload-types:120=CLEARMODE as expected for CSD. But then the MDCX has payload-types:3=GSM which is wrong, leading to the codec negotiation failure in OsmoMGW.
Looks so, yes. It's unclear why osmo-msc sends MDCX with payload-types:3=GSM.
Can you do the following?
- Create another pcap with DCC debug logging enabled in OsmoMSC, as LOG_RTPS from rtp_stream.c logs there
I was running the tests with logging level set-all debug in the log gsmtap target, so all DCC logging should be already there.
I just re-checked the PCAP file I attached and confirmed that it does contain DCC logging, including LOGL_DEBUG.
- Try it with an external MNCC and if it fails elsewhere open another issue with pcap
Uh, I am afraid that would be problematic for several reasons. It's been a while since I was running an external MNCC handler and a PBX, so I don't really want to spend hours messing up with configuring some FreeSwitch/Asterisk (even though I had a backup of config files for FreeSwitch somewhere). I am also not sure if these PBX projects support data calls.
I can meanwhile try to reproduce the problem in ttcn3-msc-test, if that helps. Should be relatively easy.
Updated by shadowcaster 10 months ago
fixeria wrote in #note-6:
Uh, I am afraid that would be problematic for several reasons. It's been a while since I was running an external MNCC handler and a PBX, so I don't really want to spend hours messing up with configuring some FreeSwitch/Asterisk (even though I had a backup of config files for FreeSwitch somewhere). I am also not sure if these PBX projects support data calls.
Asterisk does not support RFC4040 clearmode: http://lists.digium.com/pipermail/asterisk-dev/2019-March/077238.html
as a workaround long time ago people were patching existing codecs to enable clearmode/pass-throught https://marc.info/?l=asterisk-video&m=122285924014277
Freeswitch has clearmode "codec module".
Updated by fixeria 10 months ago
fixeria wrote in #note-6:
I can meanwhile try to reproduce the problem in ttcn3-msc-test, if that helps. Should be relatively easy.
So I have a Work-in-Progress testcase which enables the internal MNCC handler and spawns two BSC_ConnHdlr components: one is the calling side, another is the called side. I was a bit surprised to discover that all our MO/MT call related testcases are for the external MNCC mode of operation, there is no testing coverage for the internal MNCC at all. This is sad, but now it's a chance to fill this gap ;)
fixeria wrote in #note-6:
... It's unclear why osmo-msc sends MDCX with
payload-types:3=GSM.
Meanwhile, looking at the attached PCAP again (and applying the knowledge I gained while writing a new TTCN-3 testcase) I realized that the MDCX with payload-types:3=GSM is actually triggered by the BSSMAP Assignment Complete message containing the Speech Codec (Choosen) IE with Codec Type: GSM FR (0). This message is originated by the calling modem itself, so it could be that osmo-msc is not really the culprit here.
Updated by fixeria 10 months ago
fixeria wrote in #note-9:
Meanwhile, looking at the attached PCAP again (and applying the knowledge I gained while writing a new TTCN-3 testcase) I realized that the
MDCXwithpayload-types:3=GSMis actually triggered by theBSSMAP Assignment Completemessage containing theSpeech Codec (Choosen)IE withCodec Type: GSM FR (0). This message is originated by the calling modem itself, so it could be that osmo-msc is not really the culprit here.
Not the whole message is originated from the modem though, the Speech Codec IE is likely added by osmo-bsc:
Frame 1058: 81 bytes on wire (648 bits), 81 bytes captured (648 bits) on interface lo, id 0
...
IPA protocol ip.access, type: RSL
DataLen: 12
Protocol: RSL (0x00)
Radio Signalling Link (RSL)
0000 001. = Message discriminator: Radio Link Layer Management messages (1)
.... ...1 = T bit: Considered transparent by BTS
.000 0010 = Message type: DATA INDication (0x02)
Channel number IE
Element identifier: Channel Number (0x01)
0000 1... = C-bits: Bm + ACCH (1)
.... .010 = Time slot number (TN): 2
Link Identifier IE
Element identifier: Link Identifier (0x02)
00.. .... = channel type: Main signalling channel (FACCH or SDCCH) (0)
..0. .... = Not applicable (NA): Applicable
...0 0... = Priority: Normal Priority (0)
.... .000 = SAPI: 0
L3 Information IE
Element identifier: L3 Information (0x0b)
Length: 3
Link Layer Service Data Unit (L3 Message)
GSM A-I/F DTAP - Assignment Complete
Protocol Discriminator: Radio Resources Management messages (6)
.... 0110 = Protocol discriminator: Radio Resources Management messages (0x6)
0000 .... = Skip Indicator: No indication of selected PLMN (0)
DTAP Radio Resources Management Message Type: Assignment Complete (0x29)
RR Cause
RR cause value: Normal event (0)
Frame 1131: 122 bytes on wire (976 bits), 122 bytes captured (976 bits) on interface lo, id 0
...
BSSAP
Message Type: BSS Management (0x00)
Length: 18
GSM A-I/F BSSMAP - Assignment Complete
Message Type Assignment Complete
RR Cause
Element ID: 0x15
RR cause value: Normal event (0)
Chosen Channel
Element ID: 0x21
1011 .... = Channel mode: data, 12.0 kbit/s radio interface rate (11)
.... 1000 = Channel: 1 Full rate TCH (8)
Chosen Encryption Algorithm - No encryption used
Element ID: 0x2c
Algorithm Identifier: No encryption used (1)
AoIP Transport Layer Address
Element ID: 0x7c
Length: 6
Transport Layer Address (IPv4): 127.0.0.1
UDP Port: 4006
Speech Codec(Chosen)
Element ID: 0x7e
Length: 1
Speech Codec Element 1 - GSM FR
0... .... = FI(Full IP): AoIP with Compressed speech via RTP/UDP/IP is not supported by the BSS/Not Preferred by the MSC
.0.. .... = PI: PCM over A interface with IP as transport is not supported by the BSS or not preferred by the MSC for this Codec Type
..0. .... = PT: PCM over A-Interface with TDM as transport is not supported by the BSS or not preferred by the MSC for this Codec Type
...0 .... = TF: TFO is not supported by the BSS or TFO support is not preferred by the MSC for this Codec Type
.... 0000 = Codec Type: GSM FR (0)
Undecoded byte number: 92 (0x0050+12)
[Expert Info (Note/Undecoded): Undecoded byte number: 92 (0x0050+12)]
[Undecoded byte number: 92 (0x0050+12)]
[Severity level: Note]
[Group: Undecoded]
Updated by fixeria 10 months ago
- Project changed from OsmoMSC to OsmoBSC
As per 3GPP TS 48.008, section 3.2.1.2 "ASSIGNMENT COMPLETE", the Speech Codec (Chosen) is an optional IE.
Also, from 3GPP TS 48.008, section 3.2.2.104 "Speech Codec":
The Codec Type is valid if at least one of FI, PI or PT is set to ‘1’. If the Codec Type is not valid the Speech Codec Element shall be ignored.
This is exactly our case: all the flags are set to 0.
Updated by fixeria 10 months ago
- Related to Feature #4393: Circuit Switched Data (CSD) Support in osmo-bsc added
Updated by fixeria 10 months ago
Here is an untested patch, which fixes encoding of the Speech Codec Element for data calls:
https://gerrit.osmocom.org/c/osmo-bsc/+/33912 fix send_assignment_complete(): proper SCE encoding for CSD [WIP]
I also submitted a few additional patches for libosmocore.git and osmo-msc.git:
https://gerrit.osmocom.org/c/libosmocore/+/33911 gsm_08_08: define GSM0808_SCT_EXT (separately)
https://gerrit.osmocom.org/c/osmo-msc/+/33913 ran_a_mgcp_codec_from_sc(): cosmetic: remove unneeded breaks [NEW]
https://gerrit.osmocom.org/c/osmo-msc/+/33914 ran_a_mgcp_codec_from_sc(): map GSM0808_SCT_CSD to CODEC_CLEARMODE [NEW]
https://gerrit.osmocom.org/c/osmo-msc/+/33915 ran_a_channel_type_to_speech_codec_list(): set PI/PT for CSD [NEW]
Updated by fixeria 10 months ago
With the abovementioned patches applied, I am getting slightly further:
GSM A-I/F BSSMAP - Assignment Complete
Message Type Assignment Complete
RR Cause
Element ID: 0x15
RR cause value: Normal event (0)
Chosen Channel
Element ID: 0x21
1011 .... = Channel mode: data, 12.0 kbit/s radio interface rate (11)
.... 1000 = Channel: 1 Full rate TCH (8)
Chosen Encryption Algorithm - No encryption used
Element ID: 0x2c
Algorithm Identifier: No encryption used (1)
AoIP Transport Layer Address
Element ID: 0x7c
Length: 6
Transport Layer Address (IPv4): 127.0.0.1
UDP Port: 4012
Speech Codec(Chosen)
Element ID: 0x7e
Length: 3
Speech Codec Element 1
.1.. .... = PI: Transport of PCM over A-Interface via RTP/UDP/IP is supported by the BSS or preferred by the MSC for this Codec Type
..1. .... = PT: Transport of PCM over A-Interface via TDM is supported by the BSS or preferred by the MSC
.... 1111 = Codec Type: Codec Extension (15)
Extended Codec Type: CSData (253)
0... .... = Redundancy Level 2: Not supported
.0.. .... = Redundancy Level 3: Not supported
however osmo-msc is now complaining about an unknown codec:
Application: OsmoMSC
Process ID: 166030
Log Level: ERROR (7)
Subsystem: CC
Source File Name: msc_a.c
Source File Line Number: 1480
String: trans(CC:MO_CALL_PROC IMSI-901700000015843:MSISDN-15843:TMSI-0xBE522FE7:GERAN-A-8:CM_SERVICE_REQ callref-0x80000004 tid-8) Unknown codec in Assignment Complete: CSD\n
Updated by fixeria 10 months ago
fixeria wrote in #note-14:
With the abovementioned patches applied, I am getting slightly further:
[...]
however osmo-msc is now complaining about an unknown codec:
[...]
This patch fixes the error about an unknown codec:
https://gerrit.osmocom.org/c/osmo-msc/+/33919 codec_mapping: codec_map[]: add missing speech codec for CLEARMODE [NEW]
and now I am seeing the called modem being paged, receiving CC SETUP and responding with CC Call Confirmed. However, osmo-msc is still not happy about something and immediately releasing the call after that. I am attaching a new PCAP file.
Updated by fixeria 10 months ago
fixeria wrote in #note-15:
and now I am seeing the called modem being paged, receiving CC SETUP and responding with CC Call Confirmed. However, osmo-msc is still not happy about something and immediately releasing the call after that. I am attaching a new PCAP file.
Some highlights:
- frame 478: calling modem sends CC Setup to MSISDN=41002;
- frame 1310: the called modem responds to paging;
- frame 1443: osmo-msc sends CC Setup to the called modem (MT call from MSISDN=15843);
- frame 1836: the called modem responds with CC Call Confirmed.
Things looking weird:
- the
Bearer Capability 1IE in frame 1443 indicates "Unrestricted digital information (0x1)",- while the
Bearer Capability 1IE in frame 1836 indicates "3.1 kHz audio, ex PLMN (0x2)";
- while the
- the
Bearer Capability 1IE in frame 478 indicates "Radio channel requirement: Full rate support only MS"- the
Bearer Capability 1IE in frame 1443 indicates "Radio channel requirement: Reserved"
- the
Frame 478: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface lo, id 0
...
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
10.. .... = Control Channel: FACCH or SDCCH (0x2)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
Length: 28
GSM A-I/F DTAP - Setup
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
01.. .... = Sequence number: 1
..00 0101 = DTAP Call Control Message Type: Setup (0x05)
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 7
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.0.. .... = Compression: Not Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
1... .... = Extension: No Extension
.00. .... = Access Identity: Octet identifier (0)
...0 1... = Rate Adaption: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
.... .001 = Signalling Access Protocol: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
1... .... = Extension: No Extension
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0000 = Modem type: None
Called Party BCD Number - (41002)
Element ID: 0x5e
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x0)
.... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x1)
Called Party BCD Number: 41002
Low Layer Compatibility 1
Element ID: 0x7c
Length: 6
1... .... = Extension indicator: last octet
.00. .... = Coding standard: ITU-T standardized coding (0x0)
...0 1000 = Information transfer capability: Unrestricted digital information (0x08)
1... .... = Extension indicator: last octet
.00. .... = Transfer mode: Circuit mode (0x0)
...1 0000 = Information transfer rate: 64 kbit/s (0x10)
0... .... = Extension indicator: information continues through the next octet
.01. .... = Layer identification: Layer 1 identifier (0x1)
...0 0001 = User information layer 1 protocol: V.110/I.460/X.30 rate adaption (0x01)
.1.. .... = Layer 1: Asynchronous
..0. .... = Layer 1 in-band negotiation: Not possible
...0 1000 = User rate: 9.6 kbit/s (0x08)
.10. .... = Intermediate rate: Unknown (0x2)
...0 .... = Send data with network independent clock: Not required
.... 0... = Accept data with network independent clock: Not Accepted
.... .0.. = Send data with flow control mechanism: Not required
.... ..0. = Accept data with flow control mechanism: Not Accepted
.0.. .... = Rate adaption header: Not Present
..1. .... = Multiple frame establishment: Supported
...1 .... = mode of operation: Protocol sensitive
.... 1... = Protocol negotiation: Full protocol negotiation
.... .0.. = Message originator: Default assignee
.... ..1. = Negotiation is done: in-band
Call Control Capabilities
Element ID: 0x15
Length: 1
0000 .... = Maximum number of supported bearers: 1
.... 0... = MCAT: The mobile station does not support Multimedia CAT
.... .0.. = ENICM: The mobile station does not support the Enhanced Network-initiated In-Call Modification procedure
.... ..1. = Prolonged Clearing Procedure: Supported
.... ...1 = DTMF: the mobile station supports DTMF as specified in subclause 5.5.7 of TS 24.008
Frame 1443: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits) on interface lo, id 0
...
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
00.. .... = Control Channel: not further specified (0x0)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
Length: 23
GSM A-I/F DTAP - Setup
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
..00 0101 = DTAP Call Control Message Type: Setup (0x05)
Bearer Capability 1 - (Reserved)
Element ID: 0x04
Length: 7
Octet 3
1... .... = Extension: No Extension
.00. .... = Radio channel requirement: Reserved
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.0.. .... = Compression: Not Allowed
..11 .... = Structure: Unstructured (3)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
1... .... = Extension: No Extension
.00. .... = Access Identity: Octet identifier (0)
...0 1... = Rate Adaption: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
.... .000 = Signalling Access Protocol: Reserved (0)
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...0 .... = Number of data bits excluding parity bit if present: 7
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.00. .... = V.110/X.30 rate adaptation Intermediate rate: Reserved (0)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .000 = Parity information: Odd (0)
Octet 6c
1... .... = Extension: No Extension
.00. .... = Connection element: Transparent (0)
...0 0000 = Modem type: None
Calling Party BCD Number - (15843)
Element ID: 0x5c
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x0)
.... 0000 = Numbering plan identification: unknown (0x0)
Calling Party BCD Number: 15843
Called Party BCD Number - (41002)
Element ID: 0x5e
Length: 4
1... .... = Extension: No Extension
.000 .... = Type of number: unknown (0x0)
.... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x1)
Called Party BCD Number: 41002
Frame 1836: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface lo, id 0
...
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
10.. .... = Control Channel: FACCH or SDCCH (0x2)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
Length: 11
GSM A-I/F DTAP - Call Confirmed
Protocol Discriminator: Call Control; call related SS messages (3)
.... 0011 = Protocol discriminator: Call Control; call related SS messages (0x3)
1... .... = TI flag: allocated by receiver
.000 .... = TIO: 0
00.. .... = Sequence number: 0
..00 1000 = DTAP Call Control Message Type: Call Confirmed (0x08)
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 7
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .010 = Information transfer capability: 3.1 kHz audio, ex PLMN (0x2)
Octet 4
1... .... = Extension: No Extension
.0.. .... = Compression: Not Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
1... .... = Extension: No Extension
.00. .... = Access Identity: Octet identifier (0)
...0 0... = Rate Adaption: No rate adaption (0)
.... .001 = Signalling Access Protocol: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
1... .... = Extension: No Extension
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0110 = Modem type: According to ITU-T Rec. V.32
Updated by fixeria 10 months ago
- Project changed from OsmoBSC to OsmoMSC
Here is a diff between frame 478 and frame 1443:
-Frame 478: 134 bytes on wire (1072 bits), 134 bytes captured (1072 bits) on interface lo, id 0
+Frame 1443: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits) on interface lo, id 0
...
BSSAP
Message Type: Direct Transfer (0x01)
Data Link Connection Identifier
- 10.. .... = Control Channel: FACCH or SDCCH (0x2)
+ 00.. .... = Control Channel: not further specified (0x0)
..00 0... = Spare: 0x0
.... .000 = SAPI: RR/MM/CC (0x0)
- Length: 28
+ Length: 23
GSM A-I/F DTAP - Setup
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
- 01.. .... = Sequence number: 1
+ 00.. .... = Sequence number: 0
..00 0101 = DTAP Call Control Message Type: Setup (0x05)
- Bearer Capability 1 - (Full rate support only MS)
+ Bearer Capability 1 - (Reserved)
Element ID: 0x04
Length: 7
Octet 3
1... .... = Extension: No Extension
- .01. .... = Radio channel requirement: Full rate support only MS
+ .00. .... = Radio channel requirement: Reserved
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.0.. .... = Compression: Not Allowed
- ..00 .... = Structure: Service data unit integrity (0)
+ ..11 .... = Structure: Unstructured (3)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
@@ -35,7 +35,7 @@ GSM A-I/F DTAP - Setup
1... .... = Extension: No Extension
.00. .... = Access Identity: Octet identifier (0)
...0 1... = Rate Adaption: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
- .... .001 = Signalling Access Protocol: Rate adaptation according to ITU-T Rec. V.110 and ITU-T Rec. X.30 (1)
+ .... .000 = Signalling Access Protocol: Reserved (0)
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
@@ -45,15 +45,15 @@ GSM A-I/F DTAP - Setup
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
- ...1 .... = Number of data bits excluding parity bit if present: 8
+ ...0 .... = Number of data bits excluding parity bit if present: 7
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
- .11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
+ .00. .... = V.110/X.30 rate adaptation Intermediate rate: Reserved (0)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
- .... .011 = Parity information: None (3)
+ .... .000 = Parity information: Odd (0)
Octet 6c
1... .... = Extension: No Extension
- .01. .... = Connection element: Non transparent (RLP) (1)
+ .00. .... = Connection element: Transparent (0)
...0 0000 = Modem type: None
So now the ball is on osmo-msc's side: we definitely need to improve encoding of MT CC Setup messages.
The logic responsible for that can be found in osmo-msc.git, function gsm48_cc_tx_setup().
Updated by fixeria 10 months ago
- File modem2modem_call_connect_rlp.pcapng.gz modem2modem_call_connect_rlp.pcapng.gz added
- % Done changed from 0 to 40
fixeria wrote in #note-17:
So now the ball is on osmo-msc's side: we definitely need to improve encoding of MT CC Setup messages.
The logic responsible for that can be found in osmo-msc.git, functiongsm48_cc_tx_setup().
With these patches applied I am finally able to establish a modem-to-modem data call (the called side rings and can pick up the call):
https://gerrit.osmocom.org/c/libosmocore/+/33931 gsm48_ie: fix gsm48_encode_bearer_cap(): encode bcap->data.transp [NEW]
https://gerrit.osmocom.org/c/osmo-msc/+/33932 csd_bs_list_to_bearer_cap(): properly initialize bcap fields [NEW]
https://gerrit.osmocom.org/c/osmo-msc/+/33933 csd_bs_list_to_bearer_cap(): add default branch for safety [NEW]
In my case it was a non-transparent call employing L2COP/RLP, because one of the modems I am testing with does not support transparent calls. I picked up the call and saw CONNECT 9600 on the calling side. After ~10 seconds one of the modems ended the call by itself, for yet to be investigated reason, so I got NO CARRIER. This is already a good progress, attaching a PCAP.
Updated by fixeria 10 months ago
fixeria wrote in #note-18:
... I picked up the call and saw
CONNECT 9600on the calling side. After ~10 seconds one of the modems ended the call by itself, for yet to be investigated reason, so I gotNO CARRIER. This is already a good progress, attaching a PCAP.
Looking at the measurement reports (apply filter gsm_abis_rsl), I see the calling modem reporting RxQual=5 during the call establishment, but after I picked up the call (frame 5145 and greater) both calling and called modems report RxQual=0, so a radio link seem to be fine and unlikely be the cause of unexpected call release.
The call is terminated by the calling modem itself, see frame 8176:
Radio Signalling Link (RSL)
0000 001. = Message discriminator: Radio Link Layer Management messages (1)
.... ...1 = T bit: Considered transparent by BTS
.000 0010 = Message type: DATA INDication (0x02)
Channel number IE
Element identifier: Channel Number (0x01)
0000 1... = C-bits: Bm + ACCH (1)
.... .010 = Time slot number (TN): 2
Link Identifier IE
Element identifier: Link Identifier (0x02)
00.. .... = channel type: Main signalling channel (FACCH or SDCCH) (0)
..0. .... = Not applicable (NA): Applicable
...0 0... = Priority: Normal Priority (0)
.... .000 = SAPI: 0
L3 Information IE
Element identifier: L3 Information (0x0b)
Length: 5
Link Layer Service Data Unit (L3 Message)
GSM A-I/F DTAP - Disconnect
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
11.. .... = Sequence number: 3
..10 0101 = DTAP Call Control Message Type: Disconnect (0x25)
Cause - (16) Normal call clearing
Length: 2
1... .... = Extension: No Extension
.11. .... = Coding standard: Standard defined for the GSM PLMNS (3)
...0 .... = Spare bit(s): 0
.... 0000 = Location: User (0x0)
1... .... = Extension: No Extension
.001 0000 = DTAP Cause: Cause: (16) Normal call clearing
I will repeat the experiment with a different modem (Quectel EC20) and try to establish a transparent call, let's see if it makes a difference.
Maybe the unexpected release is somehow expected to happen because I am not sending (i.e. typing) any data?
Updated by laforge 10 months ago
On Tue, Jul 25, 2023 at 08:49:19PM +0000, fixeria wrote:
Maybe the unexpected release is somehow expected to happen because I am not sending (i.e. typing) any data?
no, that doesn't play any role. you can have the call active for as long as you want without sending any data.
Updated by fixeria 10 months ago
- File modem2modem_call_connect_rlp_gsmtap.pcapng.gz modem2modem_call_connect_rlp_gsmtap.pcapng.gz added
fixeria wrote in #note-19:
I will repeat the experiment with a different modem (Quectel EC20) and try to establish a transparent call, let's see if it makes a difference.
As it turned out, Quectel EC20 does not support transparent data calls:
21:58 < fixeria> Quectel EC20 does not seem to support transparent calls either :/ 21:58 < fixeria> AT+CBST=? gives me +CBST: (0,7,12,14,16,17,39,43,48,51,71,75,80,81,83,84,116,134),(0,1,4),(0,1) 21:58 < fixeria> but AT+CBST=71,0,0 gives an ERROR
Perhaps it's supported only for specific data rates (e.g. Ericsson F3607GW requires data rate to be 116 = 64000 bps).
The good news is that I found another device (other than the FCDEV3B) that can do transparent data calls:
03:31 < fixeria> oh damn, Calypso rocks 03:31 < fixeria> I just gave Sony Ericsson K200i a try: +CBST: (0-7,12,14,65,66,68,70,71,75),(0),(0-3) 03:32 < fixeria> the modem mode is hidden on this phone, but can be enabled via a secret code: #*87223564# 03:33 < fixeria> (documented here https://osmocom.org/projects/baseband/wiki/SonyEricssonK200i#MMI-codes) 03:33 < fixeria> so, I think I found another modem for testing transparent CSD calls
Will give it a try tomorrow.
laforge wrote in #note-20:
If it disconnects after some seconds in NT Mode, I suspect the RLP layer in the user plane cannot be successfully established, I.e. somehow the user plane gets corrupted between the two UE.
This is likely the reason, yes. I am attaching another PCAP file (non-transparent call), with RLP frames encapsulated into GSMTAP frames. I do see Uplink frames from both modems, and both sending some valid data with correct FCS, but I see no Downlink frames at all. I suspect this is somehow related to the error message I am seeing in the logging of osmo-bts:
04:34 < fixeria> "DLMIB NOTICE osmo_ortp.c:0 ortp: rtp_session_avpf_enabled(): payload type not set, unreliable result returned." 04:34 < fixeria> it's a bit weird, because I do see the payload type being set in incoming RTP frames. Will investigate this further (osmo-bts side).
Updated by fixeria 10 months ago
- File modem2modem_call_connect_rlp_gsmtap_v2.pcapng.gz modem2modem_call_connect_rlp_gsmtap_v2.pcapng.gz added
fixeria wrote in #note-22:
I am attaching another PCAP file (non-transparent call), with RLP frames encapsulated into GSMTAP frames. I do see Uplink frames from both modems, and both sending some valid data with correct FCS, but I see no Downlink frames at all. I suspect this is somehow related to the error message I am seeing in the logging of osmo-bts: [...]
This is actually my fault: I forgot to update the l1sap_down() in osmo-bts.git, so this is why no Downlink GSMTAP frames were emitted.
Attaching another PCAP with both Uplink and Downlink. If you apply filter gsm_rlp.fcs.status "Good", you should see:
- lots of
U/NULLframes - not interesting, can be filtered out!(gsm_rlp.u_ftype 0x0f); - XID frames (RLP parameter negotiation): filter by
gsm_rlp.u_ftype 0x17; - frame 4426:
U/SABMsent by the called modem (Uplink); frame 4513:U/SABMsent to the calling modem (Downlink); - frame 4799:
U/SABMre-transmitted by the calling modem (Uplink); frame 4891:U/SABMsent to the calling modem again; - frame 5055:
U/SABMsent by the calling modem (Uplink) + frame 5125:U/SABMsent by the calling modem (Uplink);
... (gsm_rlp.ftype 0x02) && (gsm_rlp.fcs.status == "Good"): me typing "hello world";- frame 10347:
U/DISCsent by the called modem (Uplink); frame 10426:U/DISCsent to the calling modem (Downlink).
So all in all, the RLP frames are flowing between the two modems as expected. I am not an RLP/CSD expert, but I see nothing suspicious.
Harald raised an interesting question in the IRC, which might pretty much be the reason of the unexpected disconnection:
04:32 < LaF0rge> fixeria: I guess it's an intersting question if NT mode would work MS-to-MS at all,
or whether RLP is somehow "directional", assuming that there's always a network-side implementation
04:33 < LaF0rge> fixeria: I don't recall the details right now, but I think it's a valid question to ask
04:33 < LaF0rge> fixeria: but in any case, you should see whatever one MS is sending in UL as the DL of the other MS
Updated by laforge 10 months ago
Based on a quick re-cap of TS 24.022 it should work symmetrically. Unlike LAPDm, the C/R bits do not differ in UL/DL direction, and the spec clearly states that either side can initiate ABM at any time. It also specifies what is to happen on SABM "clash". So I see no immediate reason why MS-to-MS RLP without IWF would fail.
Updated by fixeria 9 months ago
- Status changed from In Progress to Resolved
- % Done changed from 40 to 100
I think we can close this ticket, since all the problems in osmo-{bsc,msc} preventing call establishment have been fixed.
laforge wrote in #note-24:
Based on a quick re-cap of TS 24.022 it should work symmetrically. Unlike LAPDm, the C/R bits do not differ in UL/DL direction, and the spec clearly states that either side can initiate ABM at any time. It also specifies what is to happen on SABM "clash". So I see no immediate reason why MS-to-MS RLP without IWF would fail.
Thanks for checking this. We can continue investigating this in a separate ticket.
I will continue testing when I am back from vacation.
