From: Jet <icp...@gm...> - 2012-08-22 15:32:56
|
Hi Dmitri, I'll update the callid and fix for the coredump. as for *the possibility of doing a separate procedure for handover inside a BTS, *I am afraid this might shift too far away from the current call processing architecture. Thanks, Jet On Wed, Aug 22, 2012 at 5:38 PM, Dmitri Soloviev <dm...@ma...> wrote: > Hi Jet > > This letter is sent to a public list cause architectural aspects are > discussed. Introduction can be found here > http://wush.net/trac/rangepublic/wiki/Handover > > > I've united your code with mine and tried to make handover work via SIP. > Snapshot is git-ed > https://github.com/dmisol/openbts-p2.8/commits/handover-sandbox The code > added is not too nice, sorry.. > Transaction logic for incoming handover (air procedures) is more or less > tested (HOCxxx-named procedures and HandoverEntry..) > > I tried to put your code into transaction for outgoing handover (I was lazy > to populated it properly, do not try to log it: logical channel is not > initializes as it's useless here). > While debugging, this transaction is living inside CLI thread. > Core is dumped when HOcontroller() tries to read a SIP message and is > surprised to find the incoming IVNITE that was recently sent from the same > transaction 8) > > The problem is that when HO is inside a BTS, a single callID is checked by > both outgoing and incoming handover transactions. > So the question is: is it worth doing a separate procedure (that will live > without SIP in between) for handover inside a BTS? > > Making CallID = "handover-<l3ti>-<imsi>-<last_ho_timestamp>" as desired lets > us > - normally process a chain of handovers that loops back to initial site > (it's timestamp will differ) > - flip SIP loops (as IMSI is included) > but we still have an obstacle when HO is performed inside a BTS (that might > be practically used when shifting timeslots for GPRS). And as for now, I > have a single BTS at my disposal.. > > > Thks, > Dmitri |