asterisk users - Sep 2008 - PRI auto-configure - continued from DEV list

On Tue, Sep 9, 2008 at 7:17 AM, Bill Michaelson <bill at cosi.com> wrote:
> > I'm faced with an installation at a client site with supposed PRI
service on
> > a fractional T1.  
Steve Totaro 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.

1.  No configuration changes are needed if the client decides to
"light up" some more B channels
2.  All B channels that are lit up will come up but not the B chans
that are not in service, so configuring the entire span in Asterisk
will not effect anything negatively.  Channels that do not come up are
not used by Asterisk.

I have had issues with this only once, the entire span came up, not
just what was provisioned, so calls going out on those channels did
not work.  The carrier put a Cisco box at the demarc that was
configured for a full PRI going to the Asterisk box.

-------------------------
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...

Of course, due to my inability to assure everything else in the configuration is
correct, I could do all that smacking for nothing. I want to eliminate variables
or otherwise devise a logical step-by-step procedure for getting this running.

In my case, I've got an Adtran TSU120e doing a split between the old Nortel
PBX (which I'm trying to replace) and a Cisco router for the IP side of the
service.  From fiddling around with the Adtran panel, I've been able to
determine that there are 12 channels being sent to the DSX-1, but it tells me no
more than that.  If I could safely assume that D is on 24, and configuring the
other 23 per your suggestion will be OK, maybe there is hope.



-------------- 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/20080909/214e11b1/attachment.bin

On Tue, Sep 09, 2008 at 11:13:45AM -0400, Bill Michaelson
wrote:
> On Tue, Sep 9, 2008 at 7:17 AM, Bill Michaelson <bill at cosi.com>
wrote:
> 
> >> I'm faced with an installation at a client site with supposed
PRI
> >service on
> >> a fractional T1.  
> Steve Totaro wrote:
(Please quote properly next time)
> 
> > 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.
> 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.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir

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