Moving subscr_{get/put}_channel in gsm_subscr.c (instead of gsm_subscr_base.c)
Hi, I'm now having another look at implementing MT ciphering. For this, I need to work inside the paging system. What I'd like is that the MSC part instead of ever using paging_request directly, that they all use subscr_get_channel. Then this would also encapsulate securing the channel and only call the call back when the channel has been ciphered and is ready for the MSC part. This requires making some gsm_04_08 call inside the subscr_get_channel, so I need to move that call to the 'msc' side of gsm_subscr.c To me, it makes sense. I don't see in what context a BSC would use get/put channel ... the BSC doesn't decide, it's just ordered what to do by the MSC IIUC. I would then also replace all calls to paging_request in gsm_04_08.c by calls to subscr_get_channel. And also move the "paging_succeded" signal dispatch to the subscr_get_channel call back and not directly from gsm_04_08_utils.c (since that signal is used currently to trigger SMS delivery and other "side" things when we have a channel, it's more a MSC thing). 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 ? Cheers, Sylvain
Hi, And since a patch is worth a thousand words, I've pushed what I'm thinking of into the sylvain/prep_27c3 branch. I haven't moved the SS_PAGING signal dispatch. I have to check a few things because that signal was previously dispatched several time (once for each bts) if it expired, which sounds weird to me. (the paging call back also seemed to be called several time in case of expiry) Cheers, Sylvain
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
Hi,
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?
I don't see what you mean there. grepping for 'open_channel' didn't yield any results. Cheers, Sylvain
On 12/09/2010 09:44 AM, Sylvain Munaut wrote:
Hi,
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?
I don't see what you mean there.
grepping for 'open_channel' didn't yield any results.
Sorry, I couldn't remember the callback function name and was too lazy to check it. I was referring to compl_l3 which should be called with the Paging Response message. In the future we should parse it on the MSC side again and then dispatch it. This is not a show stopper to merge your changes. holger
participants (2)
-
Holger Hans Peter Freyther -
Sylvain Munaut