[Asterisk-Dev] unsubscribe

Wed May 25 23:03:52 MST 2005

----- Original Message ----- 
From: <asterisk-dev-request at lists.digium.com>
To: <asterisk-dev at lists.digium.com>
Sent: Saturday, November 27, 2004 7:00 PM
Subject: Asterisk-Dev Digest, Vol 4, Issue 67


> Send Asterisk-Dev mailing list submissions to
> asterisk-dev at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> or, via email, send a message with subject or body 'help' to
> asterisk-dev-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-dev-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Asterisk-Dev digest..."
>
>
> Today's Topics:
>
>    1. why not disable clock when using multiple Zaptel cards?
>       (Andrew Kohlsmith)
>    2. Re: why not disable clock when using multiple Zaptel cards?
>       (Steven Critchfield)
>    3. Re: why not disable clock when using multiple Zaptel cards?
>       (Peter Svensson)
>    4. Re: why not disable clock when using multiple Zaptel cards?
>       (Peter Svensson)
>    5. Re: why not disable clock when using multiple Zaptel cards?
>       (Andrew Kohlsmith)
>    6. bugs #2700 and #2721 (chan_agent transfers) (Kevin Blackham)
>    7. need some suggestions (Xenith Panacea)
>    8. Re: need some suggestions (Brian Roy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 26 Nov 2004 13:39:22 -0500
> From: Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com>
> Subject: [Asterisk-Dev] why not disable clock when using multiple
> Zaptel cards?
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <200411261339.22862.akohlsmith-asterisk at benshaw.com>
> Content-Type: text/plain;  charset="us-ascii"
>
> New thread started to prevent thread hijacking:
>
> On November 26, 2004 12:16 pm, Peter Svensson wrote:
> > There is a field "timing" in /etc/zaptel.conf that ranks incoming spans
in
> > the order they are to be considered as a clock source. If all active
spans
> > (presumably on a single card) have their timing set to 0 the card and
thus
> > all the spans will be clocked from an internal source.
> >
> > Now, given what has been written on the bug tracker and here I suspect
> > there is a bug in ztcfg. It should set up the clocking independently on
> > the two cards. Perhaps it doesn't?
>
> I have thought about this several times in the past and I'm finally to the
> point where I can't understand why not.
>
> If I have a pair of T100Ps, or a TDM400P and a X101P, or any combination
of
> Zaptel cards in a system why on earth does the zaptel driver not disable
the
> timer interrupt for all but one card and use that single timer for
clocking
> everything in the system?
>
> IIRC there are problems discussed where having two Zaptel cards in a
system
> can cause issues when bridging between them since the timing is off, and
> using one timer for all Zaptel cards certainly seems like it would be more
> efficient and eliminate this problem.   Am I missing something obvious?
>
> -A.
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 26 Nov 2004 12:54:08 -0600
> From: Steven Critchfield <critch at basesys.com>
> Subject: Re: [Asterisk-Dev] why not disable clock when using multiple
> Zaptel cards?
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <1101495248.22815.39.camel at critch>
> Content-Type: text/plain
>
> On Fri, 2004-11-26 at 13:39 -0500, Andrew Kohlsmith wrote:
> > New thread started to prevent thread hijacking:
> >
> > On November 26, 2004 12:16 pm, Peter Svensson wrote:
> > > There is a field "timing" in /etc/zaptel.conf that ranks incoming
spans in
> > > the order they are to be considered as a clock source. If all active
spans
> > > (presumably on a single card) have their timing set to 0 the card and
thus
> > > all the spans will be clocked from an internal source.
> > >
> > > Now, given what has been written on the bug tracker and here I suspect
> > > there is a bug in ztcfg. It should set up the clocking independently
on
> > > the two cards. Perhaps it doesn't?
> >
> > I have thought about this several times in the past and I'm finally to
the
> > point where I can't understand why not.
> >
> > If I have a pair of T100Ps, or a TDM400P and a X101P, or any combination
of
> > Zaptel cards in a system why on earth does the zaptel driver not disable
the
> > timer interrupt for all but one card and use that single timer for
clocking
> > everything in the system?
> >
> > IIRC there are problems discussed where having two Zaptel cards in a
system
> > can cause issues when bridging between them since the timing is off, and
> > using one timer for all Zaptel cards certainly seems like it would be
more
> > efficient and eliminate this problem.   Am I missing something obvious?
>
> Maybe because you may be confusing some terminology. For any T1 or E1
> interface there is timing on the wire and it is not directly tied to the
> IRQs. Timing on the T1/E1 spans are needed to keep them in sync with the
> remote end of the line. The interupt is fired after 8 bits of each
> channel are prepared. The data needs to be picked up before the next 8
> bits are ready. So the timing on the T1/E1 spans needs to be relatively
> perfect. The timing of the interupts has some wiggle room.
>
> As for eliminating the IRQs on any Zap card after the first and letting
> the driver handle each and every zap card there after on the same
> interupt, sounds interesting, but not all zap cards use the same driver.
> T100ps use wct1xxp driver, TDM400P uses wtdm somthing. If they used all
> the same drivers it might be possible, otherwise I think there is a
> kernel issue with servicing the interupt when your device didn't
> generate the interupt.
> -- 
> Steven Critchfield <critch at basesys.com>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 26 Nov 2004 19:58:45 +0100 (CET)
> From: Peter Svensson <psvasterisk at psv.nu>
> Subject: Re: [Asterisk-Dev] why not disable clock when using multiple
> Zaptel cards?
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <Pine.LNX.4.44.0411261948070.1475-100000 at cheetah.psv.nu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Fri, 26 Nov 2004, Andrew Kohlsmith wrote:
>
> > If I have a pair of T100Ps, or a TDM400P and a X101P, or any combination
of
> > Zaptel cards in a system why on earth does the zaptel driver not disable
the
> > timer interrupt for all but one card and use that single timer for
clocking
> > everything in the system?
>
> There are two periodic timers that we need to not mix up when talking. One
> is the line clock of the T1/E1 interface. It ticks at a multiple of 8*8
kHz
> (the sampling rate of the phone system) times the number of channels in
> the line (25 or 32 if I remember correctly). This timing is handled by the
> hardware on the interface card. If the card is a multiport TE410P then all
> the spans are clocked from the same source. The source is normally a PSTN
> span.
>
> The other timing is the 1kHz interrupt generated once 8 bytes are received
> from each channel. This allos the zaptel driver to do something with the
> data once received.
>
> For the first timing (the line timing) this must be distributed between
> the spans that are to share a common timing source. At the moment this
> seems only to be possible within a card. It may be possible to write a
> software PLL to lock the internally generated timing on one card to the
> pstn derived timing of another.
>
> I think the second timing currently causes 1kHz worth of interrupts per
> card in the system. Perhaps it would be possible to collect the data from
> all the cards from within the same interrupt handler. I don't know. Thay
> may lessen the load somewhat.
>
> > IIRC there are problems discussed where having two Zaptel cards in a
system
> > can cause issues when bridging between them since the timing is off, and
> > using one timer for all Zaptel cards certainly seems like it would be
more
> > efficient and eliminate this problem.   Am I missing something obvious?
>
> You missed the point that the high frequency timing needs to get from one
> card to the next. Since no cable interconnects them a pll of some sort is
> probably needed, if this is at all possible.
>
> Or, you can loop a cable from one span on one card to a span on another
> card. That loses you on port on each card of course, just to get the
> timing between the cards.
>
> Peter
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 26 Nov 2004 20:01:32 +0100 (CET)
> From: Peter Svensson <psvasterisk at psv.nu>
> Subject: Re: [Asterisk-Dev] why not disable clock when using multiple
> Zaptel cards?
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <Pine.LNX.4.44.0411261959060.1475-100000 at cheetah.psv.nu>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> On Fri, 26 Nov 2004, Steven Critchfield wrote:
>
> > Maybe because you may be confusing some terminology. For any T1 or E1
> > interface there is timing on the wire and it is not directly tied to the
> > IRQs. Timing on the T1/E1 spans are needed to keep them in sync with the
> > remote end of the line. The interupt is fired after 8 bits of each
> > channel are prepared. The data needs to be picked up before the next 8
> > bits are ready. So the timing on the T1/E1 spans needs to be relatively
> > perfect. The timing of the interupts has some wiggle room.
>
> I thought it was after 64 bits (8 samples) = 1 kHz?
> Otherwise I agree.
>
> > As for eliminating the IRQs on any Zap card after the first and letting
> > the driver handle each and every zap card there after on the same
> > interupt, sounds interesting, but not all zap cards use the same driver.
> > T100ps use wct1xxp driver, TDM400P uses wtdm somthing. If they used all
> > the same drivers it might be possible, otherwise I think there is a
> > kernel issue with servicing the interupt when your device didn't
> > generate the interupt.
>
> Those other cards would have to have their interrupts turned off. Does
> anyone have any numbers or even gut feeling if the interrupt overhead is
> significant?
>
> Peter
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 26 Nov 2004 14:18:55 -0500
> From: Andrew Kohlsmith <akohlsmith-asterisk at benshaw.com>
> Subject: Re: [Asterisk-Dev] why not disable clock when using multiple
> Zaptel cards?
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <200411261418.55902.akohlsmith-asterisk at benshaw.com>
> Content-Type: text/plain;  charset="iso-8859-1"
>
> On November 26, 2004 01:54 pm, Steven Critchfield wrote:
> > Maybe because you may be confusing some terminology. For any T1 or E1
> > interface there is timing on the wire and it is not directly tied to the
> > IRQs. Timing on the T1/E1 spans are needed to keep them in sync with the
> > remote end of the line. The interupt is fired after 8 bits of each
> > channel are prepared. The data needs to be picked up before the next 8
> > bits are ready. So the timing on the T1/E1 spans needs to be relatively
> > perfect. The timing of the interupts has some wiggle room.
>
> No I understand the terminology - I wasn't confusing span timing with TDM
IRQ
> timing.
>
> > As for eliminating the IRQs on any Zap card after the first and letting
> > the driver handle each and every zap card there after on the same
> > interupt, sounds interesting, but not all zap cards use the same driver.
> > T100ps use wct1xxp driver, TDM400P uses wtdm somthing. If they used all
> > the same drivers it might be possible, otherwise I think there is a
> > kernel issue with servicing the interupt when your device didn't
> > generate the interupt.
>
> All cards use the zaptel module do they not?  It's just the
"bottom-handler"
> modules (wctdm, wct1xxp, wct4xxp) which are different... they all
reference
> and use code in the zaptel module, unless I'm mistaken.
>
> As far as kernel issues I think you might have it backward -- the driver
init
> code would say "ooh, there's already a zaptel timing source initialized, I
am
> turning OFF the timer (and perhaps masking the IRQ) for this card and
simply
> linking the service routine for the new card to the existing zaptel timing
> handler.
>
> You aren't servicing an interrupt for a device that isn't generating it,
> you're servicing a card that didn't generate an interrupt (as far as the
> kernel is concerned, you'd be polling it).
>
> Perhaps it's all moot but it seems hideous that you would have multiple
> "high-frequency" IRQs without good reason.
>
> -A.
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 26 Nov 2004 17:40:51 -0700
> From: Kevin Blackham <blackham at gmail.com>
> Subject: [Asterisk-Dev] bugs #2700 and #2721 (chan_agent transfers)
> To: asterisk-dev at lists.digium.com
> Message-ID: <d575bde604112616401bde4465 at mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> The problem with the agent channel not being freed, or callers being
> disconnected on native SIP transfers (where # works fine, see mantis
> bug IDs in subject) are plaguing me and at least two other call center
> implementors.  Myself and one other (twilson) have come up with dial
> plan hacks to avoid chan_agent, but duct tape sucks.  Our workarounds
> are nearly identical, and can pretty much get the functionality
> reproduced, with the exception of wrapuptime.
>
> This has pretty much been the only problem keeping me from rolling *
> company-wide.  What is the status of this bug slash design issue being
> addressed?  My preference, and what seems like the best idea, is to
> move some the agent tracking code into app_queue, and get rid of
> chan_agent altogether, which I can dedicate some time to.
> Alternately, to have chan_agent handle SIP transfers in the same way #
> transfers are.  I don't understand channels enough to know what that
> involves.  Having looked at chan_agent.c and receiving an immediate
> headache and nausea, I have no idea where to start on that part.
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 27 Nov 2004 09:46:21 +0500
> From: Xenith Panacea <xenythpanacea at gmail.com>
> Subject: [Asterisk-Dev] need some suggestions
> To: asterisk-dev at lists.digium.com
> Message-ID: <2939da200411262046613401ea at mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> Hi,
> I'm a Software Engineering final term student & along with my 3 ogher
> group members, we're planning to work on asterisk for our degree
> project. We have some experience in working with asterisk.
> For now, we're thinking of picking up a requirement from the */digium
> wish list and develop it. We are working to make up our minds and set
> up 1 goal, currently we're considering the IP V6 implementation of *.
> I need some advice/suggestions for as to what should we work on.
> Something that is practical and beneficial not only for our degree
> work, but more importanlty which contributes to the * development.
> Thanks.
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 26 Nov 2004 23:01:19 -0600
> From: Brian Roy <mister.roy at gmail.com>
> Subject: Re: [Asterisk-Dev] need some suggestions
> To: Xenith Panacea <xenythpanacea at gmail.com>, Asterisk Developers
> Mailing List <asterisk-dev at lists.digium.com>
> Message-ID: <1316644904112621011be976df at mail.gmail.com>
> Content-Type: text/plain; charset=US-ASCII
>
> On Sat, 27 Nov 2004 09:46:21 +0500, Xenith Panacea
> <xenythpanacea at gmail.com> wrote:
> > Hi,
> > I'm a Software Engineering final term student & along with my 3 ogher
> > group members, we're planning to work on asterisk for our degree
> > project.
>
> Since you are a college student and all, why not pick up a bounty? Get
> paid, help the community, and advance your school project.
>
> http://www.voip-info.org/wiki-Asterisk+bounty
>
> -Chuji
>
>
> ------------------------------
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> End of Asterisk-Dev Digest, Vol 4, Issue 67
> *******************************************
>