Added limitation option for maximum dialed digits. If dial string exceeds
that limit, overlap-dialing is used to complete dial string.
Siemens EWSD (APS V16) only allows 20 digits at a time.
modified: README
modified: chan_lcr.c
modified: default/interface.conf
modified: dss1.cpp
modified: dss1.h
modified: ie.cpp
modified: interface.c
modified: interface.h
added support for asterisk 1.6. it now compiles with both 1.4 and 1.6. (tested with 1.4 only) thanx to gregor for his valuable help!
modified: bchannel.c
modified: chan_lcr.c
modified: config.h.in
modified: configure
modified: configure.ac
modified: lcradmin.c
modified: main.c
Last commit by Andreas changed matching semantics to make it possible
to go directly into the dialplan _without_ dialing any digits by implicitly
dialing the 's' extension.
That is fine, if there is one to match :)
If we do not find an implicit 's' extension, we will wait for more digits
instead of hanging up immediately. (If you _really_ depended on that 'feature'
please add s => { Hangup(); } :)
Pickup: the pickup application can be used with PICKUPMARK to match
a channel, that is in RINGING state. Unfortunately, one has to explicitly
use ast_setstate() in addition to ast_queue_event() to convince asterisk
to change the channel state...
=> Pickup works now.
LCR assumes, that any call in the list, that has ref set to 0 is waiting for a ref to be assigned.
That can cause trouble, if we have one call waiting for a ref to be assigned and another call
hanging in the list, that was just released in the same moment.
Both have ref == 0 and in some circumstances, the new ref message picks the wrong one for
assignment...
This patch makes chan_lcr distinguish between calls waiting for a new ref and those, that
only have their ref removed due to release. (It is not enough, to check for state, since
new calls can change into release state immediately! That is also one of the race conditions,
when this can get you into trouble: asterisk receives call1 by LCR, makes a SETUP call2 immediately
through LCR and then receives a release for call1 by LCR before call2 got it's ref assigned!)
This patch also removes some dead code, that was #ifdef'd out.
End user notice: if you ever got into the situation, that _all_ calls from asterisk to LCR got released
immediately and only a restart of asterisk got you out of the situation, then you might need
this fix :)
Some SIP phones don't send RETRIEVE before they send TRANSFER.
So we RETRIEVE if we bridge two channels, if calls are still on hold.
Also: handle CONTROL_SRCUPDATE with a debug message in recent
versions of asterisk.
You may change the path of socket and lock files.
LCR admin socket's flags can now be altered to allow access to other users.
Lock and socket files will now be removed when terminating LCR.
modified: Makefile
modified: chan_lcr.c
modified: default/options.conf
modified: lcradmin.c
modified: lcrsocket.h
modified: main.c
modified: options.c
modified: options.h
modified: socket_server.c
- oldast is totally unimportant
- we didn't unlock correctly
=> works now :)
Test case: open two lcr channels using a sip phone. Do a transfer between
them.
in lcr_read
(lcr_read was hanging in locked-state forever, when no data was
available, making any further calls impossible.
Now we return a null-packet to asterisk)
Sidenode: you have to use lcr_config(r) to receive faxes correctly.
(app_rxfax seems to rely on 160-byte buffers)
-> if initial caller uses pure data mode (or video), the bchannels for this call are handled in HDLC mode. (hardware/software briding is still applicable.)
modified: apppbx.cpp
modified: chan_lcr.c
modified: dss1.cpp
modified: dss1.h
modified: lcradmin.c
modified: lcrsocket.h
modified: mISDN.cpp
modified: mISDN.h
modified: message.h
modified: socket_server.c
many fixes on briding issues
-> briding will work with dsp and directly via chan_lcr
-> hdlc will work with dsp and directly with chan_lcr
modified: bchannel.c
modified: chan_lcr.c
modified: chan_lcr.h
-> YES, you may now overlap dial through asterisk
fixed answering call when bridging, because asterisk will not call lcr_answer when bridging.
modified: chan_lcr.c