7 Sep
2013
7 Sep
'13
10:33 p.m.
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(a)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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)