Bug #4892
opengbproxy2: Route BSSGP-STATUS based on "Erroneous PDU IE"
70%
Description
- PTP downlink: Simply route by NS-BVCI
- PTP uplink: route based on "Erroneous PDU IE"
- SIG downlink + uplink:
- don't route (but locally terminate) if optional BVCI IE, as that one only occurs for BVCI blocked / BVCI unknown whihc is a gbproxy problem, not one with a remote peer
- route messages without BVCI IE but with "PDU in error" IE based on the latter
- the contained BSSGP PDU might be truncated, and hence our TLV parser might not be playing well along
- we should look for TLLI + TMSI (and route based on NRI)
- if we cannot find any routing informatoin, we treat it like NULL NRI?
- fast path for single-SGSN case: simply route to "the" SGSN?
Related issues
Updated by laforge 12 months ago
- Related to Feature #4472: Intra-domain connection of OsmoGBPROXY to multiple SGSNs (pooling) added
Updated by laforge 11 months ago
There are now TTCN3 tests for both uplink and downlink direction in https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/22257
Updated by laforge 10 months ago
On Mon, Jan 25, 2021 at 10:42:07AM +0000, daniel [REDMINE] wrote:
The tests seem to be for BSSGP-STATUS PDUs while this ticket is about NS-STATUS PDUs
thanks for catching that. I'm not sure what I was thinking 2 months ago exactly,
but I think I may have been thinking about BSSGP even back then.
In terms of NS-STATUS: I'm currently not entirely sure if we should route them
at all, or not. After all, we really do terminate the NS layer completely
in gb-proxy. The NS-VCI / NSEI are going to be different on both sides.
Hence, I think it's best to rename the ticket to BSSGP.
Updated by daniel 18 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 70
Most features are implemented and pass the TTCN3 tests
https://gerrit.osmocom.org/c/osmo-gbproxy/+/26319 is in review (routing STATUS with truncated pdu-in-error)
