[asterisk-r2] Bug with two half E1s on Open R2.
Marcelo Pacheco
marcelo at m2j.com.br
Wed Jan 11 13:18:28 CST 2012
From the sample system.conf on DAHDI:
# span=<span num>,<timing source>,<line build out
(LBO)>,<framing>,<coding>[,yellow]
...
# If you choose 0, the port will never be used as a source of timing.
This is
# appropriate when you know the far end should always be a slave to you. If
# the port is connected to a channel bank, for example, you should always be
# its master. Likewise, BRI TE ports should always be configured as a slave.
# Any number of ports can be marked as 0.
I'm setting up the first E1 as PRIMARY (timing source 1), and the other
3 E1s as slaves (timing source 0).
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 ?
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.
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.
Its always important to separate the bugs we get used working around
from the proper way of doing things...
Cheers,
Marcelo
On 01/11/12 14:30, Carlos Chavez wrote:
> On Tue, 2012-01-10 at 20:16 -0200, Marcelo Pacheco wrote:
>> 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 ?
>>
>>
> 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.
>
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-r2 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-r2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-r2/attachments/20120111/0e39bf8f/attachment.htm>
More information about the asterisk-r2
mailing list