All,
Does there exist a document describing to which port the callagent (MSC)
has to connect to, how and where the CIC to RTP IP/port mapping table is
defined etc?
Regards,
Kristian
--
*Kristian Martens*
Software Engineer
Mobile: +49 160 1024262
Office: +49 30 65218529
/
ng4T GmbH
Siemensdamm 50
13629 Berlin
Germany
www.ng4t.com <http://www.ng4t.com>
/
Berlin-Charlottenburg, HRB 123546
Geschäftsführer Dr. Andreas Kallmann
All,
I have seen that it is planned to implement the full AoIP stack for a
standalone OpenBSC. Do have any idea by when this feature could be ready
to use?
Best regards,
Kris
Dear Team,
I am trying to find out KI Value of Anristu MT8820C Test SIm
Card using Pysim Software.
I am using Identiv uTrust 2900 R Smart Card Reader and Identiv
SCR35xx USB Smart Card Reader.
When I put *./pySim-read.py -p 0 *in the terminal it shows the
following error
*.*
Please help me to proceed further.
[image: Inline image 1]
Thanks and Regards....
Rajasekar
Hello All,
We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine.
When Dynamic TCH tested with the old BSC commit version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel.
Please let us know if it is known issue.
Thanks and Regards,
Mrinal
Dear Raul,
In 2012 the Osmocom OpenBSC project started to use your libsmpp34 in
order to add SMPP capabilities to our GSM Netwrok In The Box (NITB).
As there was no source code repository (svn, git. ...) of your library
around at the time, we imported the latest version you had released
(1.10) into a git repository at http://git.osmocom.org/libsmpp34/
Ever since we have been chcecking your sourceforge project occasionally
to see if you had made any further releases, in order to re-synchronize
them. Ther hasn't been any release ever since.
Meanwhile, various (small) improvements have been happening in our git
repository, but those changes are of course not visible to the new user
who is ending up on your sourceforge.net project page.
In order to avoid further confusion to the user, I would like to ask
your input on how we should proceed.
* do you still have plans for this library?
* do you want to run a git repo on sf.net and merge our contributions?
* would you consider designating the git.osmocom.org server as the
official source code repository, maybe even moving other content from
sf.net to https://osmocom.org/projects/libsmpp34
I would appreciate if you could at least put a notice on sf.net
indicating that there is a more actively maintained fork of your library
available at the above URLS.
Let me know if there is something we can do to help, or if you have any
other comments.
Thanks,
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)
So far the state of IuCS aka 3G voice is such that we will not merge the branch
to master unless we have a proper A-interface.
But come to think of it, it would technically be possible to split the code not
by git branches, but rather by the --enable-iu configure switch. In that case
openbsc master would contain all IuCS code, and if compiled with --enable-iu,
compile time switches would disable osmo-nitb, enable osmo-cscn and (currently)
destroy 2G due to lack of an A-interface implementation.
The benefit would be simply to not have a separate branch, making for easier 3G
build instructions and possibly reducing rebase merge conflicts; developers
could adjust the 3G code paths along with their 2G patches.
It's just an idea that came to mind... In the end it's just a kind of "fake"
merge, so not sure whether it's worth the effort.
Any thoughts?
~N
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Hi all,
for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good
name.
The background: we're in the process of separating libmsc from libbsc. Both use
the structs gsm_network and gsm_subscriber_connection, and both of these
structs contain elements that are used only by libbsc or only by libmsc,
besides the elements that are used by both. So at some point I will "split"
both of these in two, to have a BSC and an MSC version thereof.
How should we name them?
struct gsm_network
(note, if there is a common part, that could still be named 'gsm_network')
--> bsc_network / msc_network
looks familiar but the meaning of the name is lost
--> gsm_bsc / gsm_msc
--> osmo_bsc / osmo_msc
To me these would be the best and the names are still available, but there
are header files named like this and the osmo-bsc binary also has a very
similar name. I think I would go for these anyway.
+1
--> osmo_gsm_bsc / osmo_gsm_msc
As alternative, but the gsm is a bit out of place (particularly in the
light of a UMTS MSC).
struct gsm_subscriber_connection
--> bsc_subscriber_connection / msc_subscriber_connection
but we could use the opportunity to shorten the name
--> bsc_subscr_conn / msc_subscr_conn
I like these best; but add osmo?
+1
--> osmo_bsc_subscr_conn / osmo_msc_subscr_conn
almost the old length.
Happy shedding, "+1" comments and/or opinions welcome
~Neels
--
- Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Harald Welte
Dear all,
I have just moved the Osmocom GSUP HLR code from the really unrelated
ancient osmo-auc.git repository into its own osmo-hlr.git repository.
The GSUP HLR is a stand-alone HLR for SIM and USIM based subscribers
which exposes the GSUP protocol towards its users. Currently in
openbsc master, there is OsmoSGSN which supports this protocol.
There is ongoing work to remove the HLR from OsmoNITB and make it access
the GSUP HLR asynchronously. I originally intended to complete this
in summer this year,but was constantly delayed due to various other
tasks :/
Neels is now coming to the rescue and is in charge of moving this ahead
to get it ready to merge.
The osmo-gsup-hlr is still very simplistic. It's a single-threaded
architecture and uses only sqlite3 tables as back-end. It is suitable
for installations of the scale that OsmoNITB was able to handle. It
also lacks various features like fine-grained control of subscribed
services (like supplementary services). The most important goal for
osmo-gsup-hlr is to be a replacement for the HLR code we'r removing from
good old OsmoNITB. It is *not* supposed to be a fully-featured GSM HLR.
One of the advantages of having the GSUP protocol for both CS and PS
side is that there could be other, more scalable/powerful
implementations of the HLR that can just be swapped in.
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)
