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 notchange 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?
I guess you are referring to variables in the broadest sense, as I was, so to wit...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.
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: 3Note 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
