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