Hi 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@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.
- 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...
- 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@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)