Armin Schindler wrote: > Okay, lets have a look at the first case: > > ... > -- ISDN2: Error setting up echo canceller (PLCI=0x102) > Dec 22 11:53:50 WARNING[3056647088]: chan_capi.c:3270 show_capi_conf_error: > ISDN2: conf_error 0x300b PLCI=0x102 > Command=FACILITY_CON > F,0x8497 > > CAPI INFO 0x300b: Facility not supported > ... > > when a connection is established the echo-cancel will be activated. But in > this case the driver rejects this. Maybe the card does not support it, or > the wrong facility-selector is used (for older eicon driver you must set > echocancelold=yes).
It is a somewhat older, ex-demo Eicon card, however the driver is current (from the divactrl package, version 2.1 from http://isdn4linux.org/~armin/divas/). In capi.conf, echocanel=yes and echocancelold is commented out. I'll try uncommenting echocancelold to see if that warning goes away. > ... > Dec 22 11:53:51 ERROR[3052743600]: chan_capi.c:1173 capi_write: dont know > how to write subclass 64 > ... > > Now this is the problem why the call is disconnected. It is exactly the > problem I described: openpbx tries to send subclass 64 voice (slin) to > capi which supports alaw only ! Right. This is the call-pickup debug, where the call is lost as soon as the other SIP phone tries to pick up the call (while the original SIP phone is ringing). This is actually the less concerning problem of the two. We can sort of work around this, but I suspect it may also be the easier of the two problems to fix. > > Now the second case: > ... > > CAPI INFO 0x300b: Facility not supported > -- Started music on hold, class 'default', on CAPI/ISDN2/5251713-11 > -- Stopped music on hold on CAPI/ISDN2/5251713-11 > == Spawn extension (all-users, 578, 0) exited non-zero on > 'CAPI/ISDN2/5251713-11' > -- Executing Macro("CAPI/ISDN2/5251713-11", "pbx-extn-vmail|578|578") in > new stack > -- Executing Set("CAPI/ISDN2/5251713-11", "CFIM=") in new stack > -- Executing GotoIf("CAPI/ISDN2/5251713-11", "1?3:20") in new stack > -- Goto (macro-pbx-extn-vmail,s,3) > -- Executing Dial("CAPI/ISDN2/5251713-11", "SIP/578|20|Tt") in new stack > -- Called 578 > -- SIP/578-132d is ringing > == ISDN2: Requested RINGING-Indication for CAPI/ISDN2/5251713-11 > -- ISDN2: attempting ALERT in state 2 > -- SIP/578-132d answered CAPI/ISDN2/5251713-11 > == ISDN2: Requested Indication-STOP for CAPI/ISDN2/5251713-11 > == Spawn extension (macro-pbx-extn-vmail, s, 3) exited non-zero on > 'CAPI/ISDN2/5251713-11' in macro 'pbx-extn-vmail' > == Spawn extension (all-users, 578, 1) exited non-zero on > 'CAPI/ISDN2/5251713-11' > == ISDN2: CAPI Hangingup > -- ISDN2: activehangingup (cause=16) > ... > > I cannot find any error in this log. It looks like a perfect connection > (except the echo-cancel warning again). The call is connected and then just > hung up with cause 'normal call clearing'. This is the call transfer scenario. Yes, it does terminate like a normal call. However, after the call is transferred, the PSTN caller hears very garbled sound, but the second SIP phone that the call has been transferred to does not notice anything unusual. The garbled sound is like the wrong format is being used for that channel (maybe slin instead of alaw again). And it only affects one direction of the call. That problem is the show-stopper, since transferring a call is a fairly frequent requirement. Have you been able to reproduce this particular problem (ie, is it something unique to my setup or equipment)? _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
