This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHello Michael, > I have tried changing the session state to > `OSMO_GSUP_SESSION_STATE_CONTINUE`, and the gsup_msg_type to > `OSMO_GSUP_MSGT_PROC_SS_REQUEST` in `euse_tx_ss`. I see the “You > sent…” response on my phone, but do not get an input field. Since GSUP is used as the transport layer for encoded USSD payload, changing GSUP header fields wouldn't change the payload itself. In other words, what you are doing is correct, but additionally you need to change the message itself. The current code is using gsm0480_gen_ussd_resp_7bit() function from libosmocore, where you can find the following: // ... /** * Here you should change GSM0480_OP_CODE_PROCESS_USS_REQ * to GSM0480_OP_CODE_USS_REQUEST (see GSM 04.80). */ /* Pre-pend the operation code */ msgb_push_TLV1(msg, GSM0480_OPERATION_CODE, GSM0480_OP_CODE_PROCESS_USS_REQ); // ... /** * ... * Here you should change GSM0480_CTYPE_RETURN_RESULT * to GSM0480_CTYPE_INVOKE (see GSM 04.80). */ /* Wrap this up as a Return Result component */ msgb_wrap_with_TL(msg, GSM0480_CTYPE_RETURN_RESULT); so it makes sense to introduce a new function. Moreover, you should take care about InvokeID, it should uniquely identify each request-response pair in the following way: msc { MS [label="Subscriber"], EUSE [label="SS/USSD handler"]; MS => EUSE [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_INVOKE, invokeID=X"]; EUSE => MS [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_INVOKE, invokeID=X+1"]; MS => EUSE [label="GSM0480_OP_CODE_USS_REQUEST, GSM0480_CTYPE_RETURN_RESULT, invokeID=X+1"]; EUSE => MS [label="GSM0480_OP_CODE_PROCESS_USS_REQ, GSM0480_CTYPE_RETURN_RESULT, invokeID=X"]; } I am using X because not all phones start counting from 0, and this should be handled properly. X+1 is just an example, it can be calculated in a different way, but in any case it should be unique for the current stack of requests. Keep us updated, good luck! With best regards, Vadim Yanitskiy.