[cid:9b893015-fe6c-4d05-9933-7169f767fc97]
________________________________ From: OpenBSC openbsc-bounces@lists.osmocom.org on behalf of openbsc-request@lists.osmocom.org openbsc-request@lists.osmocom.org Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc@lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6
Send OpenBSC mailing list submissions to openbsc@lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request@lists.osmocom.org
You can reach the person managing the list at openbsc-owner@lists.osmocom.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris)
----------------------------------------------------------------------
Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov ikostov@sysmocom.de To: Neels Hofmeyr nhofmeyr@sysmocom.de Cc: Harald Welte laforge@gnumonks.org, openbsc@lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: 06726d26-d66f-d48d-cf9d-533178a13ada@sysmocom.de Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Neels,
Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure.
regards, Ivaylo
On 08.02.2017 16:26, Neels Hofmeyr wrote:
(found this mail stuck in my outbox, sending late)
On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote:
Hi Harald,
I see. What was communicated to me was that NITB channel configuration TCH/F_TCH/H_PDCH is not supported with nanoBTS.
I will have in mind that nanoBTS does not support HR (v1) codec.
Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised because from some discussion it appeared that the nanoBTS supports HR, and I was expecting TCH/F only.
While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not?
~N
--
------------------------------ - Ivaylo Kostov ikostov@sysmocom.de mailto:ikostov@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 Director: Harald Welte ------------------------------
------------------------------
Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte laforge@gnumonks.org To: Neels Hofmeyr nhofmeyr@sysmocom.de Cc: Ivaylo Kostov ikostov@sysmocom.de, openbsc@lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: 20170208154557.2rmslkrzuqlv7xc4@nataraja Content-Type: text/plain; charset=us-ascii
Hi all,
On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote:
While talking about codecs, the ip.access nanoBTS *should* in fact support the TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of your testing procedure and add it if not?
libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'.
Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR).
In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place.
For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;)
-- - Harald Welte laforge@gnumonks.org http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr nhofmeyr@sysmocom.de To: Harald Welte laforge@gnumonks.org Cc: Ivaylo Kostov ikostov@sysmocom.de, openbsc@lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: 20170208234335.GB27422@my.box Content-Type: text/plain; charset="us-ascii"
On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote:
libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'.
i.e. checks on the VTY level.
Seems like we want an issue for that: https://osmocom.org/issues/1946
~N
