Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

So, as can be seen in the pcap, the RP-DATA in this NAS message container from open5gs does not have any RP-Destination Address field. (length is 0)
So we fail here:

    if (!dst_len || !dst || !rpud_len || !rp_ud) {
        LOG_TRANS(trans, LOGL_ERROR,
            "RP-DATA (MO) without DST or TPDU ?!?\n");
        gsm411_send_rp_error(trans, rph->msg_ref,
                     GSM411_RP_CAUSE_INV_MAND_INF);
        return -EIO;
    }

Question: Is this an error on the part of open5gs, or is this RP-DATA spec-legal and we should parse the RP-User Data (TPDU) for the destination address?

NAS message container
    Element ID: 0x16
    Length: 23
    GSM A-I/F DTAP - CP-DATA
        Protocol Discriminator: SMS messages (9)
            .... 1001 = Protocol discriminator: SMS messages (0x9)
            0... .... = TI flag: allocated by sender
            .101 .... = TIO: 5
        DTAP Short Message Service Message Type: CP-DATA (0x01)
        CP-User Data
            Length: 20
            RPDU (not displayed)
    GSM A-I/F RP - RP-DATA (MS to Network)
        Message Type RP-DATA (MS to Network)
        RP-Message Reference
            RP-Message Reference: 0xba (186)
        RP-Originator Address
            Length: 0
        RP-Destination Address
            Length: 0
        RP-User Data
            Length: 15
            TPDU (not displayed)
    GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
        0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        ..0. .... = TP-SRR: A status report is not requested
        ...0 0... = TP-VPF: TP-VP field not present (0)
        .... .1.. = TP-RD: Instruct SC to reject duplicates
        .... ..01 = TP-MTI: SMS-SUBMIT (1)
        TP-MR: 186
        TP-Destination-Address - (68070144444)
            Length: 11 address digits
            1... .... = Extension: No extension
            .000 .... = Type of number: Unknown (0)
            .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
            TP-DA Digits: 68070144444
        TP-PID: 0
            00.. .... = Defines formatting for subsequent bits: 0x0
            ..0. .... = Telematic interworking: no telematic interworking, but SME-to-SME protocol
            ...0 0000 = The SM-AL protocol being used between the SME and the MS: 0
        TP-DCS: 0
            00.. .... = Coding Group Bits: General Data Coding indication (0)
            Special case, GSM 7 bit default alphabet
        TP-User-Data-Length: (2) depends on Data-Coding-Scheme
        TP-User-Data
            SMS text: Ok

Looking at three phones, and capturing this time the S1AP between the radio and open5gs, (open5gs at a glance and a guess, is simply forwarding the NAS msg container verbatim)

The HTC is indeed sending

RP-Destination Address
    Length: 0

The other two phones, a samsung and a xiaomi send:

RP-Destination Address - (7)
    Length: 2
    1... .... = Extension: No Extension
    .001 .... = Type of number: International Number (0x1)
    .... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x1)
    Called Party BCD Number: 7

So it looks like we need osmo-msc to accept zero length RP-Destination Address?

Interesting: Possibly related, https://nickvsnetworking.com/the-surprisingly-complicated-world-of-sms-apple-iphone-mt-sms/

Hi Keith,

On Tue, Feb 13, 2024 at 06:25:33PM +0000, keith wrote:

Looking at three phone, and capturing this time, the S1AP between the radio and open5gs, the htc is indeed sending [...]

Are you sure you're using the same SIM card between those attempts? Maybe the EF.SMSP contains different conten between your different phones? Didn't the RP-layer normally contain the GlobalTitle of the SMSC? Or am I mixing things here (sorry, just recalling off my head).

keith wrote in #note-3:

The HTC is indeed sending [...]

keith are you sure you have the SMSC address configured on that HTC phone?
I think we have already seen such behavior in the absence of SMSC address. Some phones require the user to set it before sending SMS, some do not and send with empty RP-Destination Address.

Thanks laforge and fixeria, Yes I realised what was going on after checking that the spec indeed requires a min length of 2 for the RP-DA and that there are no variations allowed for SMS over SGs, and also observing that the htc phone with this SIM also sends RP-DA of zero length on 2G.

Funny, this post from 2010, (back in the openBTS at the Burning Man days) came into my head, so I'll just leave this link here as it took a while to find it:
https://web.archive.org/web/20120124060701/http://openbts.blogspot.com/2010/10/smsc-address-caching-in-iphones.html

It's not the same issue as no SMSC configured, but maybe somebody is looking up SMSC problems sometime in the future..