[Asterisk-Users] Sangoma E1 board Experience

Mon Dec 19 14:26:41 MST 2005

The 8 byte chunk size is used in zaptel because:

1. For lowest "cost" echo cancellation in software you need the lowest
possible delay between outbound and inbound data streams, which demands the
minimum possible buffering.

2. The 8 byte chunk per channel is the source of the millisecond timer that
seems to be crucial to proper operation of meetme and other applications.

The T1/E1 as well as the analog Sangoma cards have a common PCI interface
using individual DMA channels for each DS0, which can be set at any value.
See for instance the API specification at
http://sangoma.editme.com/wanpipe-linux-tdm-voice-api. On the A104d quad
T1/E1 and A201d analog cards where echo is taken care of on board, and
presumably also on Digium's TE411P, there is no echo cancellation
constraint. The chunk size could easily be expanded to 10 or 20ms for these
cards with hardware EC. One of the reasons why Yate is more efficient in
handling TDM is because voice is handled in larger packets.

Switching delays at 10 or 20 ms are not at all critical. If we could get
around the need for the millisecond timer in Asterisk, the way would be open
to making use of bigger chunks. Sangoma cards can produce an independent 1
ms timer IRQ, but that somewhat defeats the object.

David Yat Sin
Sangoma Technologies
(905) 474-1990 x119
(800) 388-2475 x119
Fax: (905) 474 9223
MSN: david.ys1 at hotmail.com
Email: davidy at sangoma.com
Wiki: sangoma.editme.com

>From: Steve Underwood <steveu at coppice.org>
>Reply-To: Asterisk Users Mailing List - Non-Commercial 
>Discussion<asterisk-users at lists.digium.com>
>To: Asterisk Users Mailing List - Non-Commercial 
>Discussion<asterisk-users at lists.digium.com>
>Subject: Re: [Asterisk-Users] Sangoma E1 board Experience
>Date: Mon, 19 Dec 2005 08:05:55 +0800
>
>janvb at caselaboratories.com wrote:
>
>>
>>>Its not a limitation. Its an architectural design which is based on 
>>>pulse code modulation (pcm) standards, which essentially says:
>>>- 8,000 audio samples per second,
>>>- each sample is an 8-bit value
>>>- resulting in 64,000 bits/second (like g711 codec standard)
>>>
>>>
>>Thank you for your answer, but I don't think you read/understood my 
>>question?
>>
>>The Zaptel driver uses a 8 byte buffer for buffering G.711 in each 
>>direction. This has nothing to do with the sample rate, but how large 
>>packets you can buffer the voice for to be transported through the PCI 
>>interface. I get the impression that the Digium boards are limited to
>>8 bytes (1 ms ) by reading the zaptel driver. But, I don't know this 
>>cause I have no hardware manual that cover the PCI interface. I was 
>>hoping that the Sangoma boards offered a more variable buffer size???
>>
>The current cards from Digium use bus mastering, so the amount of 
>buffering on the board should not be a big issue, unless the PCI 
>latency in really bad. The 1ms buffering is a driver issue, and was a 
>design choice which made a lot of sense originally. It might make less
sense now.
>
>- 1ms ensured the latency between E1/T1 ports bridged in the drievr was 
>low, and EC would not be an issue. The latest revision of the 4 port
>E1/T1 cards from Digium now have on board bridging, so this is less of 
>an
issue.
>It still matters when bridging between cards, though.
>
>- 1ms ensured good EC convergence, using software EC. Adding delay 
>really degrades the performance of an EC adaption loop. It may be a 
>block size of
>2 or 3 ms might have been a better compromise between adaption 
>performance, and the necessary response time of the software. However, 
>making the block size considerably bigger - say ta 20ms block, which is 
>what * generally works with in its core - would significantly degrade 
>EC adaption.  Now there are cards with hardware EC, for which 20ms 
>blocks seems to make a lot of sense. However, right now they still all 
>work in the same 1ms block manner.
>
>Regards,
>Steve
>
>_______________________________________________
>--Bandwidth and Colocation provided by Easynews.com --
>
>Asterisk-Users mailing list
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
David Yat Sin
Sangoma Technologies
(905) 474-1990 x119
(800) 388-2475 x119
Fax: (905) 474 9223
MSN: david.ys1 at hotmail.com
Email: davidy at sangoma.com
Website: www.sangoma.com

-----Original Message-----
From: BJ Weschke [mailto:bweschke at gmail.com] 
Sent: December 19, 2005 7:50 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [Asterisk-Users] Shutting down Asterisk when not in RTP Stream

On 12/18/05, Douglas Garstang <dgarstang at oneeighty.com> wrote:
> Hi Tyler.
>
> We're registering users with OpenSER, which also routes the calls to a
series of Asterisk systems. The really tricky part is allowing different
phones entering through different Asterisk systems to reach other.
Currently, the solution is to, upon registration from phones, issue a
forward() command in OpenSER to forward the registration to every Asterisk
system. In this way, every Asterisk box knows about every phone and it
doesn't matter which Asterisk system takes the call.
>
> It's not a perfect solution though. When OpenSER sends the forward()
request to Asterisk, it also sends back the 'Trying' and 'Ok' messages to
the phones (We're using Polycom's). The phones don't seem to have a problem
with these extraneous messages.... so far. A better solution would have been
to use t_replicate() in OpenSER, which absorbs these messages, but you can
only call t_replicate once.
>
> We may still end up sending all calls BACK through OpenSER again to
terminate the call, as it knows the location of all the phones as well. This
is easy from a simple dial plan perspective, but I'm not sure yet how some
of the more advanced Asterisk features such as hints and ACD Queues will
work when specifying @proxy for their location. I'd prefer to leave OpenSER
out of the equation though.  Just trying to get it to do failure_route() etc
to Asterisk is a huge pain considering the docs on it are soooo bad. Oh
yeah.... check out the use of failure_route with t_relay() when sending
calls to Asterisk in a redundant fashion. It seems to be working well so
far. Failover is very fast. I also saw a post on the OpenSER list last night
saying that the dispatcher (which we had looked at before) now supports
failure_route too. We liked it initially because it can load balance on
call-id and give you a roughly even call distribution.
>
> Don't try using realtime either.... it's hard to believe but you can't use
it for sharing a common contact database between Asterisk systems. Digium
have admitted to this.
>

 Asterisk is not a SIP proxy. That's why you see that it still knows
about the calls even though the media has been reinvited away.
Asterisk always knows about the state of its SIP calls given that it's
a B2BUA instead of a SIP proxy.

--
Bird's The Word Technologies, Inc.
http://www.btwtech.com/