Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
2012/6/26, Richard Mudgett rmudg...@digium.com: This is the option I will try. I'll report my findings here. My findings, after setting layer1_presence=ignore in chan_dahdi.conf are : == Starting D-Channel on span 1 == Starting D-Channel on span 2 == Primary D-Channel on span 1 up == Primary D-Channel on span 2 up foo*CLI pri show spans PRI span 1/0: Up, Active PRI span 2/0: In Alarm, Down, Active foo*CLI pri show spans PRI span 1/0: In Alarm, Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active So basically, pri show spans still reports lines being down, though they are not. The pri show spans command is not useful for PTMP lines if the *telco* brings layer 2 and layer 1 down while idle. These lines really are down. The *only* difference between an unplugged line and layer 1 being down is that they come back up on demand. Do you imply that instead of being afraid of the word Down presence, I should stand assured by the word Active presence, the later one meaning this line can be back up on demand ? What would the wording for such situation in 1.4.13, with these layer 1 and 2 features ? Still something like Down, Active ? And what about using something more specific like Energy save, Active ? What surprised me a lot is the speed with which each line is put in energy save mode : a line remainded up during 20s or so and then put down for a while. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
This is the option I will try. I'll report my findings here. My findings, after setting layer1_presence=ignore in chan_dahdi.conf are : == Starting D-Channel on span 1 == Starting D-Channel on span 2 == Primary D-Channel on span 1 up == Primary D-Channel on span 2 up foo*CLI pri show spans PRI span 1/0: Up, Active PRI span 2/0: In Alarm, Down, Active foo*CLI pri show spans PRI span 1/0: In Alarm, Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active So basically, pri show spans still reports lines being down, though they are not. The pri show spans command is not useful for PTMP lines if the *telco* brings layer 2 and layer 1 down while idle. These lines really are down. The *only* difference between an unplugged line and layer 1 being down is that they come back up on demand. Do you imply that instead of being afraid of the word Down presence, I should stand assured by the word Active presence, the later one meaning this line can be back up on demand ? For your PTMP setup, the only useful information pri show spans is going to give you is the fact that the span is configured. PRI span v/w: x, y, z v = span number w = span D channel index (Will be non-zero if there is more than one D channel per span. (NFAS redundant D channel setup)) x = Can be: In Alarm (Layer 1 down) or not present if layer 1 up y = Can be: Down (Layer 2 down), Up (Layer 2 up) z = Can be: Active (This D channel is the active NFAS D channel or only D channel), Standby (This D channel is in backup standby mode for NFAS) What would the wording for such situation in 1.4.13, with these layer 1 and 2 features ? Still something like Down, Active ? And what about using something more specific like Energy save, Active ? The layer1_presence option just causes Asterisk to ignore layer 1 alarms from DADHI on the span when considering the ability of the B channels to be usable for outgoing and incoming calls. The option only has an effect on PTMP lines because some telcos drop layer 1 for power saving reasons. When in power saving mode, you will not be able to tell if the line is out of service until you attempt to make a call. The layer2_persistence option causes libpri to bring layer 2 back up when the telco drops it. Because layer 2 is not allowed to remain down, the telco cannot bring layer 1 down. Some telcos may have an issue with this behavior because the line cannot go into power saving mode. What surprised me a lot is the speed with which each line is put in energy save mode : a line remainded up during 20s or so and then put down for a while. The line will come back up on demand in less than a second. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
2012/6/22, Olivier oza_4...@yahoo.fr: 2012/6/21, Richard Mudgett rmudg...@digium.com: My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? I would think layer 1 going down. I'm aware of this energy save mode. What surprises me a bit is the frequency with which this happens: a rough estimee is 60s or less before the line going down. Is there a practical way to double check that ? Using pri debug ? core set debug ? Many European telcos for BRI PTMP lines drop layer 2 and then layer 1 to conserve power. Is the switching of clock sources causing a problem? Fortunately, beside having the log files cluttered with Alarm messages, the system is working ok. 2. How can I get rid of these alarms ? See the chan_dahdi.conf.sample file about the following options. You could use the layer1_presence option to make Asterisk ignore those alarms. This is the option I will try. I'll report my findings here. My findings, after setting layer1_presence=ignore in chan_dahdi.conf are : == Starting D-Channel on span 1 == Starting D-Channel on span 2 == Primary D-Channel on span 1 up == Primary D-Channel on span 2 up foo*CLI pri show spans PRI span 1/0: Up, Active PRI span 2/0: In Alarm, Down, Active foo*CLI pri show spans PRI span 1/0: In Alarm, Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active So basically, pri show spans still reports lines being down, though they are not. So, my next option is to downgrade libpri to 1.4.10.2 and hope for a better reporting. You could use the layer2_persistence option to keep layer 2 up. To use this option however, requires using libpri SVN 1.4 branch code as current released versions do not support the option. I was aware of this improvement and I can't wait to see it published. Using the layer2_persistence option restores behavior that was removed for better Q.921 conformance for PTMP after libpri v1.4.10.2 and is why you are seeing a behavior difference between versions. So, in a way, a better confiormance to Q.921 introduced the requirement to explicitely ignore Layer1 status changes (in BRI/TE/PtmP) in chan_dahdi.conf. Though these layer1 and layer2 settings belongs to Asterisk's chan_dahdi.conf file, maybe an UPGRADE.txt file inside libpri directory would be useful to let sysadmins access to this information. What about adding an UPGRADE.txt in libpri ? 3. Shall I report this ? It is normal with BRI PTMP lines. It is also the reason for the layer1_presence and layer2_persistence options. 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core Both mISDN and DAHDI have drivers for your BRI card. Only one of them should be loaded. Since you are using DAHDI and not mISDN, you should load the DAHDI version. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users --
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
As basically Asterisk 1.8 requires libpri1.4.11 and up, I had to downgrade Asterisk to 1.6 and libpri to 1.4.10.2 to get pri show spans working back again. Having a 1.4.13 published with complete PtmP support will be much appreciated. Regards -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
This is the option I will try. I'll report my findings here. My findings, after setting layer1_presence=ignore in chan_dahdi.conf are : == Starting D-Channel on span 1 == Starting D-Channel on span 2 == Primary D-Channel on span 1 up == Primary D-Channel on span 2 up foo*CLI pri show spans PRI span 1/0: Up, Active PRI span 2/0: In Alarm, Down, Active foo*CLI pri show spans PRI span 1/0: In Alarm, Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active foo*CLI pri show spans PRI span 1/0: Down, Active PRI span 2/0: Down, Active So basically, pri show spans still reports lines being down, though they are not. The pri show spans command is not useful for PTMP lines if the *telco* brings layer 2 and layer 1 down while idle. These lines really are down. The *only* difference between an unplugged line and layer 1 being down is that they come back up on demand. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
On Fri, Jun 22, 2012 at 08:07:54PM +1200, Alec Davis wrote: Have a look at the latest blacklist sample in dahdi trunk http://svnview.digium.com/svn/dahdi/tools/trunk/blacklist.sample?view=log file: blacklist.sample ... # Some mISDN drivers may try to attach to cards supported by DAHDI. If you # have a card which is *not* supported by DAHDI but supported by one of the # below drivers you should feel free to remove it from the blacklist below. blacklist hfcmulti May collide with wcb4xxp blacklist netjet May collide with wctdm and some other older drivers. blacklist hfcpci May collide with zaphfc. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
2012/6/25, Tzafrir Cohen tzafrir.co...@xorcom.com: On Fri, Jun 22, 2012 at 08:07:54PM +1200, Alec Davis wrote: Have a look at the latest blacklist sample in dahdi trunk http://svnview.digium.com/svn/dahdi/tools/trunk/blacklist.sample?view=log file: blacklist.sample ... # Some mISDN drivers may try to attach to cards supported by DAHDI. If you # have a card which is *not* supported by DAHDI but supported by one of the # below drivers you should feel free to remove it from the blacklist below. blacklist hfcmulti May collide with wcb4xxp blacklist netjet May collide with wctdm and some other older drivers. blacklist hfcpci May collide with zaphfc. May I ask where I can get this zaphfc from ? Is this the same refered to as vzaphfc (see http://www.voip-info.org/wiki/view/Asterisk+vzaphfc) ? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
Have a look at the latest blacklist sample in dahdi trunk http://svnview.digium.com/svn/dahdi/tools/trunk/blacklist.sample?view=log file: blacklist.sample ... # Some mISDN drivers may try to attach to cards supported by DAHDI. If you # have a card which is *not* supported by DAHDI but supported by one of the # below drivers you should feel free to remove it from the blacklist below. blacklist hfcmulti blacklist netjet blacklist hfcpci I had a similar issue after upgrading from lenny to squeeze :( System wouldn't boot as udev tried to launch both wcb4xxp and hfcmulti, as I didn't have wcb4xxp blacklisted as well as the others. Only would boot after physically removing BRI card. Alec -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Olivier Sent: Thursday, 21 June 2012 9:37 p.m. To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? 2. How can I get rid of these alarms ? 3. Shall I report this ? 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
2012/6/21, Richard Mudgett rmudg...@digium.com: My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? I would think layer 1 going down. I'm aware of this energy save mode. What surprises me a bit is the frequency with which this happens: a rough estimee is 60s or less before the line going down. Is there a practical way to double check that ? Using pri debug ? core set debug ? Many European telcos for BRI PTMP lines drop layer 2 and then layer 1 to conserve power. Is the switching of clock sources causing a problem? Fortunately, beside having the log files cluttered with Alarm messages, the system is working ok. 2. How can I get rid of these alarms ? See the chan_dahdi.conf.sample file about the following options. You could use the layer1_presence option to make Asterisk ignore those alarms. This is the option I will try. I'll report my findings here. You could use the layer2_persistence option to keep layer 2 up. To use this option however, requires using libpri SVN 1.4 branch code as current released versions do not support the option. I was aware of this improvement and I can't wait to see it published. Using the layer2_persistence option restores behavior that was removed for better Q.921 conformance for PTMP after libpri v1.4.10.2 and is why you are seeing a behavior difference between versions. So, in a way, a better confiormance to Q.921 introduced the requirement to explicitely ignore Layer1 status changes (in BRI/TE/PtmP) in chan_dahdi.conf. Though these layer1 and layer2 settings belongs to Asterisk's chan_dahdi.conf file, maybe an UPGRADE.txt file inside libpri directory would be useful to let sysadmins access to this information. What about adding an UPGRADE.txt in libpri ? 3. Shall I report this ? It is normal with BRI PTMP lines. It is also the reason for the layer1_presence and layer2_persistence options. 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core Both mISDN and DAHDI have drivers for your BRI card. Only one of them should be loaded. Since you are using DAHDI and not mISDN, you should load the DAHDI version. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
2012/6/22, Alec Davis siva...@paradise.net.nz: Have a look at the latest blacklist sample in dahdi trunk http://svnview.digium.com/svn/dahdi/tools/trunk/blacklist.sample?view=log file: blacklist.sample ... # Some mISDN drivers may try to attach to cards supported by DAHDI. If you # have a card which is *not* supported by DAHDI but supported by one of the # below drivers you should feel free to remove it from the blacklist below. blacklist hfcmulti blacklist netjet blacklist hfcpci I didn't know about the later two : thanks for sharing this. May I add that Linux automatically allocates hfc4s8s_l1 driver to Junghanns OctoBRI cards which are supported by Dahdi, so I add to blacklist them in the past. This shows me I should learn : - how Linux 2.6.32 (and above) detects PCI boards and allocates them to mISDN (the one included, I think, in the kernel itself) - where to find up-to-date data listing telephony cards either supported by Dahdi or mISDN I had a similar issue after upgrading from lenny to squeeze :( System wouldn't boot as udev tried to launch both wcb4xxp and hfcmulti, as I didn't have wcb4xxp blacklisted as well as the others. Only would boot after physically removing BRI card. I was a bit luckier thanks to default dahdi.blacklist.conf file. Alec -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Olivier Sent: Thursday, 21 June 2012 9:37 p.m. To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? 2. How can I get rid of these alarms ? 3. Shall I report this ? 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
Am 21.06.2012 um 18:05 schrieb Richard Mudgett: My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? I would think layer 1 going down. Many European telcos for BRI PTMP lines drop layer 2 and then layer 1 to conserve power. Is the switching of clock sources causing a problem? 2. How can I get rid of these alarms ? See the chan_dahdi.conf.sample file about the following options. You could use the layer1_presence option to make Asterisk ignore those alarms. You could use the layer2_persistence option to keep layer 2 up. To use this option however, requires using libpri SVN 1.4 branch code as current released versions do not support the option. Using the layer2_persistence option restores behavior that was removed for better Q.921 conformance for PTMP after libpri v1.4.10.2 and is why you are seeing a behavior difference between versions. Hi Richard, any plans when libpri 1.4.13 will be released? Michael http://www.mksolutions.info smime.p7s Description: S/MIME cryptographic signature -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? 2. How can I get rid of these alarms ? 3. Shall I report this ? 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 10/1.6.1 and Dahdi/Libpri compatilities in BRI /PtmP
My previous message was incomplete. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core hfcmulti 1. What is the root cause that makes a board change its sync source ? How can I check this ? I would think layer 1 going down. Many European telcos for BRI PTMP lines drop layer 2 and then layer 1 to conserve power. Is the switching of clock sources causing a problem? 2. How can I get rid of these alarms ? See the chan_dahdi.conf.sample file about the following options. You could use the layer1_presence option to make Asterisk ignore those alarms. You could use the layer2_persistence option to keep layer 2 up. To use this option however, requires using libpri SVN 1.4 branch code as current released versions do not support the option. Using the layer2_persistence option restores behavior that was removed for better Q.921 conformance for PTMP after libpri v1.4.10.2 and is why you are seeing a behavior difference between versions. 3. Shall I report this ? It is normal with BRI PTMP lines. It is also the reason for the layer1_presence and layer2_persistence options. 4. Waht would you suggest ? Regards 2012/6/21, Olivier oza_4...@yahoo.fr: Hi, After an upgrade, I discovered yesterday strange things I would like to share here. Basically, I'me comparing platforms: The first one is a 2.6.26 (Debian Lenny) platform, with Asterisk 1.6.1.18, Libpri 1.4.10.2, Dahdi revision 8853 (must be between 2.3 and 2.5, I think). The second one is a 2.6.32 (Debian Squeeze) platform, with Asterisk 10.5.1, Libpri 1.4.12, Dahdi 2.6.1. Both are connected to telco BRI lines in TE/PtmP mode through a Junghanns QuadBRI board (wcb4xxp driver). Both handle incoming and outgoing calls correctly, as far as I can tell. But on the second one, though working fine, Dahdi keeps showing alarm messages such as: [71765.784120] wcb4xxp :01:0e.0: new card sync source: port 1 [71767.484151] wcb4xxp :01:0e.0: new card sync source: port 1 [71771.184119] wcb4xxp :01:0e.0: new card sync source: port 2 [71794.184164] wcb4xxp :01:0e.0: new card sync source: port 1 and pri show spans mostly (but not always) report worrying status: PRI span 1/0: Down, Active PRI span 2/0: In Alarm, Down, Active On the first box pri show spans constantly reports the line is up. On thing to note is I had to forbid hfcmulti in modprobe.d in the second box to comply with a warning from dahdi. Without that, I could see this line in the output of lsmod: mISDN-core Both mISDN and DAHDI have drivers for your BRI card. Only one of them should be loaded. Since you are using DAHDI and not mISDN, you should load the DAHDI version. Richard -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
