Attention is currently required from: laforge, pespin.
2 comments:
File include/osmocom/hnbgw/context_map.h:
Patch Set #3, Line 70: MAP_SCCP_EV_CN_LINK_LOST,
I'm also a bit confused. […]
Scenario:
The connection-less RESET pre-empts all the many individual UE conns.
When the MSC sends us a RESET, it tells us in a connection-less way that it has restarted, and we should no longer attempt to use any SCCP connection-oriented conns to that MSC that were active before = any connected SCCP CO to this peer are definitely lost. (There should be the usual SCCP teardown happening, worst case from inactivity timeouts, but in this situation we want to make sure to flush out previous state to start afresh with the newly restarted MSC.)
It would be a misnomer / layer mixup to call this event RX_RESET, because this FSM is about a single UE's SCCP CO. Obviously the SCCP CO does not receive a RESET. Instead, the connection-less unitdata received a RESET, and in consequence, the SCCP CO are all now to be considered lost.
idk, is _EV_RANAP_LOST any better?
The same action would qualify for any other reason why we might want all SCCP CO to get lost with the least possible amount of wire activity; that's why i picked this more general name. _EV_RANAP_RESET is technically too specific.
File src/osmo-hnbgw/context_map_sccp.c:
Patch Set #3, Line 385: case MAP_SCCP_EV_CN_LINK_LOST:
MAP_SCCP_EV_CN_LINK_RX_RESET?
(see above)
(let me resolve this one, so there is a single unresolved item for this CR aspect, above)
To view, visit change 33173. To unsubscribe, or for help writing mail filters, visit settings.