From nhofmeyr at sysmocom.de  Mon May  3 12:10:13 2021
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 3 May 2021 14:10:13 +0200
Subject: pySim ModuleNotFoundError: No module named 'construct'
In-Reply-To: <5975ee65-401f-c74f-e4f3-a25741e02ca8@sysmocom.de>
References: <4509e0a5-872e-6ebd-c982-acfc50e788a4@digitaldissidents.org>
 <YIm5TldekDAoO1d+@nataraja>
 <ac4e5530-e634-7e06-a26c-3011dd9c6629@digitaldissidents.org>
 <5975ee65-401f-c74f-e4f3-a25741e02ca8@sysmocom.de>
Message-ID: <YI/oJaW2iHu1kzWU@my.box>

On Fri, Apr 30, 2021 at 03:51:56PM +0200, Vadim Yanitskiy wrote:
> P.S. So now we have Niels and Neels in the thread ;)

In my school class there was a Niels, a Nils and me. We were "Niels-mit-e"
"Nils-ohne-e" and "Neels-ohne-i".

~N


From nhofmeyr at sysmocom.de  Mon May  3 13:01:08 2021
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 3 May 2021 15:01:08 +0200
Subject: pySim ModuleNotFoundError: No module named 'construct'
In-Reply-To: <fb05c326-9ac0-62e4-1d6e-a7fc4b0a26a1@digitaldissidents.org>
References: <4509e0a5-872e-6ebd-c982-acfc50e788a4@digitaldissidents.org>
 <YIm5TldekDAoO1d+@nataraja>
 <ac4e5530-e634-7e06-a26c-3011dd9c6629@digitaldissidents.org>
 <YIvwA+YTT6dIdbC8@my.box>
 <fb05c326-9ac0-62e4-1d6e-a7fc4b0a26a1@digitaldissidents.org>
Message-ID: <YI/0FCJVJzWpdzf3@my.box>

On Fri, Apr 30, 2021 at 03:57:21PM +0200, Niels ten Oever wrote:
> $ sudo apt install python3-construct

So you are on a debian based system? That really puzzles me because I never had
any trouble of installed packages not being importable.

Now before I go on and suggest that you do a clean installation of your distro,
I decided to try pysim myself on my current debian testing system.

I get this:

	? ./pySim-read.py
	Traceback (most recent call last):
	  File "/home/neels/s/pysim/./pySim-read.py", line 31, in <module>
	    from pySim.ts_51_011 import EF, DF, EF_SST_map, EF_AD
	  File "/home/neels/s/pysim/pySim/ts_51_011.py", line 329, in <module>
	    from pySim.filesystem import *
	  File "/home/neels/s/pysim/pySim/filesystem.py", line 32, in <module>
	    from cmd2 import CommandSet, with_default_category, with_argparser
	ImportError: cannot import name 'CommandSet' from 'cmd2' (/usr/lib/python3/dist-packages/cmd2.py)

after I did this:

	git clone ssh://go/pysim
	cd pysim/
	sudo apt-get install python3-pyscard python3-serial python3-cmd2 python3-construct
	sudo pip3 install pytlv
	sudo pip3 install jsonpath-ng

	? python3 --version
	Python 3.9.2

