On Fri, 23 Dec 2005, Daniel Swarbrick wrote:
> Armin Schindler wrote:
> > > 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.
Yes, with this driver you need to set echocancelold=yes
> > ...
> > 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.
Yes and I think the two problems are related (see below).
> > 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)?
Actually I did not try to reproduce this problem yet, I want to try to fix
the problem which I can reproduce easily.
And I think I found the problem.
I will create a new posting...
Armin
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
