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/.
Alexander Chemeris alexander.chemeris at gmail.comOn Sat, Apr 13, 2013 at 7:22 PM, <stephane at shimaore.net> wrote: >> Could you point me to a place where you found description of call >> continuity / handover in IMS? When I did a quick search I didn't find >> it. > > I read mostly the article on VCC here: > http://catis-blog.com/?tag=as Very nice description of IMS concepts. Do you know the author by a chance? Unfortunately, VCC is mostly focused on CS-IMS call flows which are not interesting for us, because in the OpenBTS architecture there are no CS calls at the core network. In general, we don't need CS interoperability part of IMS which is the ugliest part of it. IMS have nice concepts and logic behind it, but we should adopt it with creativity. My thoughts after reading that blog: 1. We could think about OpenBTS as a P-CSCF. There will be another P-CSCF(s) when we start connecting to other networks and implement roaming, but for a standalone network OpenBTS's are the only P-CSCFs. They could route SIP messages to a proper next CSCF, which could be different for different IMSIs and different SIP message types. 2. I-CSCF is what handles authentication and admission control, which is important when our subscribers roam and connect from other networks. For internal calls I-CSCF functions could be reduced or even completely split between other elements of a network. Or we could keep it for balancing or other purposes. 3. S-CSCF in IMS somehow combines proxy and registrar, which might be better to keep separate. I don't see a problem if OpenSIPS/Kamailio could serve as such a combined entity already, otherwise it would be easier to get the thing in pieces. 4. IMS defines a way to dynamically define triggering points (Initial Filter Criteria aka iFC) which tells a CSCF to route call one or another way. I believe we don't need this initially and could live with OpenSIPS/Kamailio configs. And later we could figure out whether iFC is needed at all or there are better ways to handle events, e.g. http://switchcoder.fairwaves.ru/ 5. HSS is a part we really need to have. The only viable open-source alternative I know of is a Mobicents Diameter solution. Have you ever played with it or at least with Java SLEE in general? It looks awful to me, but some people like it :) 6. SMSC isn't really specified in IMS tutorials I saw. Do they assume it's just one of Aplication Servers? We could use Mobicents SMSC (https://code.google.com/p/smscgateway/) with a SIP frontend and keep SIP/IMS architecture or we could use AMQP as we discussed earlier. And surely we could avoid using all those ugly abbreviations when we talk about OpenBTS network. It's enough to keep a kind of mapping documented. All that said, the biggest problem right now is to have scalable SMSC and registration/authentication. Everything else is a lesser issue. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru