Re: OpenBTS OsmocomBB Asterisk

*Thanks to all who responded !!!*

In a network from scratch page describes how to connect the 2 phones.
open-bsc.cfg 2 time-slots:
*timeslot 0 -   phys_chan_config CCCH+SDCCH4
timeslot 1 -  phys_chan_config TCH/H*

When I run this option, then when I do a test call at 995 (hold music) lcr I
get:
*000000 ERROR (in gsm.cpp/audio_send() line 461): HR frame, but encoder not
created.                                     
000000 ERROR (in gsm.cpp/frame_receive() line 320): HR frame, but decoder
not created.
*

Because http://openbsc.osmocom.org/trac/wiki/OpenBSC says following:
*«TCH/H voice calls (they work in osmo-bsc, but not in osmo-nitb)»*

then I set
timeslot 0 -   phys_chan_config CCCH+SDCCH4
timeslot 1 -  phys_chan_config TCH/F
and the test call 995 (hold music) lcr works well.

I register in the test network is the second phone to call on the first
phone I need another channel TCH/F i.e. timeslot 2 - phys_chan_config TCH/F

I looked commit 687bc2318d18073d02756ef6ea5b96799f4b9aa7

*Allow transceiver application to handle multiple TRX and multiple phones*
There is no more one-to-one relation between application state, trx instance
(Continue reading)

Re: OpenBTS OsmocomBB Asterisk

On Mon, Jul 7, 2014 at 3:55 PM, trixbox.t <trixbox.t@yandex.ru> wrote:
how to add third_phone for TS 2???

One would have to add at least the code that accepts the -3, -4, etc option on the command line and set up the transceiver data structures as appropriate. It is possible that more work beyond this is needed; I haven't looked at it closely yet.

Cheers,
Rusty D

Vedr: OpenBTS OsmocomBB Asterisk

From http://lists.osmocom.org/pipermail/osmocom-commitlog/2013-February/003570.html
I read : "Calypso BTS uses tx_mask and rx_mask to define which slots to TX or RX"

Then, when looking at the case for 3 phones and trying to modify tx_mask and rx_mask
for TS 2 could it be  something like this?

as -> l1[2].tx_mask=0x03 /* TS 2 */
as -> l1[2].rx_mask=0x03 /* TS 2 */
as -> l1[1].tx_mask=0x02 /* TS 1 */
as -> l1[1].rx_mask=0x02 /* TS 1 */
as -> l1[0].tx_mask=0xdf /* TS 5,6,7,0 */
as -> l1[0].rx_mask=0x01 /* TS 0 */

/regards
erich  


Den Mandag, 7. juli 2014 23.12 skrev Rusty Dekema <rdekema@gmail.com>:


On Mon, Jul 7, 2014 at 3:55 PM, trixbox.t <trixbox.t@yandex.ru> wrote:
how to add third_phone for TS 2???

One would have to add at least the code that accepts the -3, -4, etc option on the command line and set up the transceiver data structures as appropriate. It is possible that more work beyond this is needed; I haven't looked at it closely yet.

Cheers,
Rusty D


Re: Vedr: OpenBTS OsmocomBB Asterisk

Thank you! Seems logical, but not working...
can't understand the meaning of the string:
as -> l1[0].tx_mask = 0xdf /* TS 5,6,7,0 */ ???

was
as->l1l[0].tx_mask = 0xe3; /* TS 5,6,7,0,1 */

then
as->l1l[0].tx_mask = 0xe1; /* TS 5,6,7,0 */

what does 5,6,7,0,1 and why they don't ordered,
and where 2,3,4 ???

I changed the line struct l1ctl_link l1l[3];
and line struct trx *trx[3];
in the app.h , otherwise have been seg.fault...

/regards
alex

09.07.2014, 23:37, "Erich Dachleger" <edachleger@yahoo.com>:
> From http://lists.osmocom.org/pipermail/osmocom-commitlog/2013-February/003570.html
> I read : "Calypso BTS uses tx_mask and rx_mask to define which slots to TX or RX"
>
> Then, when looking at the case for 3 phones and trying to modify tx_mask and rx_mask
> for TS 2 could it be  something like this?
>
> as -> l1[2].tx_mask=0x03 /* TS 2 */
> as -> l1[2].rx_mask=0x03 /* TS 2 */
> as -> l1[1].tx_mask=0x02 /* TS 1 */
> as -> l1[1].rx_mask=0x02 /* TS 1 */
> as -> l1[0].tx_mask=0xdf /* TS 5,6,7,0 */
> as -> l1[0].rx_mask=0x01 /* TS 0 */
>
> /regards
> erich
>
> Den Mandag, 7. juli 2014 23.12 skrev Rusty Dekema <rdekema@gmail.com>:
>
> On Mon, Jul 7, 2014 at 3:55 PM, trixbox.t <trixbox.t@yandex.ru> wrote:
>
>> how to add third_phone for TS 2???
>
> One would have to add at least the code that accepts the -3, -4, etc option on the command line and set up the
transceiver data structures as appropriate. It is possible that more work beyond this is needed; I
haven't looked at it closely yet.
>
> Cheers,
> Rusty D