Re: [asterisk-users] PRI auto-configure - continued from DEV list
On Fri, Sep 12, 2008 at 09:53:48AM -0400, Bill Michaelson wrote: > 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? The configuration in zaptel.conf is applied to channels before layer 2 is up. So I guess your question could be rephrased as: do we really need to specify 'bchan' in zaptel.conf? Any way to avoid that? I do need to configure the D channel explicitly. But any way to discover the D channels? -- Tzafrir Cohen icq#16849755 jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ -- 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
Re: [asterisk-users] PRI auto-configure - continued from DEV list
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: 1 T305 Timer: 3 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 s
Re: [asterisk-users] PRI auto-configure - continued from DEV list
On Tue, Sep 09, 2008 at 11:13:45AM -0400, Bill Michaelson wrote: > On Tue, Sep 9, 2008 at 7:17 AM, Bill Michaelson <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ -- 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
[asterisk-users] PRI auto-configure - continued from DEV list
On Tue, Sep 9, 2008 at 7:17 AM, Bill Michaelson <[EMAIL PROTECTED]> 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. 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