So I'm also having problems.
Resolving them:

	? ipython3
	Python 3.9.2 (default, Feb 28 2021, 17:03:44)
	Type 'copyright', 'credits' or 'license' for more information
	IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

	In [1]: import cmd2
	---------------------------------------------------------------------------
	ModuleNotFoundError                       Traceback (most recent call last)
	<ipython-input-1-39a0469425e0> in <module>
	----> 1 import cmd2

	~/s/cmd2/cmd2/__init__.py in <module>
	     20 from typing import List
	     21 
	---> 22 from .ansi import style, fg, bg
	     23 from .argparse_custom import Cmd2ArgumentParser, Cmd2AttributeWrapper, CompletionItem, set_default_argument_parser
	     24 

	~/s/cmd2/cmd2/ansi.py in <module>
	     17 )
	     18 
	---> 19 import colorama  # type: ignore [import]
	     20 from colorama import (
	     21     Back,

	ModuleNotFoundError: No module named 'colorama'

I would expect that a generic text prompt library would be able to at least
*start* without color support installed.
(but later on I find out the debian testing version of cmd2 is super old)

	? sudo apt-get install python3-colorama

	? ipython3
	Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
	Type 'copyright', 'credits' or 'license' for more information
	IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

	In [1]: import cmd2
	---------------------------------------------------------------------------
	ModuleNotFoundError                       Traceback (most recent call last)
	<ipython-input-1-39a0469425e0> in <module>
	----> 1 import cmd2

	~/s/cmd2/cmd2/__init__.py in <module>
	     34 # Get the current value for argparse_custom.DEFAULT_ARGUMENT_PARSER
	     35 from .argparse_custom import DEFAULT_ARGUMENT_PARSER
	---> 36 from .cmd2 import Cmd
	     37 from .command_definition import CommandSet, with_default_category
	     38 from .constants import COMMAND_NAME, DEFAULT_SHORTCUTS

	~/s/cmd2/cmd2/cmd2.py in <module>
	     71 )
	     72 
	---> 73 from . import (
	     74     ansi,
	     75     constants,

	~/s/cmd2/cmd2/plugin.py in <module>
	      6 )
	      7 
	----> 8 import attr
	      9 
	     10 from .parsing import (

	ModuleNotFoundError: No module named 'attr'


WTF, does python3-cmd2.deb not list its dependencies?!

	sudo apt-get install python3-attr

	? ipython3
	Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
	Type 'copyright', 'credits' or 'license' for more information
	IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

	In [1]: import cmd2

	In [2]:        

After this, still the same error as I started out with:

	? ipython3
	Python 3.9.2 (default, Feb 28 2021, 17:03:44) 
	Type 'copyright', 'credits' or 'license' for more information
	IPython 7.20.0 -- An enhanced Interactive Python. Type '?' for help.

	In [1]: from cmd2 import CommandSet
	---------------------------------------------------------------------------
	ImportError                               Traceback (most recent call last)
	<ipython-input-1-f665e7ca0d9d> in <module>
	----> 1 from cmd2 import CommandSet

	ImportError: cannot import name 'CommandSet' from 'cmd2' (/usr/lib/python3/dist-packages/cmd2.py)

Installed by the debian-testing package is cmd2 version 0.8.5.
The CommandSet class was added in June 2020 in cmd2 1.3.0.

	? sudo apt-get remove python3-cmd2 
	? sudo pip3 install cmd2
	Successfully installed cmd2-1.5.0

So pip3 gets me the latest version of cmd2.
After that, pySim-read.py starts successfully.
But I get this:

	? ./pySim-read.py -p 0
	Using PC/SC reader interface
	Card reader initialization failed with exception:
	'Failure to establish context: Service not available.'

I remember this, I need to start the PC/SC service or something. I thought it
said so so in the README, alas no such hint is there. So I figure out myself
that it has to be

	? sudo apt-get install pcscd
	? sudo systemctl start pcscd

Now I can successfully pySim-read.py my new sysmoISIM-SJA2,
but right in the end there is an error again:

	? ./pySim-read.py -p 0
	Using PC/SC reader interface
	Reading ...
	Autodetected card type: sysmoISIM-SJA2
	ICCID: 89[...]
	[...200 lines cut...]
	ISIM Service Table: 190200
		Service 1 - P-CSCF address
		Service 4 - GBA-based Local Key Establishment Mechanism
		Service 5 - Support of P-CSCF discovery for IMS Local Break Out
		Service 10 - Support of UICC access to IMS

	Done !

	Exception ignored in: <function PCSCCardConnection.__del__ at 0x7fb7b29190d0>
	Traceback (most recent call last):
	  File "/usr/lib/python3/dist-packages/smartcard/pcsc/PCSCCardConnection.py", line 88, in __del__
	  File "/usr/lib/python3/dist-packages/smartcard/pcsc/PCSCCardConnection.py", line 152, in disconnect
	  File "/usr/lib/python3/dist-packages/smartcard/scard/scard.py", line 502, in SCardDisconnect
	AttributeError: 'NoneType' object has no attribute 'SCardDisconnect'

So I am also having problems, but it is a different class of problem that
Niels-with-i is seeing, because it was solvable by installing the right
dependencies.

Maybe people active in the pysim.git can take this transcript of getting it
running to improve some things? Maybe mention pcscd in the README? Maybe
mention the cmd2 version required?

I'm back to osmo-bsc now.

~N


From mychaela.falconia at gmail.com  Thu May  6 07:25:36 2021
From: mychaela.falconia at gmail.com (Mychaela Falconia)
Date: Wed, 5 May 2021 23:25:36 -0800
Subject: Sharing my mixed success story with Grcard SIMs
Message-ID: <CA+uuBqZLBGFy8qe=_Yf87i85_Jh8iVqXWEJ_SHcNb30sdXh68A@mail.gmail.com>

Hello Osmocom community,

I made some posts here earlier this year about my attempts to obtain
some programmable SIM cards from Grcard (a well-known Chinese
manufacturer of SIM and other smart cards) that are GSM SIM only,
without USIM or ISIM applications - but I just realized that I never
posted anything regarding the final outcome of those escapades.  The
present post is intended to summarize what I obtained and what I
learned through that venture.

The first point to be noted is that Grcard make many bazillion
different card models, but frustratingly, they never let me see any
kind of catalog of their different offerings.  Instead what happened
is that when I first approached them back in January and told them
what I was looking for in very basic terms (I simply said that I
wanted a GSM-only SIM card without any USIM or ISIM stuff), they
offered me one of their card models based on those stated requirements,
they first sent me a few sample pieces of this card model they
selected for me, and then I ended up ordering 200 pieces of that same
model with my own custom printing on the cards.

The card model which Grcard offered to me back in January and of which
I got 200 pcs a month ago in April turned out to be exactly the same
in technical terms as the one that was once sold by Sysmocom as
sysmoSIM-GR2:

https://osmocom.org/projects/cellular-infrastructure/wiki/GrcardSIM2

As I understand it, Sysmocom had that sysmoSIM-GR2 as an offering back
in late 2013, thus it was quite surprising to see that Grcard still
readily sell that exact same model 7 and a half years later - but they
do.  As a result of having done a ton of work with these cards over
the past few months, I now know a lot more about them than is said in
the scant Osmocom wiki page above, and a lot more than the little bits
of knowledge embedded in pySim code from 2013 supporting this model.
Extensive write-ups about these cards can be found in my fc-sim-tools
repository, but here is a basic summary of the good and the bad:

The good:

* These GrcardSIM2 aka FCSIM1 cards are truly native GSM 11.11 SIM,
and do not speak the unwanted-innovation UICC protocol at all.

* F=512 D=8 speed enhancement (the only SIM speed enhancement mode
called for in the original GSM 11.11 spec and the only one implemented
in most classic GSM MS hardware such as Calypso) is supported by these
cards, thus if your GSM MS firmware has this speed enhancement enabled
(at least with TI platform, many legacy fw versions have it disabled -
don't know about other GSM chipset vendors), your phone will talk to
the SIM at about 50781 bps, instead of the circa 8737 bps you get with
the basic non-enhanced F=372 D=1 mode.

* The security model on these cards works the way it is supposed to:
they initially ship with a known default SUPER ADM key, but if you
change both ADM5 and ADM11 (SUPER ADM) keys to your own secrets, then
the card becomes fully secure in the traditional SIM security sense.
I personally don't understand and will likely never understand what is
so wrong with letting your paying service subscribers know their own
Ki and letting them clone their SIM if they so wish, but if you wish
to replicate the traditional security model where you program Ki and
change ADM keys to some secret, you *can* do it with FCSIM1 cards.
Standard PIN1/PIN2/PUK1/PUK2 can be freely reset if you authenticate
with ADM5 or ADM11, but if you change those ADM keys to secrets, then
the PIN system becomes fully secure too.  Contrast the situation with
Grcard's earlier model (sysmoSIM-GR1) where anyone can freely reset
both regular and ADM PINs without any authentication, meaning no
security whatsoever.

* All 3 of COMP128v1, COMP128v2 and COMP128v3 are supported.  I
naturally choose COMP128v3 for my own deployments - A5/1 is weak
enough to begin with, no need to weaken it further by reducing the
effective key length to just 54 bits with COMP128v1 or v2.

* As far as I can tell, there are NO unwanted STK applications on
these cards.  Harald said here earlier that Sysmocom's business
relationship with Grcard ended when Grcard started shipping cards with
some preinstalled STK applications displaying some pop-up messages in
Chinese, but I see no evidence of any such applications being present
on the FCSIM1 cards I got from them this year.  I have tried issuing a
feature-generous TERMINAL PROFILE toward the card (listing support for
all common SAT features), and the SW response was 9000 - no matter
what I tried, I never got the card to respond with SW of 91xx,
indicating some proactive SIM command - thus as far as I can tell,
these SIMs never issue any proactive commands.

* The best good of all: no MOQ!  Instead of being forced to buy 1000
or more cards and have them go to waste because I will never find that
many people who have the same pattern of technology likes and dislikes
as I do, I was able to buy just 200 cards - I could have ordered as
few as 100, but I ordered 200 because they were cheap - and I got those
200 cards with my own custom printing and with my choice of form factor
cut - I chose 2FF-only, of course.

The bad:

* The free reformatting ability that existed on sysmoSIM-GR1 has been
taken away.  On sysmoSIM-GR1 you could erase the card file system and
recreate your own tree of DFs and EFs according to your own liking
(with you deciding which files to include or omit, what size to
allocate for each file, and what access conditions it should have),
but those proprietary APDU commands from GR1 don't work on GrcardSIM2
(FCSIM1), and the official answer from Grcard is that such downstream
reformatting is not allowed.  I am guessing that what I want probably
*can* be done by reformatting the card flash and reloading their
CardOS at a lower level, but needless to say, Grcard won't divulge any
of the knowledge that would be needed for such an endeavor.

* The fixed formatting these cards came with (which we have no way of
changing per above) is far from ideal: EF_AD is only 3 bytes and not 4,
some files that aren't absolutely critical but would be nice to have
like SDN and ECC are missing, and the allocated record size for EF_ADN
is only 28 bytes, allowing only 14 characters for the contact name
field.  Contrast with old T-Mobile USA SIMs that have 44-byte ADN
records (30 characters for contact name), or current Sysmocom cards
that have 34-byte ADN records, allowing 20 characters.  Grcard people
told me that they can change this file system layout to a different
one with MOQ of 10000 pcs, but of course such MOQs are absolutely not
acceptable for "just for love" applications like mine.

* There is no OTA programming capability on this card model.  I was
hoping that I could program EF_MSISDN over the air (yes, I know full
well that a phone doesn't need to know its own MSISDN to make or answer
calls, but all classic GSM phones have a menu command for "Show my
number" or whatever it's called, and that's what EF_MSISDN on the SIM
is for) like I can do on sysmoUSIM-SJS1 and sysmoISIM-SJA2 cards, but
nope, this functionality just isn't there.  Grcard folks were telling
me that they have some other card model that supports OTA, but I never
got a straight answer out of them as to whether that other card model
is also GSM SIM only, or if it is UICC/USIM/ISIM - I suspect the
latter, which would be totally uninteresting to me.

* The worst badness of all is that Grcard people absolutely hate
customers who ask too many technical questions, and when pressed, they
typically respond only with non-answers.  There is basically NO
technical support of the kind we got used to in highly technical
communities like Osmocom with vendors like Sysmocom, instead they are
used to dealing with sales and marketing types.  I also got the
impression that selling to R&D customers is very foreign to them,
instead they are set up for making cards for operator/MVNO type of
customers who let the card vendor do all of the programming at the
factory and don't get into any real technical stuff themselves.

So here is what we got:

https://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_front.jpeg
https://www.freecalypso.org/members/falcon/pictures/SIMs/FCSIM1_back.jpeg

The cards depicted in those photos are quite real, they are sitting
right here at my FreeCalypso HQ in California, and they work in the
sense that I can program everything including IMSI, Ki and COMP128v3
selection.  I haven't set up my own GSM network yet - I already
acquired a couple of nanoBTS units (one for 850 MHz, one for 1900 MHz),
but I still need to acquire a better server machine for running
Osmocom CNI software.

Much like any other feeling and soulful human, I have a deep-rooted
urge to share my work with others.  When it comes to the present SIM
card venture, I am doing everything I can to share my work with the
community in 3 ways:

1) The software I developed for programming these cards is free to the
world, with an explicit public domain license statement:

https://www.freecalypso.org/hg/fc-sim-tools/

My fc-sim-tools suite is a direct competitor to pySim, written in C
instead of Python, and split into separate fc-simtool and fc-uicc-tool
for the two very different protocols that exist for talking to SIM
cards.  Oh, and my tools can be used to program Sysmocom webshop cards
too, not just my Grcard-based FCSIM1.

2) If anyone else would like to buy similar cards from Grcard, I will
be happy to put you in touch with my contact there and guide you through
the process - and by encouraging anyone with a commercial interest to
buy directly from Grcard instead of me acting as a reseller, I
explicitly disavow any thought of commercially profiting from any
related venture or acting as any kind of commercial entity myself.

