On 29 Apr 2016, at 11:50, Harald Welte laforge@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.