This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/UmTRX@lists.osmocom.org/.
stephane at shimaore.net stephane at shimaore.netHi Alexander, Hope you guys made some interesting contacts while in Spain. > Though I should note that FPGA and ZPU compilation and flashing is not > needed in most cases. UmTRX comes pre-flashed and should not need all > those cumbersome steps. Yup, changed my page to indicate that as well. (Although really I should be updating the wiki.) > Thank you for your patch to make it working with OpenSIPS :) Looking > forward for more contributions to the SIP side of things. My line of thought is to use OpenSIPS as registrar, with a Redis backend. Then use OpenSIPS to route calls, SMS, .. based on the IMSI. > I even thought about completely replacing oSIP with a library which > already implements SIP state machines, like Sofia-SIP. But this requires > research on whether we'll be able to implement things which require > non-standard behavior, like handover. If we are to keep the strong coupling (with OpenBTS a thin layer between GSM and SIP), the SIP stack can remain pretty simple (with some level of equivalence between GSM and SIP messages); in that case the SIP call handling intelligence will be deported to other tools (OpenSIPS, FreeSwitch, Yate, ...): OpenBTS won't be able to do things like handover or roaming on its own, the call control will belong in those external servers, but that's what they were designed to do (and OpenBTS remains a manageable project). However, in that case, SIP might not be the best protocol, since the model is more of a call-agent / gateway relationship (so something better suited to, e.g., MGCP). Or we need to defined a subset of SIP that matches that call-agent / gateway relationship carefully. On the other hand if OpenBTS is to be a full-flegde User-Agent (UA) this will require a strong SIP stack like sofia-sip, and handling a lot of "exception cases" inside OpenBTS (SIP is a piece of work). This means an amount of work similar to that required to write Asterisk, FreeSwitch, or Yate. Maybe in that case it's simpler to (re)implement OpenBTS as, e.g., a FreeSwitch "endpoint" than trying to re-invent a new SIP UA. About handover: With regards to Dmitri's handover proposal[1], I can imagine that in some contexts (large cities?) handover might be a common occurrence and keeping the call pinned in one (or more?) OpenBTS might cause scalability or audio quality issues. (This would especially be the case if multiple handovers mean traversing multiple OpenBTS.) [1] http://wush.net/trac/rangepublic/wiki/Handover Also I can imagine that we might eventually want to do GSM-to-WiFi back to-GSM type of handovers (or is that what GSM would consider roaming?). I don't know whether there are existing procedures to handle this? > RX1 (software) = RXn (PCB label) > RX3 (software) = SCNn (PCB label) > TX2 (software) = TXn (PCB label) OK, that was the missing translation table. I guess I could look at the hardware schematics when I have hardware questions. :) S.