> I don't understand. This callback will be called with data you need to
write
> to the network. In case of MTP Level3 you will need to wrap that around
the
> msgb you got.
I means: is the interaction with mtp3 layer implemented (is sending sccp
data by mtp3 implemented by the library?)?
Also, what about the reception of data from mtp3 layer. is that implemented
in the sccp lib.
I am asking these questions because I see the code of mtp3 in the lib but no
significant call is present in the sccp part of the lib.
Thank you for your help.
Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi Harald,
On Wed, Apr 6, 2016 at 12:59 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
> Can you or somebody else interested in getting this resolved provide a
> full bug report, including
> * debug log output on OsmoNITB side for for the rsl and nm
> * debug log output on OsmoBTS side for oml / transceiver interface or
> anything else related
> * pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
> the control commands between osmo-bts-trx and osmo-trx
Attached are the logs for master branches of OpenBSC, OsmoBTS, and
OsmoTRX leading up to the following RACH access behavior.
<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x2
Hopefully, somebody more familiar than myself with A-bis and related
L1/L2 dependencies can provide some insight on why the above is
happening or where to start debugging. I'll be happy to test any
subsequent changes or look into specific parts of the A-bis code.
-TT
Hi,
It might interest you that OpenBSC has entered Debian unstable today!
https://tracker.debian.org/news/755641
Please test the package and file bugs as you find them. I haven't added init/service files
yet to the package, since it needs some careful thought around what default is the best
for the general users.
Best regards,
Ruben
Dears,
hope this finds you well,
kiindly i need to know how to configure the GT and PC for the various
simulated nodes in osmo-nitb as am testing some security scripts to
simulate different roaming attacks using the MAP protocol
appreciate your support
best regards
Hi,
Is there a way to have an application (ex: trx for calypso BTS) run over the motorola phone immediately after turning the phone ON. In other words, if I flash it to the firmware I want the phone start working as a BTS without having to select it manually from the menu.
Best regards,
Robert,
Dear List,
I am in the process of creating the Wiki page for Ettus B200/B210 with OpenBSC, GPRS and Asterisk.
I am quite close, both data and calls are working, but the voice calls are half sided. The downlink direction works, but the uplink does not.
I tried without Asterisk and LCR (between two phones) and still the calls are half sided.
In the mean time I got these messages in the Osmo-BTS log:
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284768 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284764 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284764 to transmit.
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x09 fn=1284772 ts=1 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x09 link_id=0x00 fn=1284772 ts=1 tr x=0
<0006> scheduler.c:379 TCH RTS.ind: chan=TCH/F chan_nr=0x0a fn=1284772 ts=2 trx= 0
<0006> scheduler.c:276 PH-DATA.req: chan_nr=0x0a link_id=0x00 fn=1284772 ts=2 tr x=0
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=1 at f n=1284768 to transmit.
<0006> scheduler.c:1036 TCH/F has not been served !! No prim for trx=0 ts=2 at f n=1284768 to transmit.
SMS and GPRS seems to be fine.
If someone have any idea, I would love to hear it. :-)
Thanks!
Csaba
From: Max <msuraev(a)sysmocom.de>
Previously it was possible to send RTP data to port 0. This produce
multiple errors during the beginning of RTP transmission.
To address this OSMO_RTP_F_DISABLED flag was introduced. It's set by
default for all new RTP sessions. It can be manually unset after the
call to osmo_rtp_socket_create(). When the flag is set it prevents
transmission and reception of RTP frames for the session. The flag is
unset automatically in osmo_rtp_socket_connect() when session is bound
to non-zero remote port.
Fixes: OS#1662
---
include/osmocom/trau/osmo_ortp.h | 1 +
src/trau/osmo_ortp.c | 14 ++++++++++++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/include/osmocom/trau/osmo_ortp.h b/include/osmocom/trau/osmo_ortp.h
index c02cca8..2ca9cfc 100644
--- a/include/osmocom/trau/osmo_ortp.h
+++ b/include/osmocom/trau/osmo_ortp.h
@@ -29,6 +29,7 @@ enum osmo_rtp_param {
/*! \brief Flag to indicate the socket is in polling-only mode */
#define OSMO_RTP_F_POLL 0x0001
+#define OSMO_RTP_F_DISABLED 2
/*! \brief A structure representing one RTP socket */
struct osmo_rtp_socket {
diff --git a/src/trau/osmo_ortp.c b/src/trau/osmo_ortp.c
index 65ec269..22c5856 100644
--- a/src/trau/osmo_ortp.c
+++ b/src/trau/osmo_ortp.c
@@ -149,6 +149,8 @@ static void ortp_sig_cb_ts(RtpSession *rs, void *data)
int osmo_rtp_socket_poll(struct osmo_rtp_socket *rs)
{
mblk_t *mblk;
+ if (rs->flags & OSMO_RTP_F_DISABLED)
+ return 0;
mblk = rtp_session_recvm_with_ts(rs->sess, rs->rx_user_ts);
if (mblk) {
@@ -313,7 +315,7 @@ struct osmo_rtp_socket *osmo_rtp_socket_create(void *talloc_ctx, unsigned int fl
if (!rs)
return NULL;
- rs->flags = flags;
+ rs->flags = OSMO_RTP_F_DISABLED | flags;
rs->sess = rtp_session_new(RTP_SESSION_SENDRECV);
if (!rs->sess) {
talloc_free(rs);
@@ -382,11 +384,16 @@ int osmo_rtp_socket_bind(struct osmo_rtp_socket *rs, const char *ip, int port)
int osmo_rtp_socket_connect(struct osmo_rtp_socket *rs, const char *ip, uint16_t port)
{
int rc;
-
+ if (!port) {
+ LOGP(DLMIB, LOGL_INFO, "osmo_rtp_socket_connect() refused to "
+ "set remote %s:%u\n", ip, port);
+ return 0;
+ }
/* enable the use of connect() so later getsockname() will
* actually return the IP address that was chosen for the local
* sid of the connection */
rtp_session_set_connected_mode(rs->sess, 1);
+ rs->flags &= ~OSMO_RTP_F_DISABLED;
rc = rtp_session_set_remote_addr(rs->sess, ip, port);
if (rc < 0)
@@ -411,6 +418,9 @@ int osmo_rtp_send_frame(struct osmo_rtp_socket *rs, const uint8_t *payload,
mblk_t *mblk;
int rc;
+ if (rs->flags & OSMO_RTP_F_DISABLED)
+ return 0;
+
mblk = rtp_session_create_packet(rs->sess, RTP_FIXED_HEADER_SIZE,
payload, payload_len);
if (!mblk)
--
2.8.1
Hi!
I have some questions regarding GSUP design and current implementation
in ordre to help me undestand the rationale behind some of the
decisions.
1) why are the fields like msisdn, vlr address, hlr address,, sgsn
address still in their encoded form as part of struct
osmo_gsup_message? If there is a decoding/encoding function, why
does it not go all the way? Would anyone object if I was to change
this?
2) osmo_gsup_message conatains multiple fields + associated length
fields. Wy not have a 'struct osmo_buflen { char *buf; size_t len }'
which is re-used for all such fields that have buffer + length? Then
the respective code for dealing with such types could be generalized
and shared.
3) why is the INSERT SUBSCRIBER DATA ignored by the SGSN, but rather it
seems to expect the subscribe data piggy-backed onto the LOCATION
UPDATE RESULT? This seems to break the idea of staying as close as
possible to the MAP level transactions while avoiding the
encoding/decoding and underlying signalling protocol complexities.
Thanks in advance.
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)
