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