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.

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