On Mon, January 9, 2006 4:15, Daniele Orlandi said:
> On Sunday 8 January 2006 01:37, you wrote:
>> Got it all working now! Thanks again for all the support!
>>
>> I'll be writing up what I did and post it on the wiki later...
>
> Thank you :)
>
>> I have also made some changes in chan_visdn.c to implement a timer and
>> max
>> digits test in to the VISDNOverlapDial() function, aside from the
>> extension matching in there already.
>
> I gave a look at your patch, unfortunately it does not solve the problem
> that
> kept me from implementing a timeout-based dialing.
>
> The problem is that when the overlap dialing fall in an extension which
> does
> support overlap dialing I have to start the PBX immediately and pass
> further
> digits as DTMF frames. When the extension does not support overlap dialing
> I
> have to wait until the user sends "Sending complete" or a timeout occurs.
>
> However, I do not know if the extension does support overlap dialing
> before
> the channel is bridged but then it is too late.
>
> The same applies for the selection of a suitable bearer capability.
>
> I've not found a nice solution yet, any hint is appreciated.
>
> Bye,
>
I partially understand, but for me this will work, so I'll keep the patch
for myself and apply whenever updating to a newer patch level! ;-)
(Partially because I do not 'quite' grasp what you mean by "The problem is
that when the overlap dialing fall in an extension which does support
overlap dialing I have to start the PBX immediately and pass further
digits as DTMF frames")
Another thing I am looking at right now is that the chan_visdn doesn't
recognise the DTMF after the call is established, which means I cannot use
functions like ATXFER, XFER, AUTOMON, etc., because these rely on
key-presses (resp. *2, # and *1 by default), or even terminate the echo
feedback test (*43) by pressing #...
No-one ever said this was going to be easy... I'd love the challenge if I
had some more time on my hands, but right now vISDN seems to be the better
choice for EuroISDN protocol compatability (ZapHFC keeps getting confused
on the protocol state, insisting to keep the D-channel up, instead of only
activating it when necessary), whereas ZapHFC seem to be better
integrated, and handles other stuff, such as DTMF, more reliable.
As long as ZapHFC keeps choking on the channels, and vISDN doesn't do
(inband?) DTMF from the ISDN phones connected to it, neither one is a
reliable option for me right now. My money is on vISDN however, as it
seems to be maturing much faster! ;-)
BRgds
--
F Peeters
PIII 450 - 1 GB - * 1.2 - BRIstuff 0.3.0 Pre 1 - Florz patch
2 Sweex HFC-PCI modes=2 sync_slave=2 timer_card=0
Cologne HFC-S pins #52, #54, #55 connected in parallel for synching.
AMD Duron 1GHz - 1GB - * 1.2.1
2 Sweex HFC-PCI cards
_______________________________________________
Visdn-hackers mailing list
[email protected]
https://mailman.uli.it/mailman/listinfo/visdn-hackers