3) If there is anyone in the world who shares my core philosophical
position whose wording is imprinted on the plastic on my FCSIM1 cards
(see the pictures above) and would like to get a few of these cards,
please let me know, and I will be glad to send you however many cards
you need, for the cost of shipping only, or at most covering my own
cost of ordering more cards in the highly unlikely event that I get
enough interest to run down my stock.

In hacking fellowship,
Mother Mychaela

Hasta la Victoria, Siempre - 2G forever!


From laforge at osmocom.org  Wed May 12 22:00:57 2021
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 13 May 2021 00:00:57 +0200
Subject: Announcement of "OsmoDevCall" on May 14, 2021
Message-ID: <YJxQGU9qKONjC/su@nataraja>

Dear Osmocom community,

It's my pleasure to announce the next OsmoDevCall at

	May 14, 2021 at 20:00 CEST
at
	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This meeting will have the following schedule:

20:00 meet + greet
20:15 presentation by laforge: "SS7 and SIGTRAN in 2G/3G networks"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call

Presentation Abstract:

	This talk will cover some classic circuit-switched SS7 basics as
	well as SIGTRAN (SS7 over IP) and how this is used as underlying
	transport for a variety of interfaces in the 2G (GSM) and 3G
	(UMTS) cellular networks even today.

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From radiarisainanasitraka at yahoo.fr  Tue May 18 11:12:04 2021
From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka)
Date: Tue, 18 May 2021 11:12:04 +0000 (UTC)
Subject: Asking about Modification for USSD RESP
In-Reply-To: <mailman.23.1620129600.43432.openbsc@lists.osmocom.org>
References: <mailman.23.1620129600.43432.openbsc@lists.osmocom.org>
Message-ID: <156126556.2703213.1621336324113@mail.yahoo.com>

