Hi,
On 10/22/24 3:22 PM, Alexander 'lynxis' Couzens wrote:
So what is the right direction?
IMHO the right direction is to have a libosmo-gtp.git repository which contains: libosmo-gtpv1c.so libosmo-gtpv2c.so
It should be pretty similar to what nowadays you can find in https://github.com/open5gs/open5gs/tree/main/lib/gtp/ .
As in there, I really really vote for generating the TLVs as it's done in there, parsing the 3GPP docx (I actually wrote the script to generate the v1 subdir structs there iirc). See https://github.com/open5gs/open5gs/tree/main/lib/gtp/v1/support/ .
Then, on top/aside of that add some APIs to have some data domain with some structs (private structs, public APIs!) to handle peers, retransmission state, etc. like done in path.c and xact.c. Also add some VTY to declare and configure nodes like done in eg. libosmo-sigtran.
There's already a ticket to do this btw, see https://osmocom.org/issues/6518 .
Should I create a new high level API, parse only the 3-4 TLVs the SGSN will use into a `struct sgsn_response`?
We should really end up dropping libgtp, that's really a dead end and will only cause us many many problems as we try to improve it imho. So I'm all in favour of a new libosmo-gtp as mentioned above.
I think it's fine for first develop the library inside a subdir of osmo-sgsn.git or osmo-ggsn.git as a independent static library and later on once used properly make it a public shared object inside its own git repository.
Start by taking the python script, putting it eg. in osmo-sgsn.git/libosmo-gtp/support/ and generating code using libosmocore dependencies.
Regards, Pau