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
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@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
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.
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@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.
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
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)
-
Dmitri Soloviev -
Harald Welte -
Holger Hans Peter Freyther