If the SIP server dies in the middle of a call, osmo-sip-connector is in a
bad state and generates a never ending stream of error messages:
58): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f258): zero length packettport(0xb7e9f258): zero length
packettport(0xb7e9f25
It looks like the messages are generated from sofia-sip and I have managed
to suppress the messages by setting the environment variable SU_DEBUG < 3:
http://sofia-sip.sourcearchive.com/documentation/1.12.7/tport__internal_8h_…
However, it looks like osmo-sip-connector is clearly in a bad state when
this happens and we need a way to detect and release these ghosted calls.
Hi,
The virtual layer 1 is currently in a state where the l23 app can
successfully connect to the bts and most of the signaling messages
will be forwarded and handled. TCH is not yet implemented.
I have some problems still, not knowing if these are caused by
configuration problems or my coding :).
- Trying to initiate a call via the mobile vty will result in
VTY:
call 1 123
OsmocomBB#
% (MS 1)
% Call has been rejected
call 1 123
OsmocomBB#
% (MS 1)
% Call has been released
And no actual call setup message is transfered over the Um interface.
What could be reasons for that? I am using the test-sim option the
mobile app offers.
- Occasionaly the T3210 timer is fired, which causes a new registering
within the network.
LOG:
gsm48_mm.c:336 timer T3210 (loc. upd. timeout) has fired
How can i prevent that?
- I did not implement a tdma or multiframe scheduler in the mobile
uplink as the logical channel is directly put to the gsmtap-header and
thus known by the bts. As Harald used a multiframe based scheduling
for the bts downlink, i wonder if this might be necessary, though. To
submit msgs with the correct frame number for example.
- In my wireshark capture files, the gsmtap messages sent over the
multicast sockets are only recognized as UDP messages. I have to
"cast" them with the wireshark context menu "Decode as...". Why?
I would be super happy if someone of you could check out my project
(osmo-bts, branch stumpf/virt-phy + osmocom-bb, branch
stumpf/virt-phy) try to run it with the config files lying within the
project folders and tell me the problems they see :).
Here you can find a wireshark capture file of 2 mobiles connecting to
a virt bts. I also tried to init calls from both of them but the call
setup is not send.
https://www.dropbox.com/s/2ccky4ljc8ngahz/mobilex2--ms-virt--bts-virt--bsc-…
Kind Regards,
Sebastian Stumpf
Hi list, Hi all.
This is quite Rhizomatica, or at least litecel 2050 specific, please
excuse me for that. I also don't know, maybe it applies to other use cases.
Rhizomatica has one community where an attempt was made to increase
coverage at the same time as capacity, by installing two 2050s with a
somewhat overlapping coverage area. We have currently plans to do the
same in other places.
The goal of this email is to try to establish the work needed to be done
in order to fix what I outline below, I may just be lacking knowledge in
some cases, in other It seems we need to implement some things.
I have grabbed fairwaves' meas_json and meas_web and modified a little
to give me a visualisation of the neighbour meas reports.
So my first doubt is about idle cell reselection on the part of the MS.
It doesn't seem to be operating quite as I would imagine it should and I
am wondering is there any parameter that might make a difference, such
as cell_identity? Is cell reselection hysteresis/offset relevant when
handover is disabled? These parameters are not described in the manual.
If I understood them I could update that. In the meantime, we seem to be
getting reports from users that "the signal is weak" near what I might
call the secondary BTS. At the same time, user reports are not terribly
reliable. However what seems to be happening is that the MS is camped on
the primary BTS, subsequently they have moved away so their handset is
showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS
that are showing neighbour measurements from the secondary that are more
favourable.
Of course, I am often seeing messages such as:
handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better:
Skipping, Handover disabled
Obviously, this makes sense, and I am not sure why historically we have
handover disabled, I presume it is issues with rtp, although we are
using the rtp_proxy. I don't have two BTS so I can't test locally here.
Could anybody comment on the state of that?
I am assuming that there is no way we can do load balancing unless we
first have handover enabled, at the same time it is unclear to me if it
will even work with handover. I believe this is called "Traffic
Handover" Is this already implemented in the BSC? As in, can the BSC
assign a channel on another ARFCN to the MS if the current ARFCN (the
one the MS makes the access request on) has no TCH available?
I also have a doubt about operation with a Litecel/2050. Obviously you
don't really want rescue handover operating between the two BTS that are
present in the Litecel as it is the same antenna, and this shouldn't
happen anyway as the signal levels should never be sufficiently
different, but we do want load balancing handover. I do see "no
resources available" log messages, (especially related to the BROKEN
channels issue) when one BTS in a litecel has no more capacity but the
other does, so it would seem that the BSC is not managing this. Is that
correct?
Would it be correct to assume that maybe some handover rules are
required that would specify: Handover from BTS 0 to BTS 3 but not from
BTS 0 to BTS 1?
Finally, I have a doubt about the rtp proxy mode. Was it ever discussed
to implement SIP Mobility aka re-Invite in order to be able to do
BTS-MGW rtp and also handover? This would seem to me to be a good thing
to have?
k/
What should we do if the HLR sends no Insert Data?
When a subscriber does a Location Updating, the VLR sends a Location Updating
request to the HLR. The HLR typically responds with a Location Updating Result
as success and, in a *separate* message, sends an Insert Data to the VLR to
tell it the subscriber's MSISDN. So it is possible to do a successful Location
Updating without being told the MSISDN (as my test verifies).
What should the VLR do if it never receives the Insert Data from the HLR? In
that case the subscriber is attached but cannot be reached by MSISDN. Should
we actively wait for Inser Data and reject the subscriber if not successful?
It would be fairly easy to just send the MSISDN along in the Location Updating
Result. Why this separate message?
Thx,
~N
Hello,
We have already contacted our SIM cards provider (sysmocom), and they have
referred us towards this Mailing List.
We have purchased sysmoUSIM-SJS1 cards and we are having the following
problem when trying to program them:
We want to change the MCC and MNC values to the ones of our
OpenAirInterface LTE system, and Ki and OPC of the SIM card are changing
despite we are not intending for that to happen. The main issue with this
behavior is that as we have two sets of Ki and OPC values, when we are
going to register the user in the LTE database, we don't know for sure
which set of parameters we are supposed to introduce.
Here on I'll describe the configuration we are using and the commands
introduced when programming the SIM cards:
As programming software we are using PySIM.
The default parameters of the SIM we are programming are:
ADM: 20168462
ICCID: 8988211000000099120
Ki: 5B868E2B30C61190ABEFBA1CA6F6D56F
OPC: B3425076F23BA6054557FA359B4F9C0C
The parameters we are meaning to program are:
MCC: 001
MNC: 01
IMSI: 001010000009912
The command we are using to program in the SIM card is:
./pySim-prog.py -p 0 -a 20168462 -x 001 -y 01 -t sysmoUSIM-SJS1 -i
001010000009912 -s 8988211000000099120
And after programming the card, we are getting this:
[image: Imágenes integradas 1]
Do you what's the reason why this is happening?
Thank you very much for your time
Best regards,
Giselle Glez
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works. AFAICT it just receives messages and replies to
them right away (but haven't seen / understood all of it). For the case of the
UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer,
but the code chooses to resolve by id and then sends to the wrong peer. If it
used the peer's IP address and port instead, things would work out.
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
Which way shall we resolve this?
~N
Hi all
I have got trough the pcs 1900 nano bts if you have any doubts pls let me ... and these days I am trying to resolves OML issues with RBS 2308 ericson bts
Thank you very much
Regards
Rajitha peiris
Sent from my iPhone
On Feb 24, 2017, at 9:42 PM, "openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>" <openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>> wrote:
Send OpenBSC mailing list submissions to
openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request(a)lists.osmocom.org<mailto:openbsc-request@lists.osmocom.org>
You can reach the person managing the list at
openbsc-owner(a)lists.osmocom.org<mailto:openbsc-owner@lists.osmocom.org>
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: Ki and OPC values change when programming MCC and MNC
(Holger Freyther)
2. Re: Virtual layer 1 - Questions (Harald Welte)
3. OsmoHLR and IPA unit id (Neels Hofmeyr)
4. Re: Handover and load balancing on SysmoBTS 2050 (Keith)
5. Re: OsmoHLR and IPA unit id (Harald Welte)
6. Re: Handover and load balancing on SysmoBTS 2050 (Keith)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Feb 2017 15:25:56 +0700
From: Holger Freyther <holger(a)freyther.de<mailto:holger@freyther.de>>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
Cc: "openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>" <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Ki and OPC values change when programming MCC and MNC
Message-ID: <31579AC7-F837-49F1-9EDC-C0B8D2CCC85C(a)freyther.de<mailto:31579AC7-F837-49F1-9EDC-C0B8D2CCC85C@freyther.de>>
Content-Type: text/plain; charset=us-ascii
On 23 Feb 2017, at 09:53, Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>> wrote:
On Wed, Feb 22, 2017 at 05:06:20PM +0100, Sylvain Munaut wrote:
--help will tell you defaults for Ki and OPC is to randomize ...
Ah, indeed, I never saw that. Could also be misunderstood. IMHO it should say
right at the top that you normally want to pass -k and -o when calling pysim.
After all, none of the other options do that. anyway...
"normally".. for the batch mode as used at XC3 events the "normal" is to
generate a random KI, you wouldn't want to do that by hand 4k times. :)
holger
------------------------------
Message: 2
Date: Thu, 23 Feb 2017 15:41:24 +0100
From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
To: Sebastian Stumpf <sebastian.stumpf87(a)googlemail.com<mailto:sebastian.stumpf87@googlemail.com>>
Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>, baseband-devel(a)lists.osmocom.org<mailto:baseband-devel@lists.osmocom.org>
Subject: Re: Virtual layer 1 - Questions
Message-ID: <20170223144124.mdba7w7avdujy23g@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Sebastian,
On Sun, Feb 19, 2017 at 06:16:01PM +0100, Sebastian Stumpf wrote:
I also see that the RACH requesets all are sent with a bogus frame
number: 42. This will not work. The RACH request needs to be sent with
the current frame number at the time being.
I fixed that and calculate the proper rach fn like in
https://github.com/osmocom/osmocom-bb/blob/master/src/target/firmware/layer…
good.
Also, RACH retransmissions are happening way too quick.
Calculating a proper frame number didn't fix the fast retransmissions.
They are caused by sending the channel request over the virtual um
immediately after getting the rach-request from layer23. Thus also the
rach-confirm is sent to l23 immediately, so layer23 thinks "oh fine its
already transmitted" and will generate the next rach-request for my
layer 1.
i see. the confirmation should probably be delayed somehow. As a quick
intermediate hack you might simply add a timer.
I think one can do without on the MS side, but then the BTS must
basically queue the incoming frames until the respective frame number
indicated in the frame matches the current frame number.
I think to fix the problem with the quick retransmission , I need some type
of scheduling. Because if I queue the incoming uplink-msgs in the
bts-virtual-layer1 instead, I don't know when they are processed on the ms
side and thus don't know when to send the rach-confirm to layer23...
My idea for a simple scheduler would be:
-- no timing and timer interrupts on ms side, but just set the current fn in
the ms state each time we receive a message on downlink to the fn of
the received message, which is accessible in the gsmtap header.
yes, that makes sense.
-- queue the outgoing uplink messages with their confirm callback to l2
and process all that with a smaller fn than the current fn in the
scheduling function.
yes, but please keep in mind that the frame number is wrapping every so
often, so "smaller" must consider that modulo-arithmetic, or you will
(after fn wrap) have pending downlink messages for much higher fn which
are not sent as the wrapped fn is now very small.
-- calling the scheduling function each time we receive a msg on downlink
(so I do not need to handle timer interrupts)
yes. I think it is reasonable to not have any actual timers on the ms
side and always depend on the frame numbers in the downlink messages
from the BTS. After all, in the worst case you have periodic messages
like the BCCH messages that can be used to update the fn.
I hope that will be sufficent and try it out tomorrow. I am a bit
afraid of trouble caused by the frame number skipping values with the
upper incrementation logic.
I don't think skips are that problematic. But then, I haven't tried it ;)
--
- Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3
Date: Fri, 24 Feb 2017 06:43:26 +0100
From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
To: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
Subject: OsmoHLR and IPA unit id
Message-ID: <20170224054326.GB1368(a)my.box<mailto:20170224054326.GB1368@my.box>>
Content-Type: text/plain; charset="us-ascii"
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works. AFAICT it just receives messages and replies to
them right away (but haven't seen / understood all of it). For the case of the
UPDATE LOCATION RESULT, it would also be possible to use the same conn pointer,
but the code chooses to resolve by id and then sends to the wrong peer. If it
used the peer's IP address and port instead, things would work out.
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
Which way shall we resolve this?
~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-RFC-add-the-osmo_gsup_conn-directly-to-the-lu_operat.patch
Type: text/x-diff
Size: 2550 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170224/121d8d06/at…>
------------------------------
Message: 4
Date: Fri, 24 Feb 2017 16:42:35 +0100
From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>>
To: Alexander Chemeris <alexander.chemeris(a)gmail.com<mailto:alexander.chemeris@gmail.com>>
Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Handover and load balancing on SysmoBTS 2050
Message-ID: <39e245c4-ba1a-600b-8e38-cb300c10133f(a)rhizomatica.org<mailto:39e245c4-ba1a-600b-8e38-cb300c10133f@rhizomatica.org>>
Content-Type: text/plain; charset=utf-8
Hi Alexander, seeing as how you came in on the thread, as a side topic,
you may have noticed I mentioned meas_json and meas_web in the OP. I
fixed up a small thing with meas_json that was producing unparseable
json in the neighbours array. I also did some stuff server side to
filter for either SDCCH or TCH, although I think I would make this a
clientside javascript filter option, rather than running multiple websocketd
I added the neighbour levels to the displayed data. I hardcoded the
ARFCNs for the site in question, but I would make that happen dynamically.
I found this quite useful for monitoring in relation to analysis on this
site and the would-be handover scenario.
I'm wondering what to do with this work.
Should I make a commit of meas_json to master? In that case I would
appreciate some minor help getting the Makefile right.
Maybe meas_json is not a candidate for the master branch, as it doesn't
currently do anything particularly useful without the external
dependencies, ie meas_web and websocketd or alternative.
I can publish my work on meas_web to github.
Keith.
------------------------------
Message: 5
Date: Fri, 24 Feb 2017 16:53:03 +0100
From: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de<mailto:nhofmeyr@sysmocom.de>>
Cc: openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>
Subject: Re: OsmoHLR and IPA unit id
Message-ID: <20170224155303.tuidxovd4qbzp5go@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
IPA CCM made sense on the Abis interface, where each BTS reports with
its unit_id and MAC address. I'm not quite sure how much sense that
makes in the core network. I also don't know if existing
implementations of e.g. A interface over IPA multiplex actually use it.
In terms of future outlook, the MSC/VLR/SGSN should register at the HLR
with some kind of identity. In MAP, it is the SCCP Address that is used
for this purpose. In absence of SCCP on GSUP, I used the CCM identity
as a replacement. However, it is used as an opaque string, so that any
GSUP/MAP gateway might simply translate the SCCP address into a string
of its choosing, and then talk to OsmoHLR. OsmoHLR would then simply
do a strcmp() on the string to match the identity.
Sooner or later, OsmoHLR will have to store this identity in the
database, e.g. for imlpementing message-waiting-lists of SMSCs in case
of MT-SMS from real SMSCs.
All-in-all, I think the string approach is not too bad in terms of
keeping GSUP simple while having a clan approach to interworkng with
MAP.
On Fri, Feb 24, 2017 at 06:43:26AM +0100, Neels Hofmeyr wrote:
I just ran my first tests of both OsmoNITB and OsmoSGSN connecting to OsmoHLR.
It turns out OsmoHLR uses the ipaccess_unit data a.k.a. CCM (whatever CCM
means) to route GSUP replies back to its sender.
It looks like "NAME-00-00-00-00-00-00".
However, all of our GSUP client code simply sets the unit id to:
"SGSN-00-00-00-00-00-00".
The result is that the VLR never receives an UPDATE LOCATION RESULT, because it
is sent to the SGSN instead, since that was the first one to say that it is
"SGSN-00...".
this is of course not good.
I would extend the GSUP clients to allow setting an ID from VTY, or maybe a
random ID. At this point it would suffice to make the MSC side say it is
"MSC-00-00-00-00-00-00" but that's beside the point.
A random ID would not be permissible, as it has to be persistent accross
MSC/VLR/HLR re-starts, in order to make above-mentioned mechanisms
working.
I would say, why not simply use the same approach as in OsmoBTS, i.e. use
the MAC address (together with the MSC or SGSN prefix). The MAC address
is unlikely to change frequently or on short notice. For people who
know what they're doing, we can have a VTY command to override the
identity with a manually-specified string. If that option is not set,
the default "(SGSN|MSC)-MAC" is used.
Do we really want to do that? Any peer could come along and say it is someone
else, very easy to misconfigure (and not very security sensitive when thinking
of OAP -- which we're not using but maybe we will one day).
I don't think we are aiming for anyone to use those protocols on
public[ly accessible] networks. There's no message authentication or
other cryptographic protection anyway. OAP seems like a funny but
futile minor obstacle, but nothing that can provide any reasonable level
of security.
For some messages, OsmoHLR uses the conn pointer from msg rx to route the
response back -- that works.
This should be done in all request-response style procedures, I think.
AFAICT it just receives messages and replies to them right away (but
haven't seen / understood all of it). For the case of the UPDATE
LOCATION RESULT, it would also be possible to use the same conn
pointer, but the code chooses to resolve by id and then sends to the
wrong peer. If it used the peer's IP address and port instead, things
would work out.
Looking up by ID would also work in case meanwhile the old connection
has died and a new connection has been established
With the attached and possibly very stupid patch, OsmoHLR works for me with
both MSC and SGSN talking to it even though they have identical IPA IDs: I
bluntly store the conn in struct lu_operation and re-use it later.
For synchronous responses (i.e. no asynchronous activity in between)
this will work. So I think it's an optimization for those cases, and we
shouldn't rely on this to always work for all transactions at all time
in the future. Rather, we should make sure it works even without that
optimization?
--
- Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 6
Date: Fri, 24 Feb 2017 17:12:02 +0100
From: Keith <keith(a)rhizomatica.org<mailto:keith@rhizomatica.org>>
To: Harald Welte <laforge(a)gnumonks.org<mailto:laforge@gnumonks.org>>
Cc: OpenBSC Mailing List <openbsc(a)lists.osmocom.org<mailto:openbsc@lists.osmocom.org>>
Subject: Re: Handover and load balancing on SysmoBTS 2050
Message-ID: <ca4d6dc2-fa43-8eaa-8c39-821939d87e52(a)rhizomatica.org<mailto:ca4d6dc2-fa43-8eaa-8c39-821939d87e52@rhizomatica.org>>
Content-Type: text/plain; charset=windows-1252
On 21/02/2017 16:14, Harald Welte wrote:
Just a quick response: jolly implemented "traffic handover" aka "load
balancing" 3 years ago as part of a branch (I believe for a customer),
but unfortunately this never was merged back to master.
Reading the commit log, this looks terrific...
Meanwhile, we already have all the code for execution of hand-overs in
place. We also have dynamic timeslots in place. So the "mechanics"
should all be there to add the two missing features from those old
branches:
a) de-fragmenting of channels (i.e. merging two separate TCH/H into one
timeslot, so the other timeslot can be switched to TCH/F or PDCH on
demand
b) load/traffic based hand-over
So essentially everything I was talking about is already implemented!
My question then would be, and I understand maybe the answer is not so
easily available without a full code review, but
Was it unfortunately never merged back to master because
Simply no one ever made the effort to do so.
OR
There were problems with the code, disagreement on the implementation or
incompatibilities with other developments etc..
If it's the former, I'll have a go at this.
If it is the latter, it's probably beyond my skills.
The general strategy I would normally assume is to
* switch to half-rate channels with AMR whenever possible
* use dynamic channel switching to switch between TCH/H (default) and
TCH/F (if neded)
Absolutely, I must revisit this one.
It was shelved for us due to my understanding a few months ago that if
we implemented AMR, then we couldn't also use FR.
As that's all now resolved, I can implement, test and report. :-)
------------------------------
Subject: Digest Footer
_______________________________________________
OpenBSC mailing list
OpenBSC(a)lists.osmocom.org<mailto:OpenBSC@lists.osmocom.org>
https://lists.osmocom.org/mailman/listinfo/openbsc
------------------------------
End of OpenBSC Digest, Vol 28, Issue 20
***************************************
Hi Holger,
On Feb 22, 2017 1:02 AM, "Holger Freyther" <holger(a)freyther.de> wrote:
> On 21 Feb 2017, at 21:40, Keith <keith(a)rhizomatica.org> wrote:
Hi Keith,
> On the question about SIP re-invite, I am talking about operating
> without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP
> streams at the same time as handover. From what I've read, this is quite
> feasable, as part of the SIP spec.
> I think this is already considered as part of the development of the
> osmo-sip-connector, which is a project I really want to see moving
> forward and hope to find time to contribute to over the next few months.
yes for the osmo-sip-connector I have ignored the topic of handover. In
general I try to see how long I get away with not having to touch the
UDP/RTP streams.
You don't really need to touch RTP stream if you do re-invite.
In case of hand-over the new BTS might send from a different src IP,
src Port and will most likely have a new SSRC, timestamp seqno. It is
a bit of a question of how "your" PBX will handle it. I can see a
couple of outcomes.
a.) It has some support for "NAT" handling and will just use the new
stream and return packages to the new src IP/src port. It might go back
and forth but at some point the old bts will stop sending things.
b.) It will accept the new stream but will try to send to the old BTS.
The we would have one-way audio.
c.) It will reject it as it is a unknown src ip/port.
I think for b.) and c.) we will require SIP re-invite but also need
to look at the AoIP spec to see if they say how to handle this
scenario. But that depends on how the PBX handles this as well. So it
means for handover we always need to look at BSC/SIP+PBX and how it is
handling SDP/RTP.
If I remember correctly,
(b) is what's going to happen if a client is following vanilla SIP spec,
because changing RTP IP/port requires updating SDP which is done with a
re-invite.
(a) is a hack supported by many SIP clients, but it may depend not only on
PBX, but also on its configuration parameters, on SBCs used on a network,
etc
So if you want to be nice to the other party and follow the spec, it's
better to do re-invite :)
Btw, re-invite will need to be implemented anyway if you want to support
call hold.
Please excuse typos. Written with a touchscreen keyboard.
--
Regards,
Alexander Chemeris
CTO/Founder Fairwaves, Inc.
https://fairwaves.co
Now I've actually added some monitoring on all opened and closed sockets in the
python tests, and it turns out the recent patch had no effect because the
tearDown() is overloaded in TestVTYBase.
With every running test, another socket is opened and they aren't closed until
presumably the test py program exits. "40 sockets open", "41 sockets open",
"42 sockets open", ...
Found two places where we need to close sockets, and now the number of open
sockets stays between 0 and 1. Patches are
https://gerrit.osmocom.org/1903https://gerrit.osmocom.org/1905
Will update the docker for openbsc tests when it's merged, and hopefully we can
remove the extra monitoring of tcp sockets soon.
~N