Hello,
When the phone send *#100#, the ussd responds with "the extension is xxxx" and it gives option to accept after this like button "ok". My question is it possible to perform this response of ussd for two options "reply" and "cancel" and the phone could reply the answer of the network?


Chears,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20210518/7bafd603/attachment.htm>

From laforge at osmocom.org  Tue May 18 17:33:02 2021
From: laforge at osmocom.org (Harald Welte)
Date: Tue, 18 May 2021 19:33:02 +0200
Subject: Asking about Modification for USSD RESP
In-Reply-To: <156126556.2703213.1621336324113@mail.yahoo.com>
References: <mailman.23.1620129600.43432.openbsc@lists.osmocom.org>
 <156126556.2703213.1621336324113@mail.yahoo.com>
Message-ID: <YKP6Tkqtylp3yJLJ@nataraja>

On Tue, May 18, 2021 at 11:12:04AM +0000, Radiarisainana Sitraka wrote:
> When the phone send *#100#, the ussd responds with "the extension is xxxx" and it gives option to accept after this like button "ok". My question is it possible to perform this response of ussd for two options "reply" and "cancel" and the phone could reply the answer of the network?

this doesn't make sense in the use case of 'show me my own number'.  In general
you can implement this as so-called "EUSE" (External USSD Entity), see
see https://git.osmocom.org/osmo-hlr/tree/src/osmo-euse-demo.c for an
example on how to develop your own USSD applications that plug into
osmo-hlr.


