Hi all,
I think we are close to the point of no return. All tickets and wikis have been imported. Please have a quick look if there is something obviously broken and if not I will proceed with post-processing and renaming tonight.
kind regards
holger
Hi,
When running lintian on openbsc, I get the following error:
E: osmocom-bsc-nat: possible-gpl-code-linked-with-openssl
E: osmocom-nitb: possible-gpl-code-linked-with-openssl
It seems like openbsc is being linked with libcrypto from OpenSSL, but I cannot
find any statement of OpenSSL exception for the AGPL. Debian policy requires
this.
Can you look into this? You can have a look at wget if you need an example.
Ruben
The openbsc branches to use for testing IuPS and IuCS have changed,
because Daniel and I have merged the branches.
They used to be daniel/gprs-iu (IIRC) and sysmocom/cscn.
Both are now merged as:
sysmocom/iu
Holger, this is relevant to our coverity configuration.
We are still using other branches that may or may not be merged to their
respective masters. I'd like to publicly record here why or why not we
should merge them now. Please add any reasons you know.
We're using master for Iu[h|CS|PS] in:
libasn1c: * master
libosmo-abis: * master
libosmocore: * master
openggsn: * master
osmo-python-tests: * master
osmo-iuh: * master
Reasons NOT to merge to master in:
openbsc: * sysmocom/iu
- hardcoded kc and sres for testing
- NITB and most probably osmo-bsc are not operational
- A-interface not implemented in CSCN
asn1c: * aper-prefix
- ?
libosmo-netif: * sysmocom/sctp
- ?
libosmo-sccp: * laforge/wip
- ?
Thanks for any additions...
~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: Holger Freyther, Harald Welte
Hi,
First of all I would like to thank you guys for working on an awesome project
and contributing so much nice code!
I've been working on getting the Osmocom libraries into Debian. libosmocore has
been there for some time now, but I recently also got libosmo-sccp,
libosmo-abis, libosmo-netif, libsmpp34 (not directly osmocom) and openggsn in.
This means that all dependencies for building openbsc, osmo-bts and osmo-pcu
should be available in Debian. I would also like to thank you for keeping a
quite well-maintained debian directory in the tar-balls, even with good state
of SONAME-ing etc. I've used this as the starting point where possible, but
also modified them to meet "Debian standard".
It would be great if you could test the packages and also verify that the
copyright files contain all the copyright holders. Let me know on this list or
on private email if there is something missing or wrong.
Here are links to all copyright files:
https://tracker.debian.org/media/packages/libo/libosmo-abis/copyright-0.3.2…https://tracker.debian.org/media/packages/libo/libosmo-netif/copyright-0.0.…https://tracker.debian.org/media/packages/libo/libosmo-sccp/copyright-0.7.0…https://tracker.debian.org/media/packages/libo/libosmocore/copyright-0.9.0-4https://tracker.debian.org/media/packages/libs/libsmpp34/copyright-1.10-1https://tracker.debian.org/media/packages/o/openggsn/copyright-0.92-1
You will have to run Debian sid (unstable) to directly install the packages
using "apt install", but you could also download the .deb-files manually from:
https://packages.debian.org/unstable/[packagename] or for Ubuntu here:
https://launchpad.net/ubuntu/xenial/+source/[packagename]
I'm also aware of that the code is moving ahead rapidly and what is in Debian
unstable now may quickly get out-of-date. But I will try to keep them up-to-
date as much as possible, and also provide backport packages. Getting the
packages in the first time is usually much more cumbersome than keeping them
up-to-date.
For those interested in Ubuntu, the current versions will most likely get
into the next long-term support release (16.04), since its freeze date
for package imports from Debian is already Feb 18th. So let me know quickly
if there is something wrong so that I possibly may be able to fix it before the
freeze (when it's much more straight forward).
Cheers,
Keep up the good work.
Ruben
From: Max <msuraev(a)sysmocom.de>
Previously the presence of header and data blocks were communicated
in-band which decreases code readability and makes it unnecessary hard
to add support for new hardware.
Note: both OsmoBTS and OsmoPCU have to be modified to take advantage of
extended ph_data_param structure.
---
include/osmocom/gsm/l1sap.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/osmocom/gsm/l1sap.h b/include/osmocom/gsm/l1sap.h
index 9f3fe98..1af8ba8 100644
--- a/include/osmocom/gsm/l1sap.h
+++ b/include/osmocom/gsm/l1sap.h
@@ -25,6 +25,16 @@ enum osmo_mph_info_type {
PRIM_INFO_DEACT_CIPH, /*!< \brief Deactivation of ciphering */
};
+/*! \brief PH-DATA presence information */
+enum osmo_ph_pres_info_type {
+ PRES_INFO_INVALID = 0, /*!< \brief Data is invalid */
+ PRES_INFO_HEADER = 1, /*!< \brief Only header is present and valid */
+ PRES_INFO_FIRST = 3, /*!< \brief First half of data + header are valid (2nd half may be present but invalid) */
+ PRES_INFO_SECOND = 5, /*!< \brief Second half of data + header are valid (1st halfmay be present but invalid) */
+ PRES_INFO_BOTH = 7, /*!< \brief Both parts + header are present and valid */
+ PRES_INFO_UNKNOWN
+};
+
/*! \brief for PH-RANDOM_ACCESS.req */
struct ph_rach_req_param {
uint8_t ra; /*!< \brief Random Access */
@@ -48,6 +58,7 @@ struct ph_data_param {
uint8_t chan_nr; /*!< \brief Channel Number (Like RSL) */
uint32_t fn; /*!< \brief GSM Frame Number */
int8_t rssi; /*!< \brief RSSI of receivedindication */
+ enum osmo_ph_pres_info_type pdch_presence_info; /*!< \brief Info regarding presence/validity of header and data parts */
};
/*! \brief for TCH.{req,ind} | TCH-RTS.ind */
--
2.7.1
Hi list,
during testing of OsmoCSCN, I find that osmo-hnbgw connects to the CN
servers once, but when such a CN component restarts, no new connection is
established. Sequence:
- start hnbgw, which continuously tries to connect to CS and PS CN servers
every five seconds (osmo-cscn and dummy-cn in my case).
- start dummy-cn, hnbgw connects.
- start osmo-cscn, hnbgw connects.
- osmo-cscn segfaults ;)
- hnbgw logs the disconnect
- I restart osmo-cscn
- but hnbgw never attempts to reconnect to osmo-cscn.
- so I have to restart hnbgw, hnb-test and its VTY connection "all the
time", which is cumbersome.
I briefly tried to resolve the issue, but I'm losing patience. I tried to
enable the DLINP debug logging but found that hnbgw's VTY doesn't allow me
to manipulate logging levels, apparently.
Next I'd have liked to set the hnbgw_log_info to indicate
[DLINP] = { .loglevel = LOGL_DEBUG }
but DLINP is negative. Does this really have to be as fiendish?
I guess the INT2IDX() macro doesn't apply here, as it would cause index
overlaps with the other D* constants. It can be really hard to find my way
around the Osmo source code, with the little non-obvious things
accumulating...
I did find that much: the reconnect flag passed to
osmo_stream_cli_open2()
is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a
first connection is established. Now, if upon disconnect, something were
to set the state back to
cli->state = STREAM_CLI_STATE_CONNECTING
my guess is that the cli_timer_cb() would indeed attempt to reconnect as I
intend.
BTW, what does cli stand for? Not command-line interface, is it.
If I stayed onto this I'd probably solve the issue. My focus should be on
an IuCS Location Update though, so comments or help is appreciated :)
So long I'll carry on with the workaround, restarting hnbgw "all the time".
Thanks!
~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: Holger Freyther, Harald Welte
I noticed that osmo-iuh/src/regen-common-includes.sh doesn't do anything
useful (anymore). Should it be redirected towards osmo-iuh/include or can
we drop it?
osmo-iuh/src/regen-common-includes.sh:
[[[
#!/bin/sh
#for f in `(cd ../asn1/hnbap/asn1c && ls --color=none -1 *.h)`; do echo "#include \"$f\""; done
for f in ranap/*.h; do echo "#include \"$f\""; done
]]]
Thanks
~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: Holger Freyther, Harald Welte
Hi Harald,
in osmo-iuh/doc/hnb_cs_lu.msc I find that after the location update
request from the UE, an identity request "should" follow from the CN.
Yesterday I made my first pcap using our hNodeB and that weighty black UE
we use for testing, and saw that the MSC indeed sends out an identity
request at that time [1], however, the UE simply never responds to it.
My question: is the hnb_cs_lu.msc declarative and definitely correct, or
could it be that in 3G, UEs in general expect authentication first, as
the "osmo-iuh/pcap/UPP RANAP.pcap" suggests (starting at packet #335).
Since my sources tell me (i.e. Daniel) that an identity request at that
time is indeed kinda special practise by openbsc to collect all IMEIs we
possibly can, I'm going for authentication first.
Just wanted to make sure you agree that the hnb_cs_lu.msc may be erratic
in that case. Thanks!
~Neels
[1] near openbsc/src/libmsc/gsm_04_08.c:589 (thanks Daniel!)
--
- 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: Holger Freyther, Harald Welte
Dear autoconf,
I have received no reply yet, so am taking the liberty to <bump>.
BTW, is there a way to verify that this report has reached someone,
besides waiting for an email reply?
Thanks!
~Neels
On Thu, Jan 14, 2016 at 02:40:38PM +0100, Neels Hofmeyr wrote:
> Dear autoconf,
>
> I am observing a bug with `autoreconf -i`.
> To my/our knowledge, this is not due to an error in
> our configuration but a genuine bug from 'subdir-objects'.
>
> The symptom: after running ./configure, I find a directory
> src/tests/\$(top_srcdir)
>
> (The string that looks like a variable that is to be expanded is written to the
> file system in verbatim, as the directory name.)
>
> The weird dir contains only a .deps dir with dependency files for the src/*
> files (not for src/tests/* files as one might expect).
>
> If I remove 'subdir-objects' from configure.ac, the weird dir is not created.
>
>
> Reproduction recipe on debian stable:
>
> ▶ autoreconf --version
> autoreconf (GNU Autoconf) 2.69
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+/Autoconf: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
>
> Written by David J. MacKenzie and Akim Demaille.
>
>
> ▶ git clone git://git.osmocom.org/osmo-iuh
> Cloning into 'osmo-iuh'...
> remote: Counting objects: 5945, done.
> remote: Compressing objects: 100% (2661/2661), done.
> remote: Total 5945 (delta 4991), reused 3757 (delta 3228)
> Receiving objects: 100% (5945/5945), 12.11 MiB | 8.97 MiB/s, done.
> Resolving deltas: 100% (4991/4991), done.
> Checking connectivity... done.
>
> ▶ cd osmo-iuh/
>
> ▶ sed -i 's/^PKG_/dnl &/' configure.ac
>
> ▶ autoreconf -i
> aclocal: warning: couldn't open directory 'm4': No such file or directory
> libtoolize: putting auxiliary files in `.'.
> libtoolize: copying file `./ltmain.sh'
> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
> libtoolize: copying file `m4/libtool.m4'
> libtoolize: copying file `m4/ltoptions.m4'
> libtoolize: copying file `m4/ltsugar.m4'
> libtoolize: copying file `m4/ltversion.m4'
> libtoolize: copying file `m4/lt~obsolete.m4'
> libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
> configure.ac:5: installing './compile'
> configure.ac:5: installing './config.guess'
> configure.ac:5: installing './config.sub'
> configure.ac:7: installing './install-sh'
> configure.ac:7: installing './missing'
> src/Makefile.am: installing './depcomp'
>
> ▶ ./configure
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking how to print strings... printf
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 1572864
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
> checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking for gawk... no
> checking for mawk... mawk
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for mt... mt
> checking if mt is a manifest tool... no
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking whether make sets $(MAKE)... yes
> checking for style of include used by make... GNU
> checking whether make supports nested variables... yes
> checking dependency style of gcc... gcc3
> checking whether make supports nested variables... (cached) yes
> checking whether make sets $(MAKE)... (cached) yes
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking for ANSI C header files... (cached) yes
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating libosmo-ranap.pc
> config.status: creating src/Makefile
> config.status: creating src/hnbap/Makefile
> config.status: creating src/ranap/Makefile
> config.status: creating src/rua/Makefile
> config.status: creating src/tests/Makefile
> config.status: creating Makefile
> config.status: creating include/Makefile
> config.status: creating include/osmocom/Makefile
> config.status: creating include/osmocom/hnbap/Makefile
> config.status: creating include/osmocom/ranap/Makefile
> config.status: creating include/osmocom/rua/Makefile
> config.status: executing libtool commands
> config.status: executing depfiles commands
> config.status: executing src/tests/atconfig commands
>
> ▶ ls -F src/tests/
> atconfig Makefile test_common.h test-hnbap.ok $(top_srcdir)/
> dummy_cn_sua.c Makefile.am test-helpers.c test-ranap.c
> hnb-test.c Makefile.in test-helpers.ok test-ranap.ok
> hnb-test.h test_common.c test-hnbap.c testsuite.at
>
>
> Observe '$(top_srcdir)/' in file listing.
>
>
> ▶ ls -aR src/tests/\$\(top_srcdir\)/
> src/tests/$(top_srcdir)/:
> ./ ../ src/
>
> src/tests/$(top_srcdir)/src:
> ./ ../ .deps/
>
> src/tests/$(top_srcdir)/src/.deps:
> ./ hnbap_common.Po hnbap_encoder.Po rua_decoder.Po rua_msg_factory.Po
> ../ hnbap_decoder.Po rua_common.Po rua_encoder.Po
>
>
>
> Please excuse my not trying to verify the bug with the latest sources. To my
> knowledge, this bug applies to the latest released version (2.69) and I hope it
> will not be an effort to you if the bug is already known to be fixed.
>
> Thank you for your time!
>
> ~Neels
>
> (I am not subscribed to any autoconf ML, hence a Cc to my sender address is
> appreciated)
--
- 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: Holger Freyther, Harald Welte
Hi,
you may be aware that the '#include "config.h"' in libasn1c's asn_system.h
breaks builds with the out-of-the-box 'make install'. So far we go to the
installed header and remove that line.
This time I've removed the line from the source tree before building, and
I can't find any effect really. My source tree has no config.h file to
begin with.
But I'm not sure what would be a point of failure there. When I commit
this, will I break something I merely happen to not be using? Any autoconf
guru here that could resolve this with a quick glance?
http://git.osmocom.org/libasn1c/tree/configure.achttp://git.osmocom.org/libasn1c/tree/include/asn1c/asn_system.h
Thanks,
~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: Holger Freyther, Harald Welte
Hi Niti,
On 02/16/2016 08:53 AM, Niti Rohilla wrote:
> Hi All,
>
> I want to enable GTP-U in OpenVswitch. I have implemented the code for the GTP-U in ovs and submitted the same on ovs-dev.
>
> As currently, GTP-U support is not available in upstream linux kernel, so to create a GTP port in ovs we have to load the openvswitch kernel
> module to linux kernel.
>
> I have received some review comments stating that first I have to implement the code for GTP-U in upstream linux kernel in netdev net-next
> tree then it can be incorporated into ovs.
>
> I want to know the process of how to implement and get the code for GTP-U into upstream linux kernel.
>
> If anybody is working on the same how can I help them to get it in into the upstream linux kernel quickly.
I'm a bit out of touch with OVS, so my idea on how this should work might be wrong.
As far as I understand OVS, the way forward would be to use the lwtunnel infrastructure to enable OVS to use a kernel GTP module.
Our current OVS module ([1], [2]) is not (yet) using lwtunnel, but we do plan on switching to that.
So far, we have been coordinating the GTP kernel module development on the OpenBSC ML [3]. The goal is to upstream it as soon as all the
basics are covered (smallish netlink API changes, final touches on IPv6 and maybe lwtunnel).
On the OVS side, someone would then need to implement the necessary ops to handle GTP lwtunnel integration.
Andreas
[1]: http://git.osmocom.org/osmo-gtp-kernel
[2]: https://github.com/RoadRunnr/osmo-ggsn
[3]: https://lists.osmocom.org/mailman/listinfo/openbsc
>
>
> Thanks & Regards
> Niti Rohilla
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
I'm trying to get rid of all BTS backpointers in libmsc.
In libmsc/gsm_04_08.c, in gsm48_rx_mm_serv_req(), I find:
if (is_siemens_bts(bts))
send_siemens_mrpci(msg->lchan, classmark2-1);
My conclusion so far is that this "hook" should move to the BSC code, but
I could use some comforting approval by more apt contenders... Some
detail:
send_siemens_mrpci() is found in libbsc/gsm_04_08_utils.c:
int send_siemens_mrpci(struct gsm_lchan *lchan,
uint8_t *classmark2_lv)
{
struct rsl_mrpci mrpci;
if (classmark2_lv[0] < 2)
return -EINVAL;
mrpci.power_class = classmark2_lv[1] & 0x7;
mrpci.vgcs_capable = classmark2_lv[2] & (1 << 1);
mrpci.vbs_capable = classmark2_lv[2] & (1 <<2);
mrpci.gsm_phase = (classmark2_lv[1]) >> 5 & 0x3;
return rsl_siemens_mrpci(lchan, &mrpci);
}
IIUC the Siemens BS11 BTS needs to be tickled with a vendor-specific RSL
message as soon as a CM service request (GSM48_MT_MM_CM_SERV_REQ) or a paging
response is received from a subscriber.
Only the BSC knows which BTS is involved, so I'd try to find some place in
libbsc/ or osmo-bsc/ to move this away to.
The same function is called from gsm48_handle_paging_resp() in libbsc.
Any shortcuts / workarounds or could this also be dropped entirely?
It does look like that particular case is indeed missing from osmo-bsc.
Who is this Mister PCI anyway? ;)
The gsm48_handle_paging_resp() function leads me to another, more general
question: often, there are two bts pointers around, namely the
gsm_subscriber_connection->bts
as well as the
lchan->ts->trx->bts
Are these typically/always/never expected to be the same bts struct?
(In this function, both bts pointers are used, and I'd like to understand why.)
Thanks!
~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: Holger Freyther, Harald Welte
Hi everybody,
we have just done the first download of an Internet page using the
current bleeding EDGE development version of the OSMO-PCU. Supported are
MCS-1 to MCS-9 in downlink and MCS-1 to MCS-4 in uplink direction.
The download of 'www.osmocom.org' has been documented in a PCAP file and
can be downloaded from
https://openbsc.osmocom.org/trac/wiki/osmo-pcu
To decode the data blocks, an experimental patch for the gsmtab
dissector is also available from there.
Cheers
Jacob
--
- Jacob Erlbeck <jerlbeck(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Hi,
Can someone here help me debug the failing build of libosmocore in Ubuntu?
See:
https://launchpadlibrarian.net/235791225/buildlog_ubuntu-xenial-amd64.libos…
The test case "gprs-bssgp" fails with following output:
stderr:
MESSAGE to 0x7f0000ff, msg length 12
02 00 81 01 01 82 0b 56 04 82 0b 55
All NS-VCs for NSEI 2901 are either dead or blocked!
All NS-VCs for NSEI 2901 are either dead or blocked!
BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified
BSSGP BVCI=1234 Rx BVC STATUS, cause=Unknown BVCI
NSEI=2901/BVCI=2989 Cannot handle PDU type 34 for unknown BVCI, NS BVCI 2989
Unable to resolve NSEI 4660 to NS-VC!
Assert failed rc >= 0 gb/gprs_bssgp_test.c:234
I think it is related to the hardening option "-D_FORTIFY_SOURCE=2". What is
interesting is that it builds correctly in Debian, but not Ubuntu.
The issue has apparently been observed before:
http://comments.gmane.org/gmane.comp.mobile.osmocom.baseband.devel/4149
If this gets fixed quickly, it might go into the next Ubuntu LTS version which
has import freeze Feb 18th.
Cheers,
Ruben
This commit adds this predicate function which can be used to
avoid the execution of code if a certain log level is not enabled.
The function will only return 0 (false), if it is sure that a logging
call for the same facility and level will not produce any output.
This safety criterion shall ensure, that no logging output is lost
due to the use of this predicate as a guard. On the other hand, even
if the predicate returns != 0 (true), no logging output might get
generated by a similar logging command.
Note that the current implementation is not focussed on performance,
which could be improved by using a lookup table instead of iterating
through every target.
Sponsored-by: On-Waves ehf
---
include/osmocom/core/logging.h | 1 +
src/logging.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h
index 1c159d0..290b33d 100644
--- a/include/osmocom/core/logging.h
+++ b/include/osmocom/core/logging.h
@@ -198,6 +198,7 @@ void logp2(int subsys, unsigned int level, const char *file,
int line, int cont, const char *format, ...)
__attribute__ ((format (printf, 6, 7)));
int log_init(const struct log_info *inf, void *talloc_ctx);
+int log_check_level(int subsys, unsigned int level);
/* context management */
void log_reset_context(void);
diff --git a/src/logging.c b/src/logging.c
index 876964a..c7b1999 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -865,4 +865,43 @@ int log_init(const struct log_info *inf, void *ctx)
return 0;
}
+/*! \brief Check whether a log entry will be generated.
+ * \returns != 0 if a log entry might get generated by at least one target */
+int log_check_level(int subsys, unsigned int level)
+{
+ struct log_target *tar;
+
+ if (subsys < 0)
+ subsys = subsys_lib2index(subsys);
+
+ if (subsys > osmo_log_info->num_cat)
+ subsys = DLGLOBAL;
+
+ /* TODO: The following could/should be cached (update on config) */
+
+ llist_for_each_entry(tar, &osmo_log_target_list, entry) {
+ struct log_category *category;
+
+ category = &tar->categories[subsys];
+ /* subsystem is not supposed to be logged */
+ if (!category->enabled)
+ continue;
+
+ /* Check the global log level */
+ if (tar->loglevel != 0 && level < tar->loglevel)
+ continue;
+
+ /* Check the category log level */
+ if (tar->loglevel == 0 && category->loglevel != 0 &&
+ level < category->loglevel)
+ continue;
+
+ /* This might get logged (ignoring filters) */
+ return 1;
+ }
+
+ /* We are sure, that this will not be logged. */
+ return 0;
+}
+
/*! @} */
--
1.9.1
Hi all,
this is diverting a mail dialog that started off privately to this list,
for the benefit of everyone.
You may have noticed that Daniel is working on IuPS (3G/UMTS data conns)
and I'm working on the OsmoCSCN, which is going to handle IuCS (3G/UMTS
voice calls).
There was still some puzzlement around connection IDs and how to reach a
mobile device (aka UE). In particular, which ID or information do I store
to identify the link to a UE, and how do I find a UE in case of paging?
First off, we're so far implementing a special case where we're using a
HNB-GW to demultiplex voice and data (IuCS and IuPS) from an hNodeB
(femto-cell). ASCII art to illustrate, view in a monospaced font:
UE 1 <--> |hNodeB 1| <-->|HNB-GW| <---> |CSCN or SGSN
| 1 | |
UE 2 <--> |hNodeB 2| <-->| | |
UE 3 <--> | | | |
|
|
UE 4 <--> |hNodeB 3| <-->|HNB-GW| <---> |
| 2 | |
UE 5 <--> |hNodeB 4| <-->| | |
UE 6 <--> | | | |
So, how does a CSCN know where to send a message for a given UE, and how
does it reach that UE?
Turns out the picture is more like this:
. . . (hNodeB) . . . (HNB-GW)
UE1 <--> | Cell <--1--> [RNC] <------------> [CSCN]
UE2 <--> |
Meaning that the hNodeB actually encloses an RNC (Radio Network
Controller) and a single radio cell. The HNB-GW does pretty much
"invisible" forwarding of the SCCP|SUA connection to the RNC. Each RNC has
a global RNC ID, and can manage N radio cells. In the hNodeB case, there
is exactly one cell behind the RNC, but the general case looks like this:
UE1 <--> | Cell <-----> |RNC1 <------------> |CSCN
UE2 <--> | | |
| |
UE3 <--> | Cell <-----> | |
|
|
UE4 <--> | Cell <-----> |RNC2 <------------> |
UE5 <--> | | |
| |
UE6 <--> | Cell <-----> | |
When a UE calls, the CSCN receives a User SAP link with a conn_id, and
simply routes the reply back to this link and conn_id. The reply goes
right back to the RNC, and the RNC knows which cell the UE is at.
The case where the CN contacts a UE is known as paging, i.e. the request
by the CN that the UE shall please establish a connection to the CN. The
CSCN may encounter different cases here: a User SAP link may have been
established and is still present, or no link is available (e.g. a link has
existed before but has been torn down due to a Reset by the RNC, etc.).
If the link is still valid, this manifests as: the struct
gsm_subscriber_connection still has a valid pointer to an osmo_sua_link,
and iu_tx() feeds the conn_id to this link to reach the UE.
(Note that the gsm_subscriber_connection struct does not yet have an
osmo_sua_link pointer. I will move the ue_conn_ctx into the
gsm_subscriber_connection struct in an upcoming commit.)
If, e.g. due to a Reset, the osmo_sua_link pointer has been cleared, the
CSCN or SGSN will ask the HLR: where has the last location update for this
IMSI been registered? Each RNC can manage several location areas, further
divided into several service areas, and once the HLR has identified the
service area where the UE is expected, the CSCN or SGSN can identify the
RNC by the global RNC ID and send the paging request in that direction.
A bit of pseudo struct code:
struct gsm_network {
llist of struct gsm_subscriber_connection:
{
{
struct gsm_subscriber subscr {
char imsi[GSM_IMSI_LENGTH];
};
struct {
struct osmo_sua_link *link; /* point into an rnc struct */
uint32_t conn_id;
} iu;
},
...
};
llist of struct rnc (does not exist yet) :
{
struct osmo_sua_link *link; /* upon link-down, clear the above */
...
};
};
So, IIUC, the global RNC ID resolved from the HLR info should identify the
path to a particular UE. The CSCN knows which RNC is behind which of its
local link endpoints. In our special case with an HNB-GW and when there
are several hNodeB instances behind the HNB-GW, the HNB-GW knows which way
to send a connection reply by the established SCCP|SUA link, or which way
to send a paging request by the RNC ID. The finer code details here are
not entirely known to me yet, but I hope that the answers will come
naturally or have already been implemented by Daniel ;)
If any questions, answers or comments emerge in your mind while reading
this, please don't hesitate and share!
Thanks,
~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: Holger Freyther, Harald Welte
Hi.
There are bunch of functions like osmo_counter_* and osmo_stats_reporter_* in
libosmocore and other projects.
I'm pretty much understand what they do, but what happens on the receiving end?
There's nothing in our wiki regarding statsd.
How do you guys use it? Any statsd config examples? Workflow hints?
With such an elaborate functionality there got to be somebody who actually uses it.
Please share your experience, configs, pretty screenshots and complaints :)
cheers,
Max.
Hi,
before the l1sap changes were merged I fixed a case where after a ip.access CRCX with recvonly mode the BTS would already start to send RTP frames to UDP port 0 which will trigger an ICMP unreachable. This is not harmful but still a bug. After the l1sap merge the sysmobts is still doing it when it receives a TCH frame and all other bts models behave like before the bugfix. The below diff copies this into the common code.
Besides administratives work I try to work on the SMSC, so if anyone could testdrive this patch and check for ICMP errors it would be greatly appreciated.
holger
From: Daniel Willmann <daniel(a)totalueberwachung.de>
Hello,
it seems PDP context updates was never really used/tested to an Update PDP
context would not go through. The following patches fix that (at least for
gtpv1).
Regards
Daniel
Daniel Willmann (3):
gtp: Pass pdp along when calling gtp_req() in gtp_update_context()
gtp: Make gtp_update_pdp_conf() work for gtp0 and gtp1 connections
gtp: Handle gtpv1 in gtp_update_pdp_conf() correctly
gtp/gtp.c | 162 +++++++++++++++++++++++++++++++++++++++++++++-----------------
1 file changed, 118 insertions(+), 44 deletions(-)
--
2.1.4
--
- Daniel Willmann <dwillmann(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
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
Is this a proper way to copyright OsmoCSCN? I'm trying to mention both the
facts that it's something new as well as that it is based on a copy-paste of
OsmoNITB:
/* (C) 2016 by sysmocom s.f.m.c. GmbH <info(a)sysmocom.de>
* All Rights Reserved
*
* Based on OsmoNITB:
* (C) 2008-2010 by Harald Welte <laforge(a)gnumonks.org>
* (C) 2009-2012 by Holger Hans Peter Freyther <zecke(a)selfish.org>
* All Rights Reserved
[...]
Thanks!
~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: Holger Freyther, Harald Welte
I'm using LCR as a GSM <-> SIP interface and I've been trying to figure out
why MO calls result in a segfault. I am running openbsc on cdc548cb and LCR
on c14326641a built and run on an ubuntu 14.04 64bit.
>From what I've investigated so far, the request_uri passed to sofia-sip is
malformed.
Has anyone seen this problem before? Would appreciate pointers.
Here are the full logs and stack trace:
** LCR Version 1.14
> 000000 DEBUG (in route.c/getrulesetbyname() line 1928): ruleset main found.
> 000000 DEBUG (in sip.cpp/sip_init() line 1997): SIP globals initialized
> 000000 DEBUG (in gsm.cpp/mncc_socket_retry_cb() line 1443): Connected to
> MNCC socket /tmp/bsc_mncc!
> su_port_create(0x6ad410): epoll_create() => 0: OK
> su_socket_port_init(0x6ad410, 0x7ffff7dcf880) called
> su_pthread_port_init(0x6ad410, 0x7ffff7dcf880) called
> nua: nua_create: entering
> [New Thread 0x7ffff6c52700 (LWP 11520)]
> su_port_create(0x7ffff00008c0): epoll_create() => 0: OK
> su_socket_port_init(0x7ffff00008c0, 0x7ffff7dcf880) called
> su_pthread_port_init(0x7ffff00008c0, 0x7ffff7dcf880) called
> nua: nua_stack_init: entering
> nua: nua_stack_set_params: entering
> soa_create("default", 0x7ffff0001130, 0x7ffff0001230) called
> soa_set_params(static::0x7ffff0001920, ...) called
> soa_set_params(static::0x7ffff0001920, ...) called
> nta_agent_create: initialized hash tables
> nta_agent_create: initialized transports
> nta_agent_create: initialized random identifiers
> nta_agent_create: initialized timer
> nta_agent_create: initialized resolver
> tport_create(): 0x7ffff0003df0
> nta: master transport created
> tport_bind_server(0x7ffff0003df0) to */127.0.0.1:5062/sip
> tport_bind_server(0x7ffff0003df0): calling tport_listen for udp
> tport_alloc_primary(0x7ffff0003df0): new primary tport 0x7ffff0004470
> tport_listen(0x7ffff0004470): listening at udp/127.0.0.1:5062/sip
> tport_bind_server(0x7ffff0003df0): calling tport_listen for tcp
> tport_alloc_primary(0x7ffff0003df0): new primary tport 0x7ffff0004910
> tport_listen(0x7ffff0004910): listening at tcp/127.0.0.1:5062/sip
> nta: bound to (127.0.0.1:5062;transport=*)
> nta: agent_init_via: SIP/2.0/udp 127.0.0.1:5062 (sip)
> nta: agent_init_via: SIP/2.0/tcp 127.0.0.1:5062 (sip)
> nta: Via fields initialized
> nta: Contact header created
> nua_register: Adding contact URL '127.0.0.1' to list.
> nua: nua_set_params: entering
> nua((nil)): sent signal r_set_params
> 000000 DEBUG (in sip.cpp/sip_init_inst() line 1942): SIP interface created
> (inst=0x6acce0)
> nua((nil)): recv signal r_set_params
> nua: nua_stack_set_params: entering
> soa_set_params(static::0x7ffff0001920, ...) called
> nua((nil)): event r_set_params 200 OK
> LCR 1.14 started, waiting for calls...
> 000000 TRACE 15.01.16 11:36:21.011 --: LCR 1.14 started, waiting for
> calls...
> nua: nua_application_event: entering
> 000000 DEBUG (in sip.cpp/sip_callback() line 1785): Event 23 from stack
> received (handle=(nil))
> 000000 DEBUG (in port.cpp/Port() line 210): new port (1) of type 0x3101,
> name 'gsm-0-in' interface 'gsm'
> 000000 DEBUG (in gsm.cpp/Pgsm() line 239): Created new GSMPort(gsm-0-in).
> 000000 DEBUG (in gsm_bs.cpp/Pgsm_bs() line 56): Created new
> GSMBSPort(gsm-0-in).
> 000000 TRACE 15.01.16 11:37:28.210 CH(1): New call ref LCR<->BSC callref
> new=0x8000000d
> 000000 TRACE 15.01.16 11:37:28.210 CH(1): Codec negotiation LCR<->BSC
> bearer capa='given by MS' speech version='Full Rate given'
> 000000 TRACE 15.01.16 11:37:28.210 CH(1): MNCC_SETUP_IND LCR<->BSC
> calling number=639360100037 imsi=901550000000824 dialing number=12345678
> 000000 DEBUG (in endpoint.cpp/Endpoint() line 48): EPOINT(1): Allocating
> enpoint 1 and connecting it with: ioport
> 000000 DEBUG (in endpoint.cpp/portlist_new() line 150): EPOINT(1)
> allocating port_list, attaching to port 1
> 000000 DEBUG (in appbridge.cpp/EndpointAppBridge() line 31): Bridge
> endpoint created
> 000000 DEBUG (in port.cpp/epointlist_new() line 131): PORT(1) allocating
> epoint_list.
> 000000 TRACE 15.01.16 11:37:28.211 CH(1): MNCC_CALL_PROC_REQ LCR<->BSC
> progress coding=3 location=1 descr=8
> 000000 DEBUG (in port.cpp/new_state() line 283): PORT(gsm-0-in) new state
> PORT_STATE_IDLE --> PORT_STATE_IN_PROCEEDING
> 000000 TRACE 15.01.16 11:37:28.211 CH(1): MNCC_FRAME_RECV LCR<->BSC
> 000000 DEBUG (in gsm_bs.cpp/setup_ind() line 631): Request RTP peer info,
> before forwarding setup
> 000000 DEBUG (in gsm.cpp/rtp_create_ind() line 869): Got RTP peer info
> (7f000001,52103) forwarding setup
> 000000 DEBUG (in message.c/_message_put() line 70): message MESSAGE_SETUP
> written from 140733193388033 to 140733193388033 (memory 6b1a50 at file
> gsm.cpp, line 872)
> 000000 DEBUG (in message.c/message_get() line 115): message MESSAGE_SETUP
> reading from 1 to 140733193388033 (memory 6b1a50)
> 000000 DEBUG (in appbridge.cpp/port_setup() line 94): EPOINT(1) epoint
> received setup from='639360100037' to='12345678'
> 000000 DEBUG (in port.cpp/Port() line 210): new port (2) of type 0x2002,
> name 'sip-0-out' interface 'sip'
> 000000 DEBUG (in sip.cpp/Psip() line 72): Created new Psip(sip-0-out).
> 000000 DEBUG (in endpoint.cpp/portlist_new() line 150): EPOINT(1)
> allocating port_list, attaching to port 2
> 000000 DEBUG (in message.c/_message_put() line 70): message MESSAGE_SETUP
> written from 1 to 2 (memory 6b1a50 at file message.c, line 94)
> 000000 DEBUG (in message.c/_message_put() line 70): message MESSAGE_BRIDGE
> written from 1 to 1 (memory 6b6c00 at file appbridge.cpp, line 222)
> 000000 DEBUG (in message.c/_message_put() line 70): message MESSAGE_BRIDGE
> written from 1 to 2 (memory 6ba6e0 at file appbridge.cpp, line 225)
> 000000 DEBUG (in message.c/message_get() line 115): message MESSAGE_SETUP
> reading from 140733193388033 to 2 (memory 6b1a50)
> 000000 DEBUG (in sip.cpp/message_setup() line 954): Doing Setup (inst
> 0x6acce0)
> 000000 DEBUG (in sip.cpp/message_setup() line 961): RTP info given by
> remote, forward that
> 000000 DEBUG (in sip.cpp/message_setup() line 968): local ip 7f000001 port
> 52103
> 000000 DEBUG (in sip.cpp/message_setup() line 969): remote ip 00000000
> port 0
> nua: nh_create_handle: entering
> 000000 TRACE 15.01.16 11:37:28.816 CH(2): NEW handle handle new=0x6b09c0
> 000000 DEBUG (in sip.cpp/message_setup() line 1038): Using SDP for invite:
> v=0
> o=LCR-Sofia-SIP 0 0 IN IP4 127.0.0.1
> s=SIP Call
> c=IN IP4 127.0.0.1
> t=0 0
> m=audio 52103 RTP/AVP 3
> a=rtpmap:3 GSM/8000
> 000000 TRACE 15.01.16 11:37:28.816 CH(2): INVITE from uri=
> sip:639360100037@127.0.0.1:5062 to uri=sip:12345678@192.168.40.100:5060
> rtp ip=127.0.0.1 port=52103,52104 payload=GSM:3
> nua: nua_invite: entering
> nua(0x6b09c0): sent signal r_invite
> 000000 DEBUG (in port.cpp/new_state() line 283): PORT(sip-0-out) new state
> PORT_STATE_IDLE --> PORT_STATE_OUT_SETUP
> 000000 DEBUG (in sip.cpp/message_setup() line 1069): do proceeding
> 000000 DEBUG (in port.cpp/new_state() line 283): PORT(sip-0-out) new state
> PORT_STATE_OUT_SETUP --> PORT_STATE_OUT_PROCEEDING
> 000000 DEBUG (in message.c/_message_put() line 70): message
> MESSAGE_PROCEEDING written from 2 to 1 (memory 6be1c0 at file sip.cpp, line
> 1072)
> 000000 DEBUG (in port.cpp/epointlist_new() line 131): PORT(2) allocating
> epoint_list.
> 000000 DEBUG (in message.c/message_get() line 115): message MESSAGE_BRIDGE
> reading from 1 to 1 (memory 6b6c00)
> 000000 DEBUG (in port.cpp/message_epoint() line 657): PORT(gsm-0-in)
> bridging to id 1
> nua(0x6b09c0): recv signal r_invite
> 000000 DEBUG (in port.cpp/bridge() line 1305): Port 1 creating not
> existing bridge 1.
> 000000 DEBUG (in message.c/message_get() line 115): message MESSAGE_BRIDGE
> reading from 1 to 2 (memory 6ba6e0)
> 000000 DEBUG (in port.cpp/message_epoint() line 657): PORT(sip-0-out)
> bridging to id 1
> nua: nua_stack_set_params: entering
> 000000 DEBUG (in port.cpp/bridge() line 1290): Port 2 found existing
> bridge 1.
> 000000 DEBUG (in message.c/message_get() line 115): message
> MESSAGE_PROCEEDING reading from 2 to 1 (memory 6be1c0)
> 000000 DEBUG (in appbridge.cpp/port_other() line 259): EPOINT(8) epoint
> received message 7070144 from port
> 000000 DEBUG (in message.c/_message_put() line 70): message
> MESSAGE_PROCEEDING written from 1 to 140733193388033 (memory 6be1c0 at file
> message.c, line 94)
> 000000 DEBUG (in message.c/message_get() line 115): message
> MESSAGE_PROCEEDING reading from 1 to 1 (memory 6be1c0)
> nua(0x6b09c0): adding session usage
> nta_leg_tcreate(0x7ffff0006b00)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff6c52700 (LWP 11520)]
> strlen () at ../sysdeps/x86_64/strlen.S:106
> 106 ../sysdeps/x86_64/strlen.S: No such file or directory.
> (gdb) bt
> #0 strlen () at ../sysdeps/x86_64/strlen.S:106
> #1 0x00007ffff7b70896 in url_xtra (url=url@entry=0x7ffff00075d0) at
> url.c:1048
> #2 0x00007ffff7b2deaf in sip_request_create (home=home@entry=0x7ffff0006fc0,
> method=method@entry=sip_method_invite, name=0x7ffff7b916e2
> <sip_method_name_invite> "INVITE",
> name@entry=0x7ffff7b8ed49 "INVITE", uri=uri@entry=0x7ffff00075d0,
> version=version@entry=0x0) at sip_basic.c:225
> #3 0x00007ffff7ae3512 in nta_msg_request_complete (msg=msg@entry=0x7ffff0006fc0,
> leg=leg@entry=0x7ffff0006b00, method=method@entry=sip_method_invite,
> method_name=method_name@entry=0x7ffff7b8ed49 "INVITE",
> request_uri=0x7ffff00075d0, request_uri@entry=0x0) at nta.c:3890
> #4 0x00007ffff7b07d92 in nua_client_request_sendmsg (cr=cr@entry=0x7ffff0005af0)
> at nua_client.c:803
> #5 0x00007ffff7b08de9 in nua_client_request_try (cr=0x7ffff0005af0) at
> nua_client.c:708
> #6 0x00007ffff7b06b93 in nua_client_init_request0 (cr=0x7ffff0005af0) at
> nua_client.c:605
> #7 nua_client_init_request (cr=0x7ffff0005af0) at nua_client.c:442
> #8 0x00007ffff7b07246 in nua_client_create (nh=nh@entry=0x6b09c0,
> event=event@entry=31, methods=methods@entry=0x7ffff7dc4d20
> <nua_invite_client_methods>, tags=tags@entry=0x6b0eb0)
> at nua_client.c:199
> #9 0x00007ffff7b1cc61 in nua_stack_invite (nua=nua@entry=0x6adc80,
> nh=nh@entry=0x6b09c0, e=e@entry=nua_r_invite, tags=tags@entry=0x6b0eb0)
> at nua_session.c:705
> #10 0x00007ffff7b03eb3 in nua_stack_signal (nua=0x6adc80, msg=<optimized
> out>, ee=0x6b0e88) at nua_stack.c:582
> #11 0x00007ffff7b522b2 in su_base_port_execute_msgs (queue=0x0) at
> su_base_port.c:280
> #12 0x00007ffff7b527bd in su_base_port_run (self=0x7ffff00008c0) at
> su_base_port.c:335
> #13 0x00007ffff7b52f10 in su_pthread_port_clone_main (varg=0x7fffffffe4c0)
> at su_pthread_port.c:324
> #14 0x00007ffff7840182 in start_thread (arg=0x7ffff6c52700) at
> pthread_create.c:312
> #15 0x00007ffff6d4d47d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
>
>