25 Aug
2013
25 Aug
'13
10:51 a.m.
Hi list,
Peter, thank you for your reply.
I still have questions about media control:
1) when parsing MGCP CRCX, sdp is not expected. May I change it?
2) I still can't run media in BSC mode. Seems I'm missing something.
osmo-bsc and osmo-bsc_mgcp are running
BSSAP works perfectly
But it seems two interfaces are working completely independent:
-- MGCP between MSC and BSC
-- interface between BSC and BTS (ip.access):
at MGCP, connection is acknowledged, endpoint is allocated (at BSC
ip=192.168.1.11)
at ip.access interface between BSC and BTS, BTS replies to ip.accessCRCX
with proper acknowledgement with proper ip:port at BTS (192.168.1.9) , then
BSC issues ip.accessMDCX with endpoint ip zero:
7e:73:01:09:f8:00:2d:*f0:00:00:00:00*:f1:0f:be:f4:00:f2:03
My attempts to modify connection at MGCP interface has no impact on
ip.access interface
The key question, I'm not getting how osmo-bsc and osmo0bsc_mgcp are
interacting.
Thank you,
Dmitri
PS my configs are
mgcp
local ip 192.168.1.11
bts ip 192.168.1.9
bind ip 192.168.1.11
bind port 2427
rtp base 6000
sdp audio payload number 3
sdp audio payload name GSM/8000
number endpoints 31
and
e1_input
e1_line 0 driver ipa
network
network country code 250
mobile network code 07
short name OsmoBSC
long name OsmoBSC
auth policy closed
location updating reject cause 13
! encryption a5 1
neci 1
paging any use tch 0
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 0
timer t3111 0
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3122 0
timer t3141 0
dtx-used 0
subscriber-keep-in-ram 0
bts 0
type nanobts
band PCS1900
cell_identity 2611
location_area_code 51601
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
neighbor-list mode manual-si5
gprs mode none
trx 0
rf_locked 0
arfcn 810
nominal power 0
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
msc
! ip.access rtp-base 6000
timeout-ping 20
timeout-pong 5
dest 192.168.50.10 5000 0
in fact, BSSAP goes from a card over VPN, while MGCP comes from
self-written TRAU running locally, the same host as BSC
3:03 p.m.
Thank you
but there are few things still unclear:
- why at A-bis interface BSC issues ip.accessMDCX with ip=0.0.0.0? is there
anything configured improperly?
- so, UDP port is BSC side is predicted. but an endpoint at BTS side is
dynamically allocated.. is there a way to inform osmo-BSC_mgcp, or it just
replies to RTP from BTS?
On Sun, Aug 25, 2013 at 4:02 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On Sun, Aug 25, 2013 at 02:51:12PM +0400, Dmitri
Soloviev wrote:
Hi list,
But it seems two interfaces are working completely independent:
yes, they just share one secret on how to go from endpoint number
to rtp port.
holger
2 Sep
2 Sep
10:57 a.m.
On Sun, Aug 25, 2013 at 07:03:40PM +0400, Dmitri Soloviev wrote:
Thank you
but there are few things still unclear:
- why at A-bis interface BSC issues ip.accessMDCX with
ip=0.0.0.0? is there
anything configured improperly?
that is okay. The BTS has the OML/RSL connection. When the BTS is
receivng a 0.0.0.0 on the RSL link, it is supposed to send the RTP
to the IP address of the peer of the RSL link.
- so, UDP port is BSC side is predicted. but an
endpoint at BTS side is
dynamically allocated.. is there a way to inform osmo-BSC_mgcp, or it just
replies to RTP from BTS?
right. The osmo-bsc_mgcp will open two ports for each endpoint. One is
facing toward the BTS and is predicatble, the other will be dynamically
allocated and faces the network.
12:46 p.m.
Thank you..
in fact, last night I did a hack, and it started to work
http://www.opensigtran.org/bsc.html
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.
I was about to clean the code (my ss7+ca and transcoder), publish it as
well as discuss patches/hacks to openbsc I had to do:
1) in my case, OpenBSC makes BTS to talk to a predictable port at transcoder
2) I could not guess your reasons (as well as ways) to configure voice
codecs within BSC, and hardcoded them within bssap_handleassingm_req()
Hope to prepare a proper letter it in about a week
BR,
Dmitri
On Mon, Sep 2, 2013 at 2:57 PM, Holger Hans Peter Freyther <
holger(a)freyther.de> wrote:
On Sun, Aug 25, 2013 at 07:03:40PM +0400, Dmitri
Soloviev wrote:
Thank you
but there are few things still unclear:
- why at A-bis interface BSC issues ip.accessMDCX
with ip=0.0.0.0? is
there
anything configured improperly?
that is okay. The BTS has the OML/RSL connection. When the BTS is
receivng a 0.0.0.0 on the RSL link, it is supposed to send the RTP
to the IP address of the peer of the RSL link.
- so, UDP port is BSC side is predicted. but an
endpoint at BTS side is
dynamically allocated.. is there a way to inform osmo-BSC_mgcp, or it
just
replies to RTP from BTS?
right. The osmo-bsc_mgcp will open two ports for each endpoint. One is
facing toward the BTS and is predicatble, the other will be dynamically
allocated and faces the network.
7 Sep
7 Sep
4:53 p.m.
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)
8: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)
4368
days inactive
4381
days old
6 comments
3 participants
participants (3)
-
Dmitri Soloviev -
Harald Welte -
Holger Hans Peter Freyther