[asterisk-users] PRI auto-configure - continued from DEV list

[Bill Michaelson]

Tzafrir Cohen wrote:
>
>>> I usually configure the entire span of 24 channels (23 B + 1 D) and
>>> only the turned up channels go into service.  This is good for a
>>> couple of reasons.
>>>       
>
> Also note that Zaptel will anyway reserve all the 24 (for T1) or 31 (for 
> E1) Zaptel channels for the span. So the Zaptel channel numbers will not
> change whether the span is fractional or full.
>   
What do you mean by "reserve"?  Seriously, I'm trying to get a good grasp.

I have always assumed that the signal presented by the Adtran TSU120e 
appears as a full 24 channels.  But it was not clear to me how those 
channels are transformed on the TDM side of the fork, if at all, by the 
Adtran.  I supposed they might be remapped within the frames.  But 
thinking (out loud) about it some more, I realize that remapping any of 
the channel positions would likely invalidate some references embedded 
within the Q.931 data stream on the D channel, vastly complicating the 
process by requiring the Adtran to be aware of the content structure at 
a protocol layer that would otherwise be unnecessary.  So I suppose that 
it almost certainly does not remap these channels.  In fact, the nature 
of this animal is such that I suppose for a PRI, each entire frame could 
be passed to the TDM side unmodified and it would work just fine, with 
the PBX ignore the IP channels.

And following this same line of reasoning, the zaptel code would have 
little need to be told through its configuration which B channels are 
available because such information is implicitly available via Q.931 - 
and thus the channels specifications in zaptel.conf serve only to 
restrict usage.  Have I got this right?
>   
>> Steve,
>>
>> Thanks, I like this idea, and I appreciate the tip.  I will try it.  
>> Meanwhile, I'm finding from others' comments that it is extremely common to 
>> find the D channel on 24, which is primarily what concerned me - and my 
>> inability to divine this precisely in my case led to my suggestion/inquiry 
>> on the dev list.  I've seen enough docs that indicate that the D channel 
>> could be anywhere in the group, also implying that it's not unlikely to be 
>> at 13 or 6, IIRC.  I have visions of sitting in a lonely room repeatedly 
>> editing zaptel/zapata.conf and smacking it again, and again...
>>     
>
> Please give a list of variables. At least the ones you can think of.
>
>   
I guess you are referring to variables in the broadest sense, as I was, 
so to wit...

Having never attached asterisk to a T1, I have no working reference 
system, and I don't have a personal finite checklist of completion 
items.  So not knowing what I don't know is the biggest variable!  But I 
have placed configuration info in redfone.com, zaptel.conf and 
zapata.conf (see below).

I have built the ethmf module and it loads, and I can observe a stream 
of data on the designated ethernet interface with tcpdump.  It is a 
bidirectional stream of fixed length blocks that look something like 
what I might expect, but I have been unable to decipher any content upon 
superficial inspection.  I am supposing it is functioning correctly, but 
it's validity is still a variable to me, albeit only a small source of 
doubt.  Basic info such as alarm state is definitely getting 
transmitted, as zttool and the asterisk app are able to detect state 
changes...

When I move the DSX-1 cable from the Nortel box (which works for actual 
phone calls, so this is not a variable) and I plug it into the redfone 
TDMoE box, the LED goes from yellow to green, implying that it sees the 
data (I guess).  Similarly, zttool tells me there are no alarms and that 
I have the number of channels configured as specified in my 
configuration.  It has thus far only indicated that 0 are active, which 
based on googling, I suppose means 0 live calls established.

Now it seems that the only configuration that causes asterisk to start 
without complaint has been with the D channel on 24.  I'll omit detail 
on this for the moment.

Now I am at a point where I can use the pri command to get status.  With 
the cable out, I see this:

left*CLI> pri show spans
PRI span 1/0: Provisioned, In Alarm, Down, Active

and with the cable connected, I see this:

left*CLI> pri show span 1
Primary D-channel: 24
Status: Provisioned, Down, Active
Switchtype: National ISDN
Type: CPE
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: 0
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T309 Timer: -1
T313 Timer: 4000
N200 Counter: 3

Note that this cable is ordinarily attached to a Nortel PBX which is 
fully functioning with the T1 service.

Perusing the net, I've decided that the "Down" status is what I must 
understand and correct.  So the variable is the meaning of Down.  Other 
clues seem to indicate that my box is sending stuff down the line, but 
hearing nothing in return.  But I haven't seen any messages that 
elaborate.  For example, the pri command provides certain trace options 
which yields stuff like this:

[Sep 11 19:31:10] VERBOSE[2865] logger.c: Sending Set Asynchronous 
Balanced Mode Extended
[Sep 11 19:31:10] VERBOSE[2865] logger.c:
 > [ 00 01 7f ]
[Sep 11 19:31:10] VERBOSE[2865] logger.c:
 > Unnumbered frame:
[Sep 11 19:31:10] VERBOSE[2865] logger.c: > SAPI: 00  C/R: 0 EA: 0
 >  TEI: 000        EA: 1
[Sep 11 19:31:10] VERBOSE[2865] logger.c: >   M3: 3   P/F: 1 M2: 3 11: 
3  [ SABME (set asynchronous balanced mode extended) ]

...(REPEATS INDEFINITELY)...


So additional variables are:

-is 24 really a D-channel?
-is it really a PRI as I've been told?

And thus the question:
-is there a way to obtain the answers to these questions from asterisk 
trace data?

And following, maybe...

If it is not a PRI, how do I change the redfone/zaptel/... configs to 
try CAS?

----------------------------------------------

/etc/redfone.conf...

[globals]
fb=192.168.1.254
server=00:04:23:a9:3e:24
[span1]
framing=esf
encoding=b8zs
slave


/etc/zaptel.conf...

dynamic=ethmf,eth2/00:50:C2:65:D4:0A/0,24,1
dchan=24
bchan=1-23
loadzone=us
defaultzone=us

/etc/asterisk/zapata.conf...

[channels]
immediate=no
callgroup=1
switchtype=national
signalling=pri_cpe
context=from-trunk
resetinterval=never

group=1
channel => 1-23

Thanks for your attention.





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3234 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080912/fe6575fc/attachment.bin