Moving subscr_{get/put}_channel in gsm_subscr.c (instead of gsm_subscr_base.c)

[Holger Hans Peter Freyther]

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