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/OpenBSC@lists.osmocom.org/.
Dmitri Soloviev dmi3sol at gmail.comHi Harald Thank you for a letter. as for intra-BSC handover, there could be 2 ways: - process them as inter-BSC. I'm pretty sure that in 2003 ip.access followed this way, as both nanoBTS involved were connected to a single BSC, and it was a gateway that processed handover - use osmo-bsc_mgcp as it was originally desired It doesn't make much difference: minor changes in transcoder control, as MGCP logic was just reduced. Meantime if the second way is chosen, I'll face the old problem again: I could not get how the endpoint from BTS is delivered to osmo-bsc_mgcp, and why it is lost in the particular deployment I'll appreciate your vision of codec management: reasons for keeping it at BSC side (and some key/example how to configure them), or permission to reduce this logic. If there is a demand to interact with a particular inflexible MSC, I would offer to filter out unsupported codecs in assignment procedure, keeping a single control point/decision maker Best Regards, Dmitri On Sat, Sep 7, 2013 at 8:53 PM, Harald Welte <laforge at gnumonks.org> wrote: > Hi Dmitry, > > On Mon, Sep 02, 2013 at 04:46:09PM +0400, Dmitri Soloviev wrote: > > in fact, last night I did a hack, and it started to work > > http://www.opensigtran.org/bsc.html > > congratulations! Thanks for your effort. > > > I'm doing without osmo-bsc_mgcp at all: after a chanel is being opened, > my > > transcoder just replies the first rtp from bts and keeps this address as > > endpoint. > > Do you already have a plan for dealing with intra-bsc hand-over in this > case? The advantage of having different RTP IP/Port on the A and the > A-bis side is that the BTS can change due to intra-BTS or intra-BSC > hand-over, while on the A interface everything remains stable/unchanged. > > > 1) in my case, OpenBSC makes BTS to talk to a predictable port at > transcoder > > See my comment above. I'm not sure if this is the best solution moving > forward... > > > 2) I could not guess your reasons (as well as ways) to configure voice > > codecs within BSC, and hardcoded them within bssap_handleassingm_req() > > I'll let holger comment on that. My guess is that the MSC that was used > didn't have enough flexibility in configuring the codecs so we override > it in the BSC. > > > Hope to prepare a proper letter it in about a week > > Looking forard to it! > > Regards, > Harald > -- > - Harald Welte <laforge at gnumonks.org> > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20130908/594b16f0/attachment.htm>