-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From keith at rhizomatica.org  Thu May 27 01:26:04 2021
From: keith at rhizomatica.org (Keith)
Date: Wed, 26 May 2021 20:26:04 -0500
Subject: LCLS and osmo-sip-connector
Message-ID: <bc6d1694-bc87-1b5a-1469-60a2b7577066@rhizomatica.org>

Hi all.

I would like to implement some functionality that existed as a kind of
happy accident?, in the osmocom-nitb

That is - that media endpoints in INVITEs/200s and re-INVITEs from a SIP
UA to osmo-sip-connector just ended up being transparently communicated
to osmo-bts. This made it really easy to take the pbx out of the audio
stream.

I wanted to share where I am at with that.

freeswitch even has a console command for this: "uuid_media" can switch
the pbx in and out of the stream during the call. In the case of a MS to
MS call on the same bts, we just connect the two osmo-bts media
endpoints to each other. Freeswitch can schedule to playback message on
calls and such like - for "your credit ran out" message for example -
and it works pretty good. FS knows to put itself back into the stream
with a re-INVITE with it's own IP in the SDP before playing the audio
and invites itself back out of the stream as soon as playback is finished.

I've been looking on and off, not that I've given it a huge amount of
time, at how to replicate this with the BSC/MSC/MGW/SIP combination.

