<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
From the sample system.conf on DAHDI:<br>
<br>
# span=<span num>,<timing source>,<line build out
(LBO)>,<framing>,<coding>[,yellow]<br>
...<br>
# If you choose 0, the port will never be used as a source of
timing. This is<br>
# appropriate when you know the far end should always be a slave to
you. If<br>
# the port is connected to a channel bank, for example, you should
always be<br>
# its master. Likewise, BRI TE ports should always be configured as
a slave.<br>
# Any number of ports can be marked as 0.<br>
<br>
I'm setting up the first E1 as PRIMARY (timing source 1), and the
other 3 E1s as slaves (timing source 0).<br>
<br>
You explanation that I must setup all 30 channels on each SPAN even
if they're not used for CAS at all is based on what ?<br>
I think this is a OWT (Old Wife's Tail). Each channel should be
defined for its actual use. If there's a bug you're working around,
then lets report that and get it fixed.<br>
Carrier Embratel in Brazil has about 20000 customers with a 15
channel voice + voice signalling + 15 channel data Internet bundle.
Usually Embratel supplies the MUX to split the signals, but then
you're saying that I'm unable to do the MUX function in Linux if the
voice is MFC-R2 ? I've done this with ISDN just fine.<br>
<br>
Its always important to separate the bugs we get used working around
from the proper way of doing things...<br>
<br>
Cheers,<br>
<br>
Marcelo<br>
<br>
<br>
On 01/11/12 14:30, Carlos Chavez wrote:
<blockquote
cite="mid:1326299405.2285.3.camel@cursor.telecomabmex.com"
type="cite">
<pre wrap="">On Tue, 2012-01-10 at 20:16 -0200, Marcelo Pacheco wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have the following chan_dahdi.conf
[channels]
usecallerid=yes
echocancel=no
echocancelwhenbridged=no
signalling=mfcr2
mfcr2_variant=br
mfcr2_forced_release=no
mfcr2_get_ani_first=no
mfcr2_category=national_subscriber
mfcr2_allow_collect_calls=yes
mfcr2_double_answer=no
context=entrada
group=1
mfcr2_max_ani=14
mfcr2_max_dnis=4
channel => 1-15
;group=0
;context=drop
;channel => 17-21
context=geral
group=2
mfcr2_max_ani=4
mfcr2_max_dnis=16
channel => 32-46
And the following /etc/dahdi/system.conf
span=1,1,0,cas,hdb3
span=2,0,0,cas,hdb3
span=3,0,0,cas,hdb3
span=4,0,0,cas,hdb3
cas=1-15:1101
cas=17-21:1101
cas=32-46:1101
dchan=16,47
echocanceller=kb1,32-46
#echocanceller=mg2,1-15,17-31,32-46,48-52
loadzone = us
defaultzone=us
If I leave the 17-21 channel range out of chan_dahdi.conf (or commented
as shown), then the attributes from channels 1-15 bleed through to 32-36
(max_ani, max_dnis).
*CLI> mfcr2 show channels
Chan Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS Rx CAS
1 BR 14 4 No No IDLE IDLE
2 BR 14 4 No No IDLE IDLE
3 BR 14 4 No No IDLE IDLE
4 BR 14 4 No No IDLE IDLE
5 BR 14 4 No No IDLE IDLE
6 BR 14 4 No No IDLE IDLE
7 BR 14 4 No No IDLE IDLE
8 BR 14 4 No No IDLE IDLE
9 BR 14 4 No No IDLE IDLE
10 BR 14 4 No No IDLE IDLE
11 BR 14 4 No No IDLE IDLE
12 BR 14 4 No No IDLE IDLE
13 BR 14 4 No No IDLE IDLE
14 BR 14 4 No No IDLE IDLE
15 BR 14 4 No No IDLE IDLE
32 BR 14 4 No No IDLE IDLE
33 BR 14 4 No No IDLE IDLE
34 BR 14 4 No No IDLE IDLE
35 BR 14 4 No No IDLE IDLE
36 BR 14 4 No No IDLE IDLE
37 BR 4 16 No No IDLE IDLE
38 BR 4 16 No No IDLE IDLE
39 BR 4 16 No No IDLE IDLE
40 BR 4 16 No No IDLE IDLE
41 BR 4 16 No No IDLE IDLE
42 BR 4 16 No No IDLE IDLE
43 BR 4 16 No No IDLE IDLE
44 BR 4 16 No No IDLE IDLE
45 BR 4 16 No No IDLE IDLE
46 BR 4 16 No No IDLE IDLE
Notice channels 32-36 endup with the configuration from the first
channel group instead of the proper (4/16) config. However the context
setting is properly set.
Uncommenting 17-21 on chan_dahdi works around the issue. I'm using
asterisk 1.6.2.18. I'm unable to use asterisk 1.8 due to some sip
features changed in undesirable ways. The customer has a 15 voice
channels + 15 internet channels, with an external MUX splitting the last
15 channels into a separate link, however that leads so lots of
block/unblock of channels in the 17-31 range polluting the Asterisk log
when the workaround is applied.
It this a known issue, or should I open a new bug on this ? Is this a
openR2 issue or a chan_dahdi issue ?
</pre>
</blockquote>
<pre wrap="">
You should always define all channels in system.conf even if they will
not be used by asterisk. Also you have spans 2 to 4 as clock source
over span 1.
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
asterisk-r2 mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-r2">http://lists.digium.com/mailman/listinfo/asterisk-r2</a></pre>
</blockquote>
<br>
</body>
</html>