On 12/01/2010 08:55 PM, Sylvain Munaut wrote:
Finally, I'd need to pass the msgb paging response all the way to the paging callback because it contains important field to enable ciphering.
Any objections to this plan ? Did I miss something ?
I agree with most of the changes. It is good that the MSC part starts using a 'better' way to manage the channel and has a way to properly queue requests, maybe even re-use a channel later. From what I see it is a step in the right direction, it doesn't seem to break osmo-bsc. Feel free to merge it.
There are some minor issues but that is mostly due us having a general issue with paging. In a network there are two possible configs for paging. The MSC sends a Paging Request and the BSC sends the RSL paging command (1:1) or the MSC asks for paging and the BSS will send various items. With the current nanoBTS config (and I think it was the case for the BS11 too) the BSS is sending multiple requests.
The above is leaving us with two issues: 1.) the BSC part needs to schedule paging requests and queue them (and stop them on a paging response) 2.) the MSC needs to get the paging response part
In the short-term we might want to be able to run the BSC and MSC part in two different processes and then we would need to properly separate these things. So I am thinking if things might not be easier in the long run if we check in the 'open_channel' callback on the MSC side if it was a paging response and then trigger the signal and the subscriber logic there?
regards holger