First thing was to fix up the BSS messages and Global Call Reference
generation. (TS 23.284) Given that Max had done most of this, that's
pretty easy, although I got lost at one point down a rabbit hole of
trying to figure out more than I needed to with the FSM and BSS
messages, and that put me off working on it for a while.

Anyway, https://gerrit.osmocom.org/c/osmo-msc/+/24236 exists and
"works"? - that is you can do LCLS with either mgw-loop or bts-loop
configured on the BSC - but only for the internal mncc, obviously as the
osmo-sip-connector still does not know what to do with the GCR (global
call reference)

I thought about various hackish things to do. (maintain a table of
call-ids and their gcr on the sip conn and add an X-Osmo-CallID header
to the SIP) but I've also been looking at the specs.

TS 29.164 (section 6) says that the GCR should be encapsulated in a
binary encoded ISUP payload, there are pointers in the spec to ITU
Q.1912.5 (Section5 and thereabouts) So the ISUP messages should be added
to SIP messages, requiring a multipart MIME attachment to the INVITE
with the SDP and the ISUP. Also see RFC3204?

What I don't know is how sip UEs will respond to these. I wonder will
they decode them, I doubt it, some searching for SIP-I support in
FreeSwitch confirms no support.

So I'm thinking that I need to serialise the GCR and add it to an "X-"
SIP header, so we at get it back on the B-leg.

So yes, I need to just do this, but I got stalled a bit again with my
lack on programming skills trying to learn how to serialise the GCR the
"right" way. - but once I figure that out, then I can at least test what
happens and see how the MSC and MGW behaves with the MNCC messages that
result from SIP re-INVITES.

Maybe that just works, but I don't think so, I think I will need to
implement more BSS LCLS messages to actually change the LCLS states, not
just update media endpoints.

Sometimes I wonder here what should happen in the sip conn and what in
the MSC.

Anyway, It's been on my mind to write this up quickly to the ML just in
case somebody has a "OH... better not do it like that" type comment..

Thanks

k.






