FreeCalypso > hg > osmo-playpen
view doc/Proto-SMSC-testing @ 22:7bfe3e21eaae default tip
top Makefile: add ctrl-client
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Sun, 17 Dec 2023 08:53:35 +0000 |
parents | 9ff041d85da5 |
children |
line wrap: on
line source
The present code repository contains a proto-SMSC test framework: a pair of programs that connect to OsmoHLR in the role of a GSUP-speaking SMSC and allow the rest of SMS-over-GSUP path to be exercised and tested. To exercise SMS flow between an MS and the present proto-SMSC, set up your test environment as follows: 0) Use versions of osmo-hlr and osmo-msc that have OS#6135 implementation included: either mainline (master branch) from 2023-10 or later, or branch falconia/production (Themyscira Wireless patches on top of 2023-02 release) in both osmo-hlr and osmo-msc git repositories. 1) Configure OsmoHLR to expect an SMSC at a certain IPA name, and to route MO SMS to this SMSC. Example config: hlr reject-cause not-found plmn-not-allowed reject-cause no-proxy net-fail gsup bind ip 127.0.0.1 ipa-name Example-HLR ussd route prefix *#100# internal own-msisdn ussd route prefix *#101# internal own-imsi smsc entity Example-SMSC smsc route 19990014444 Example-SMSC In this example the SMSC is operated at SC-address (fake Global Title) +19990014444 (a number falling into a reserved/invalid range in the North American Numbering Plan), with IPA name Example-SMSC, and you are configuring OsmoHLR to map this SC-address to this IPA name. SM-RP messages addressed to any other SMSC will be rejected - a user trying to send something to a commercial operator's SMSC will get an error during SMS send attempt, instead of her message being sneakily intercepted and diverted to Example-SMSC. OTOH, if you prefer to operate your network in a guest roaming manner, allowing foreign SIMs without an actual roaming interconnection in place, and you wish to operate so that all such guest-roaming users will send their MO SMS to your SMSC while their phones "think" that they are addressing their native operator's SMSC, change the last line to: smsc default-route Example-SMSC 2) Ensure that your OsmoMSC configuration includes the following bits: msc sms-over-gsup hlr ipa-name Example-MSC The sms-over-gsup bit should be obvious, but the need for an explicitly set ipa-name is much less so. The explicitly set ipa-name doesn't matter for MO SMS, but it is needed for MT SMS to work. When an MT-forwardSM.req message arrives at the MSC from an SMSC, routed via OsmoHLR, the MSC will need to respond to it, and this response needs to reach the MT-sending SMSC. These responses are routed passively by OsmoHLR, and for this passive routing to work, the sender of the response message needs to include source_name IE. Thus explicitly set ipa-name for the MSC becomes a requirement, just like with inter-MSC handover. 3) Run proto-smsc-daemon like this: proto-smsc-daemon 127.0.0.1 Example-SMSC mo-sms-log /tmp/sendmt_socket The first argument is the IP address of your OsmoHLR instance (more precisely, the IP address at which OsmoHLR GSUP server can be reached; standard GSUP port is required), the second argument is the IPA name this proto-SMSC should give itself (needs to match OsmoHLR config), the third argument is the name of a log file that will be opened for writing, and the fourth argument is the pathname to which a local UNIX domain socket will be bound. Any time an MS sends MO SMS to this proto-SMSC, the message will be written into the line-oriented log file which you named as the second argument to proto-smsc-daemon. Here is what messages will look like: 2023-08-25T23:53:01Z Rx MO SM IMSI: 310xxxxxxxxxxxx SM-RP-MR: 0x03 SM-RP-DA: SMSC TON=1 NPI=1 1xxxxxxxxxx SM-RP-OA: MSISDN TON=1 NPI=1 1xxxxxxxxxx SM-RP-UI: 13 bytes 010304814444000004D4F29C0E ('x' characters in the above fragment are [0-9] digits in reality, but the numbers had to be redacted out for privacy, as the test was done on a live network that operates with real NANP phone numbers.) The string of hex digits that makes up the final line of each recorded message is the GSM 03.40 SMS-SUBMIT TPDU that has been received from the MS in the SM-RP-UI field. proto-smsc-daemon writes it out in raw hex, but you can get a complete decoding by feeding this log file to sms-pdu-decode utility from FreeCalypso User Phone Tools suite, which is in turn a part of FC host tools package: https://www.freecalypso.org/pub/GSM/FreeCalypso/fc-host-tools-latest.tar.bz2 You will need to run sms-pdu-decode with -n option so it will know not to expect a prepended SC-address in front of the TPDU, as happens in GSM 07.05 - running the above log fragment through sms-pdu-decode -np, we get the following decoding: 2023-08-25T23:53:01Z Rx MO SM IMSI: 310xxxxxxxxxxxx SM-RP-MR: 0x03 SM-RP-DA: SMSC TON=1 NPI=1 1xxxxxxxxxx SM-RP-OA: MSISDN TON=1 NPI=1 1xxxxxxxxxx SM-RP-UI: 13 bytes 010304814444000004D4F29C0E First-Octet: 0x01 MR: 0x03 To: 4444 (type 0x81) PID: 0x00 DCS: 0x00 (7-bit) Length: 4 Test 4) To test MT SMS, you will need to compile and install this additional sw package (very small): https://www.freecalypso.org/hg/sms-coding-utils/ To send a test MT SMS, run a shell pipeline like the following: sms-encode-text 'Message text blah blah' | gen-sms-deliver-pdu 1234 | proto-smsc-sendmt 19990014444 310999-001 /tmp/sendmt_socket The various bits are: * The argument to sms-encode-text is the human-level message body to be sent. One can also omit this command line argument and supply the message body on stdin instead. * The argument to gen-sms-deliver-pdu is the "From" number to be inserted into the SMS-DELIVER TPDU being generated. * The first argument to proto-smsc-sendmt is the SC-address to be transmitted in SM-RP-OA. This SMSC address is passed through to the MS, and savvy users of hacker-friendly MS can see it: it is written into SIM SMS storage which can then be read out and decoded, it can be retrieved via GSM 07.05, plus other MS-specific options like /pcm/SMS on Pirelli DP-L10 running that phone's original proprietary fw. * The second argument to proto-smsc-sendmt is the IMSI to which the message should be sent. (Key point: MT SMS recipients in SMS-over-GSUP are addressed by IMSI, not by MSISDN!) proto-smsc-sendmt supports FreeCalypso shorthand notation for IMSI entry: 310999-001 in this example expands into 310999000000001. Of course you can also enter the full IMSI manually, if you don't mind torturing your eyes counting all those zeros. * The third argument to proto-smsc-sendmt is the local UNIX domain socket to which the composed GSUP message should be sent; it needs to match the socket pathname you gave to proto-smsc-daemon.