Change in osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-08-20 Thread Neels Hofmeyr
Neels Hofmeyr has abandoned this change. ( https://gerrit.osmocom.org/7221 ) Change subject: abis_rsl: properly handle RSL Release Ind from MS .. Abandoned nonsense -- To view, visit https://gerrit.osmocom.org/7221 To

osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-03-12 Thread Neels Hofmeyr
Patch Set 1: > At first sight I'm not entirely convinced. > > An RLL REL IND indicates release of one SAPI (on either DCCH or > SACCH), not release of the radio channel. The MS could release > SAPI3 as no SMS transmissions are pending but still keep SAPI 0 for > other signaling? > >

osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-03-12 Thread Harald Welte
Patch Set 1: Code-Review-1 -- To view, visit https://gerrit.osmocom.org/7221 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0f8c9c4e6b6850b15c70250fd3f88bdf75f9accf Gerrit-PatchSet: 1 Gerrit-Project: osmo-bsc Gerrit-Branch: master

osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-03-12 Thread Harald Welte
Patch Set 1: At first sight I'm not entirely convinced. An RLL REL IND indicates release of one SAPI (on either DCCH or SACCH), not release of the radio channel. The MS could release SAPI3 as no SMS transmissions are pending but still keep SAPI 0 for other signaling? Imagine SMS over SACCH

osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-03-11 Thread Neels Hofmeyr
Patch Set 1: Code-Review-1 This probably needs some more testing, and the ttcn3 change-id may not be pushed yet, but I'd like to get some feedback in the meantime. -- To view, visit https://gerrit.osmocom.org/7221 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType:

[PATCH] osmo-bsc[master]: abis_rsl: properly handle RSL Release Ind from MS

2018-03-11 Thread Neels Hofmeyr
Review at https://gerrit.osmocom.org/7221 abis_rsl: properly handle RSL Release Ind from MS If we receive a Release Ind from the MS, we so far just drop it on the floor, assuming that some other part of the BSC code invoked something that it is already taking care of -- which is of course not