On Sat, 4 Jun 2005, Ralf Schlatterbeck wrote: > > > I'm had difficulties with applications Busy and Congestion in Asterisk > > > with chan_capi -- which is not solved in chan_capi-0.4.0-PRE1. So I > > > looked at the source and made an implementation of capi_indicate that > > > can now signal congestion or busy to the remote end. > > > > > > I would be interested to merge the changes back into an 'official' > > > version. > > > > We can add this to the CVS, that's why I created it. > OK, for now I'll submit it as a patch against your version of chan_capi > from CVS. Do you have a tag in CVS I should check out, so you know later > against which version I'm working?
There are no special tags, just use HEAD. > > > I've also got difficulties with the Austrian implementation of > > > Euro-ISDN PTP: Obviously the current 0.4.0-PRE1 (and 0.3.5 before it) > > > assume that an incoming PTP call will be followed by an INFO_IND that > > > conveys the DID information -- In Austria, at least when called from a > > > fully-digital line (ISDN or mobile phone) the DID information is already > > > there and no INFO_IND follows, resulting in a timed-out call (because > > > the INFO_IND never comes). > > > In line 2144 of chan_capi.c (0.4.0-PRE1) the new channel is handed to > > > asterisk in AST_STATE_DOWN. When I change this to AST_STATE_RING it > > > works for me -- but I lose DID information from analogue phones (which > > > is still better than loosing all calls from digital phones and leaving > > > asterisk in an inconsistent state). > > > Are there solutions for this? I'd appreciate help in debugging (and > > > patching) this... > > > > Hmm, I think this is what kapejod told me already about. As far as I > > understood, he knows this problem and may have a fix. But if he has a > > probable fix, it would be nice to publish it. (Via CVS it's simple). > I'm now in contact with somebody quite knowledgeable about ISDN in > general and austrian/german differences in particular. > One of the things I discovered already is that chan_capi currently does > not honor the "Sending complete" subelement in the "Additional Info" of > a connect_ind or info_ind. This means it will wait for additional digits > even in the case where there will be no more (block dialling from a > mobile phone will send all the dialling -- including DID -- in the > connect). I think you have a copy of the capi-spec, in part-I on p.77 > and p.107 you can check out the sending complete info. In addition there > should be a timer for waiting for additional dialling information (if > sending complete is zero). The timer is set to 15sec in the standard but > most implementations use a shorter time. After the timer expires the > call should be handed to asterisk even if the dialling info is not > complete, otherwise the call will be timed out (thats what happens to me > with the original implementation) I don't know if CAPI already > implements this timer or if the application is responsible for doing > this. As far as I know the timer should be part of the application. I think the correct way is to handle each number/digit to Asterisk and Asterisk should state an own 'sending complete' according to dialplan, or time out. But the 'sending complete' status of connect_ind/info_ind must be evaluated of course. > > I did not have a closer look at this problem yet. Can you provide a log > > of capi messages for such calls (ISDN and analog)? > > What ISDN card do you use? If it's Eicon, then > > divactrl ditrace will help you here. > I don't think a log will improve the current understanding of the > problem much. I think I know how the implementation should look like and > I need it myself. So I check if I can code it up and send a patch. If It > doesn't work I can always send a log :-) I cannot reproduce every case, so a trace of the CAPI messages would show what is done in the real world. > > > Hmm, maybe this should have gone to the devel list after all :-) > > > > Which devel list? Asterisk? > > Hmm, maybe I should have a look at this list as well ;-) > I'm also subscribe only since yesterday... and I'm only playing for 2 > weeks or so with asterisk but already am fascinated what is possible... I know what you mean ;-) Armin _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
