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/.
Holger Freyther holger at freyther.de
> On 29 Apr 2016, at 11:50, Harald Welte <laforge at gnumonks.org> wrote:
>
> Hi!
>
>
> 1) why are the fields like msisdn, vlr address, hlr address,, sgsn
> address still in their encoded form as part of struct
> osmo_gsup_message? If there is a decoding/encoding function, why
> does it not go all the way? Would anyone object if I was to change
> this?
I don't remember Jacob's reason but my first reaction is that when using these fields one needs them encoded and decoded at the same time (e.g. decode the vlr address, encode the number as GT in SCCP, but for MSISDN and MO-SMS one might just copy the encoded data). But right now I don't remember anything that prevents a "deep" decode for convenience.
>
> 2) osmo_gsup_message conatains multiple fields + associated length
> fields. Wy not have a 'struct osmo_buflen { char *buf; size_t len }'
> which is re-used for all such fields that have buffer + length? Then
> the respective code for dealing with such types could be generalized
> and shared.
yes, makes sense to re-use this.
> 3) why is the INSERT SUBSCRIBER DATA ignored by the SGSN, but rather it
> seems to expect the subscribe data piggy-backed onto the LOCATION
> UPDATE RESULT? This seems to break the idea of staying as close as
> possible to the MAP level transactions while avoiding the
> encoding/decoding and underlying signalling protocol complexities.
The reason to piggy-back was that I wanted to make it easier for the SGSN to deal with multiple invocations of subscriber data and only be presented with the entire set at once. We can argue that by going from E1/SCCP to TCP we can avoid this layer7 segmentation. In spirit it aligns the protocol with the move to SIGTRAN.
Not handling stand-alone ISD is a limitation that should be easy to fix as well.