did you load hfcmulti.ko with dslot=1 parameter? this is required to
move dchannel slot from 16 to 1.
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:125 alen =6, dev(0)
channel(0) sapi(63) tei(127)
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:128 <= len = 12,
prim(0x8) id(0x7f3f): DL_INFORMATION_IND
> Mon May 25 16:07:39 2009 <1000> input/misdn.c:135 DL_INFORMATION_IND:
use channel(0) sapi(63) tei(127) for now
> ISDN message for unknown sign_link
>
This patch in conjunction with patch 15 (paging lac) makes patch 8
(paging) obsolete.
> The patch will store the current LAC in the HLC when the subscriber
successfully attaches. If the subscriber detaches, the LAC will be set
to 0.
> This patch is required to make patch 15 (paging) work. This patch
does not depend on any other patch i made.
a minor fix of DMM debugging. now MM debugging is shown, if given by
debug option, not only by default debugging. the color of DNM debugging
changes to cyan as it is supposed to be.
This patch will resolve all BTS with the LAC of the subscriber and page
every BTS with this LAC. If the subscriber is not currently attached,
the LAC is not set, so the caller will get cleared with cause 27 (MO out
of order).
This patch must be applied AFTER patch 12 (application interface) has
been applied.
The patch will store the current LAC in the HLC when the subscriber
successfully attaches. If the subscriber detaches, the LAC will be set
to 0.
This patch is required to make patch 15 (paging) work. This patch does
not depend on any other patch i made.
I improved trau_mux.c. Now it supports not just bridging only. A new
function "trau_recv_lchan" is used to link a channel to a call reference
of a transaction. (Transactions are used in later patches.) TRAU frames
will then be forwarded to the application with the given call reference
(in later patches). Also the application can send TRAU frames by using
"trau_send_lchan".
A new list is introduced in trau_mux.c. (upqueue_entry) All subslots
that must be sent to application are listed here.
Received TRAU frames are written in the upqueue of application
interface, if a call reference is found in the upqueue-list. If an entry
is found the ss_entry list, the TRAU frames are bridged as before. The
frames have a message type (msg_type), a call reference (callref) and a
trau frame (data). The length of trau frame is defined by the content of
the c-bits inside the frame.
There is no support for ip-access yet. Harald must add this in order to
use application interface with ip-access. The bridging with ip-access
works as before.
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- 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)
i don't know if it works with the latest mISDN. have you tested it? if it doesn't work, we need to fix it. do you have any idea why it does not work with mISDN?
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 07:43
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 6_datalink
On Thu, May 21, 2009 at 02:27:35PM +0200, Andreas.Eversberg wrote:
> This patch corrects the handling of data link status change.
thanks, applied - with the exception of the last hunk removing the 'kernel doesnt support sapi' comment. As far as I know, we still need to claim that we use SAPI0, despite in reality using a different one, since the kernel will refuse any non-sapi-0 request from userspace.
Regards,
--
- 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)
here is the problem: we don't know about the called bts, if
- the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL.
- the lchan is not set because paging expires.
we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order)
but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions.
we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result.
-----Ursprüngliche Nachricht-----
Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg
Gesendet: Samstag, 23. Mai 2009 09:47
An: Harald Welte
Cc: openbsc(a)lists.gnumonks.org
Betreff: AW: patch: 8_paging
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 08:30
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
> On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
> > Paging refers to a BTS. To page a mobile phone, the current location
> > is required. If paging succeeds or expires, the BTS structure is
> > also given to the callback function (cbfn).
> >
> > Because paging refers to a BTS, the cbfn (callback function) must
> > include a pointer to bts.
>
> The paging response includes a lchan pointer, which can be resolved to
> the physical channel / timeslot and to the trx and finally to the BTS.
> Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the
BTS of the calling party rather than the called party). So this parameter
is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request()
to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that
is passed back as a reference when calling the call-back function. So
if the bts of the calling or called party needs to be known, it should
probably be referenced from that data structure.
Or am I missing something?
--
- 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)
you can copy compat_af_isdn.h from mISDNuser package, as you did with mISDNif.h. (socket branch) then you don't need the user package. i think i forgot to copy it to the include/openbsc/ directory.
-----Ursprüngliche Nachricht-----
Von: Harald Welte [mailto:laforge@gnumonks.org]
Gesendet: Samstag, 23. Mai 2009 07:24
An: Andreas.Eversberg
Cc: openbsc(a)lists.gnumonks.org
Betreff: Re: patch: 2_misdn
On Thu, May 21, 2009 at 02:27:34PM +0200, Andreas.Eversberg wrote:
> This patch corrects the inclusion of mISDN headers. Also the mISDNif.h
> is updated.
compat_af_isdn.h is not in our source tree. As the current socket-based mISDN headers cannot yet be expected to be present on most linux distributions, I would rather not create any additional external dependencies.
I have no problem with updating our header files, but they should not create additional dependencies.
--
- 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)
