29 Apr
2016
29 Apr
'16
1:57 p.m.
On 29 Apr 2016, at 11:50, Harald Welte
<laforge(a)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.