From laforge at osmocom.org  Thu May 27 19:30:19 2021
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 27 May 2021 21:30:19 +0200
Subject: Announcement of "OsmoDevCall" on May 28, 2021
Message-ID: <YK/zS/SDy7mVF+iv@nataraja>

Dear Osmocom community,

It's my pleasure to announce the next OsmoDevCall at

	May 28, 2021 at 20:00 CEST
at
	https://meeting4.franken.de/b/har-xbc-bsx-wvs

This meeting will have the following schedule:

20:00 meet + greet
20:15 presentation by fixeria: "Hacking binary protocols with Pycrate"
21:00 USSE: unstructured supplementary social event [*]
22:00 close of call

Attendance is free of charge and open to anyone with an interest
in Osmocom.

More information about OsmoDevCall, including the schedule
for further upcoming events can be found at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall

Looking forward to meeting you on Friday.

Best regards,
	Harald

[*] this is how we started to call the "unstructured" part of osmocom
developer conferences in the past, basically where anyone can talk about
anything, no formal schedule or structure.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Fri May 28 13:34:12 2021
From: laforge at osmocom.org (Harald Welte)
Date: Fri, 28 May 2021 15:34:12 +0200
Subject: LCLS and osmo-sip-connector
In-Reply-To: <bc6d1694-bc87-1b5a-1469-60a2b7577066@rhizomatica.org>
References: <bc6d1694-bc87-1b5a-1469-60a2b7577066@rhizomatica.org>
Message-ID: <YLDxVJHZaeCg/Dly@nataraja>

On Wed, May 26, 2021 at 08:26:04PM -0500, Keith wrote:
> That is - that media endpoints in INVITEs/200s and re-INVITEs from a SIP
> UA to osmo-sip-connector just ended up being transparently communicated
> to osmo-bts. This made it really easy to take the pbx out of the audio
> stream.

yes, but it unfortunately also measn you cannot have separate, non routed
networks between RAN and core network, which anyone with a reasonable interest
in network security always wants to have,  so you have to put some kind of
RTP proxy like osmo-mgw co-located at the BSC level, as the BSC is the only
element that has connectivity with the CN.

> freeswitch even has a console command for this: "uuid_media" can switch
> the pbx in and out of the stream during the call. [...]

interesting to know, thanks.

> TS 29.164 (section 6) says that the GCR should be encapsulated in a
> binary encoded ISUP payload, there are pointers in the spec to ITU
> Q.1912.5 (Section5 and thereabouts) So the ISUP messages should be added
> to SIP messages, requiring a multipart MIME attachment to the INVITE
> with the SDP and the ISUP. Also see RFC3204?

oh my. Seriously?  I just re-read the specs starting from 23.284 for
LCLS and ideed you seem to be correct :(

> So I'm thinking that I need to serialise the GCR and add it to an "X-"
> SIP header, so we at get it back on the B-leg.

makes sense.

> So yes, I need to just do this, but I got stalled a bit again with my
> lack on programming skills trying to learn how to serialise the GCR the
> "right" way. 

isn't there already some kind of function to print it to a string?

> - but once I figure that out, then I can at least test what
> happens and see how the MSC and MGW behaves with the MNCC messages that
> result from SIP re-INVITES.

Which re-invites?  I think it might be useful to create a ladder diagram
of how you think this all works together.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From zs.cheng at hotmail.com  Wed May 26 15:44:24 2021
From: zs.cheng at hotmail.com (=?utf-8?B?56iLIOWtkOW4hQ==?=)
Date: Wed, 26 May 2021 15:44:24 +0000
Subject: Help on reading values of ISIM
Message-ID: <26DE0DD5-EA4E-411B-B47F-51974E57CD79@contoso.com>

Dear Osmocom community,

I am using pysim to read values of ISIM. However, it just returns "None, None". And the aids of my SIM card is ['a0000000871002ff86ffff89ffffffff']. It seems does not have ISIM application on my SIM card.

How should I read values of ISIM?

Best regards,
Zishuai CHENG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20210526/270e633c/attachment.htm>