Re: [asterisk-users] Iridium integration / gateway

[Bertrand Lupart]

Hello,


> Thanks for reply, but this is irrelevant, I'm looking for an *Iridium*
> gateway.

I guess calling to/from Iridium via GSM network is not an option and you’re 
looking for on boarding asterisk on a boat or somewhere GSM is not available.

http://www.groundcontrol.com/Iridium_Making_Calls.htm


I guess you could connect to your Iridium handset via USB :

https://www.iridium.com/support/help-desk/


Greetings,

— 
Bertrand-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Iridium integration / gateway

[Jean-Denis Girard]

Thanks for reply, but this is irrelevant, I'm looking for an *Iridium*
gateway.


Regards,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527

Le 03/04/2018 à 16:05, albert zhang a écrit :
> http://www.dinstar.cn/en/index.php/GSM/
> 
> 2018-04-04 10:01 GMT+08:00 Jean-Denis Girard  >:
> 
> Hi list,
> 
> I have a request to integrate Iridium in a Asterisk system. A quick
> search didn't return much: I expected to find products similar to GSM
> gateways, but this does not seem to exist. so I'd be very interested
> about possible solutions. Has it be done already, how?
> 
> 
> Thanks,
> --
> Jean-Denis Girard
> 
> SysNux                   Systèmes   Linux   en   Polynésie  française
> https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527
> 
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/ 
> 
> New to Asterisk? Start here:
>       https://wiki.asterisk.org/wiki/display/AST/Getting+Started
> 
> 
> 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 --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Iridium integration / gateway

[albert zhang]

http://www.dinstar.cn/en/index.php/GSM/

2018-04-04 10:01 GMT+08:00 Jean-Denis Girard :

> Hi list,
>
> I have a request to integrate Iridium in a Asterisk system. A quick
> search didn't return much: I expected to find products similar to GSM
> gateways, but this does not seem to exist. so I'd be very interested
> about possible solutions. Has it be done already, how?
>
>
> Thanks,
> --
> Jean-Denis Girard
>
> SysNux   Systèmes   Linux   en   Polynésie  française
> https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.
> org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> 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 --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Iridium integration / gateway

[Jean-Denis Girard]

Hi list,

I have a request to integrate Iridium in a Asterisk system. A quick
search didn't return much: I expected to find products similar to GSM
gateways, but this does not seem to exist. so I'd be very interested
about possible solutions. Has it be done already, how?


Thanks,
-- 
Jean-Denis Girard

SysNux   Systèmes   Linux   en   Polynésie  française
https://www.sysnux.pf/   Tél: +689 40.50.10.40 / GSM: +689 87.797.527

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Strange problem with PRI on 64-bit?

[Antony Stone]

On Wednesday 04 April 2018 at 00:30:00, Richard Mudgett wrote:

> On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson  wrote:
> > On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield 
> > > Both the 32-bit and 64-bit were fresh installs of the latest CentOS 6.9
> > > from online repositories using a kickstart build.
> 
> The libpri makefile doesn't install things for 64 bit systems in the right
> place [1] without your help.  You'll need to specify where to install the
> library on the command line for your system:
> 
> sudo make install libdir=/usr/lib64
> 
> [1] https://issues.asterisk.org/jira/browse/PRI-100

Isn't this handled by the CentOS package manager?


Antony.

-- 
I know I always wanted to be somebody, but I guess I should have been more 
specific.

   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Audio Dropouts During Call

[Antony Stone]

On Wednesday 04 April 2018 at 00:20:29, Dave Platt wrote:

> Also, check the wiring.  Check each individual RJ-45 jumper, *and* the
> in-house wiring, with a proper tester that can verify that the
> individual pairs are hooked up correctly.

Can you provide a link to such a tester?

> The problem is this:  in a telco RJ-45 cable (such as was/is often used
> for proprietary telephone systems) the individual wires are either not
> in twisted pairs, or are twisted-pairs in a 1-2 3-4 5-6 7-8 arrangement.
> These work fine for analog connections.  They're latent-death-on-wheels
> for Ethernet.

> A good Ethernet cable-pair tester can spot such things pretty quickly.

I disagree.

*Certainly*, incorrect pair terminations can cause the sort of problems 
described, however I haven't yet come across a cable tester which can identify 
that a cable correctly connected from end to end with wires {1..8} <-> {1..8} 
is in fact not correctly connected in ethernet 1-2 3-6 4-5 7-8 pairs.

All cable testers I have so far encountered will check that all wires are 
correctly connected end to end and not cross connected etc., but have no clue 
whether the wire joining pin 3 at one end to pin 3 at the other end is twisted 
together with the cable from pin 4 or pin 6.

I would be very interested to find such a tester, if you can point us at one.


Thanks,


Antony.

-- 
"Can you keep a secret?"
"Well, I shouldn't really tell you this, but... no."


   Please reply to the list;
 please *don't* CC me.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Strange problem with PRI on 64-bit?

[Richard Mudgett]

On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson  wrote:

> On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield 
> wrote:
> > In article 

Re: [asterisk-users] Audio Dropouts During Call

[Dave Platt]

> I looked at your network diagram. Try checking the configuration of the
> Ethernet ports on the firewall and the Asterisk box. Make sure they are
> set to auto-negotiate and not set to a fixed speed and fixed duplex.
> I have found in the past that if one end of a link is expecting auto-
> negotiation (as the switches probably are) and the other end is expecting
> a fixed configuration, things can degrade to half-duplex trying to talk
> to full-duplex, resulting in lots of collisions and packet loss when there
> is any kind of significant traffic.
> 
> Your description would be consistent with the firewall introducing lots of
> LAN collisions when busy, in the central gigabit switch, even if the VoIP
> traffic isn't passing through the firewall.

Also, check the wiring.  Check each individual RJ-45 jumper, *and* the
in-house wiring, with a proper tester that can verify that the
individual pairs are hooked up correctly.

I've seen all kinds of hell occur, in situations where somebody used
telco-type RJ-45 connecting cables, in place of proper Ethernet
connecting cables.

The problem is this:  in a telco RJ-45 cable (such as was/is often used
for proprietary telephone systems) the individual wires are either not
in twisted pairs, or are twisted-pairs in a 1-2 3-4 5-6 7-8 arrangement.
These work fine for analog connections.  They're latent-death-on-wheels
for Ethernet.

Ethernet only works well if you connect the pairs as a 1-2, 3-6, 4-5,
7-8 arrangement, because this is how the signals are sent electrically.
Using the correct connections ensures that the signals on each pair are
"balanced" electrically - that is, the two wires in each twisted pair
are carrying equal-but-opposite currents for the two sides of an
individual signal.  This minimizes electrical coupling between pairs,
and thus minimizes crosstalk.

If you use a telco-style cable (these are often black, and flat), or if
you use what looks like an Ethernet cable but which had its wires
"punched down" to the connector in the wrong pairing, things go very
badly indeed.  One twisted pair might be carrying one TX signal and one
RX signal.  This pretty much *guarantees* terrible cross-talk between
the two.

The symptoms of this can be as was related... the connection appears to
work OK under light load, when there's usually traffic flowing in only
one direction at a time.  However, when you put a bidirectional load on
the connection, the signals going from A to B and from B to A cross-talk
with one another, leading to a very high rate of corrupted/dropped
packets on the network.

This will often show up in the end device's Ethernet packet statistics,
if you can get to them... look for a high rate of dropped or "bad"
packets, FCS (frame sequence check) errors, etc.

I've seen a fair number of cheap "Ethernet" cables that had been
manufactured wrong.  You should see a color pairing such as

http://www.hardwaresecrets.com/how-gigabit-ethernet-works/

indicates - pins 4 and 5 are a pair (blue, and white-and-blue), and the
next-outer pins are also a pair (orange, and white-with-orange).

If you see a pattern such as "white-with-green, green, white-with-blue,
blue, white-with-orange, orange, white-with-brown, brown" where there
are four color-matched pairs of wires next to one another, you've got a
bad cable.

The same error can occur when building wiring is "punched down" to the
RJ-45 jacks.

A good Ethernet cable-pair tester can spot such things pretty quickly.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Strange problem with PRI on 64-bit?

[Matt Fredrickson]

On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield  wrote:
> In article 
> 

Re: [asterisk-users] Audio Dropouts During Call

[Tony Mountifield]

In article <0ed7d81c-4507-0355-3dd7-cebd7b9a8...@texascountrytitle.com>,
Brent Davidson  wrote:
> 
> Well, I now have another office complaining of the audio drop-outs. Logs 
> are showing the same issues.  RTP just stops for awhile then resumes.
> 
> At the original problem office, I replaced all the network cables, 
> replaced two network hubs, and made sure the phones are all connected 
> correctly.  The problem still exists.
> 
> One thing I did notice during testing is that the audio is perfectly 
> fine as long as there is no internet traffic, but once there is internet 
> traffic, the audio quality drops drastically, then cuts out completely.  
> Once the internet traffic stops, there is about a 2 second lag, then the 
> audio resumes.
> 
> I find that incredibly odd as we don't use VOIP outside lines, and none 
> of the voice traffic should be passing through our firewall, router, or 
> DSL modem.
> 
> Internal network traffic, such as moving a file between shared folders 
> on 2 computers on the internal office network does not impact the audio 
> at all.  However, if I try to send a file across the VPN, refresh a web 
> page in the browser, or run a bandwidth test from either computer, the 
> audio goes glitchy then drops out until the traffic returns to normal.
> 
> Attached is a network diagram to show how both offices are set up. There 
> shouldn't be any reason for traffic that goes straight to the internet 
> to affect the internal VOIP traffic.  The Asterisk server only runs 
> Asterisk, Hylafax, and a Samba share for the workgroup copier/scanner to 
> save scanned files to.  It isn't doing DNS, or anything that would tax 
> it's resources.  The servers both have quad-core CPUs and 16 GB of ram.
> 
> I've tried switching codes between ulaw, alaw, and g.729 and the problem 
> persists at both offices.
> 
> 
> Any ideas?

I looked at your network diagram. Try checking the configuration of the
Ethernet ports on the firewall and the Asterisk box. Make sure they are
set to auto-negotiate and not set to a fixed speed and fixed duplex.
I have found in the past that if one end of a link is expecting auto-
negotiation (as the switches probably are) and the other end is expecting
a fixed configuration, things can degrade to half-duplex trying to talk
to full-duplex, resulting in lots of collisions and packet loss when there
is any kind of significant traffic.

Your description would be consistent with the firewall introducing lots of
LAN collisions when busy, in the central gigabit switch, even if the VoIP
traffic isn't passing through the firewall.

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Strange problem with PRI on 64-bit?

[Tony Mountifield]

In article 

Re: [asterisk-users] Strange problem with PRI on 64-bit?

[Matt Fredrickson]

On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield  wrote:
> I have some more investigation to do on this, but I wanted to see if anyone
> here had any insight into the issue I've run into.
>
> The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one
> of several systems that have been running without issue since 2010/2011. They
> have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen
> 5 card), libpri 1.2.8 and asterisk 1.2.32.
>
> Having taken this particular system out of production, I updated it to CentOS
> 6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version
> of Asterisk is required at the moment due to custom modifications).
> This appears to work fine.
>
> In order to reduce the number of different versions we support, I reinstalled
> the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using
> the same versions as above.
>
> However, for reasons I don't understand, the 64-bit version was logging
> frequent PRI errors every few minutes:
>
> [Apr  1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
> [Apr  1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR 
> (A): Got supervisory frame with F=1 in state 7(Multi-frame established)
>
> This left the PRIs in strange states - trying to make a call failed with 
> cause 101.
>
> So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs
> were no longer present, and the system operated normally again.
>
> So my question is: does anyone have any clues why there would be a difference
> in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into
> anything similar?


That does seem quite odd.  If I remember right, those messages would
come up if it looked like the other end hadn't received a message when
it thought it should have.  I can't think of anything that would
particularly impact 64 bit systems versus 32 bit systems in that
domain (ISDN real time message timing, etc).  Are you sure there's
nothing else different (kernel version or something else like that)?
Maybe also run a patlooptest on the spans in question to make sure
that they're running cleanly.

Matthew Fredrickson

>
> Cheers
> Tony
> --
> Tony Mountifield
> Work: t...@softins.co.uk - http://www.softins.co.uk
> Play: t...@mountifield.org - http://tony.mountifield.org
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users



-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Audio Dropouts During Call

[Brent Davidson]

Well, I now have another office complaining of the audio drop-outs. Logs 
are showing the same issues.  RTP just stops for awhile then resumes.


At the original problem office, I replaced all the network cables, 
replaced two network hubs, and made sure the phones are all connected 
correctly.  The problem still exists.


One thing I did notice during testing is that the audio is perfectly 
fine as long as there is no internet traffic, but once there is internet 
traffic, the audio quality drops drastically, then cuts out completely.  
Once the internet traffic stops, there is about a 2 second lag, then the 
audio resumes.


I find that incredibly odd as we don't use VOIP outside lines, and none 
of the voice traffic should be passing through our firewall, router, or 
DSL modem.


Internal network traffic, such as moving a file between shared folders 
on 2 computers on the internal office network does not impact the audio 
at all.  However, if I try to send a file across the VPN, refresh a web 
page in the browser, or run a bandwidth test from either computer, the 
audio goes glitchy then drops out until the traffic returns to normal.


Attached is a network diagram to show how both offices are set up. There 
shouldn't be any reason for traffic that goes straight to the internet 
to affect the internal VOIP traffic.  The Asterisk server only runs 
Asterisk, Hylafax, and a Samba share for the workgroup copier/scanner to 
save scanned files to.  It isn't doing DNS, or anything that would tax 
it's resources.  The servers both have quad-core CPUs and 16 GB of ram.


I've tried switching codes between ulaw, alaw, and g.729 and the problem 
persists at both offices.



Any ideas?

On 3/26/2018 10:30 AM, Bertrand LUPART - Linkeo.com wrote:

Hello,


Only one of the servers has the drop-out issues.  This location has a 
network switch on the main desk due to wiring limitations, but several

of the other non-problematic offices do as well.


I run some offices with similar asterisk configurations, only one 
experiencing drop-out calls as well.


Just visited the impacted office today, discovering their phones are 
daisy-chained. Still investigating, but i'm pretty confident correctly 
wiring them on a decent switch will correct the issue.


Also double-check the phone are correctly wired (LAN on LAN port and 
not on computer port)


OTOH

--
Bertrand LUPART




---
This email has been checked for viruses by AVG.
http://www.avg.com

WARNING-FRAUDULENT FUNDING INSTRUCTIONS



Email hacking and fraud are on the rise to fraudulently misdirect funds. Please call your escrow officer immediately using contract information found from an independent source, such as the sales contract or internet, to verify any funding instructions received. We are not responsible for any wires sent by you to an incorrect bank account. 

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Strange problem with PRI on 64-bit?

[Tony Mountifield]

I have some more investigation to do on this, but I wanted to see if anyone
here had any insight into the issue I've run into.

The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one
of several systems that have been running without issue since 2010/2011. They
have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen
5 card), libpri 1.2.8 and asterisk 1.2.32.

Having taken this particular system out of production, I updated it to CentOS
6.9 32-bit, with DAHDI 2.11.1, LibPRI 1.6.0 and Asterisk 11.25.3 (this version
of Asterisk is required at the moment due to custom modifications).
This appears to work fine.

In order to reduce the number of different versions we support, I reinstalled
the OS using the 64-bit version of CentOS 6.9 instead, and rebuilt, using
the same versions as above.

However, for reasons I don't understand, the 64-bit version was logging
frequent PRI errors every few minutes:

[Apr  1 03:40:52] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:40:58] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:44:06] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:46:38] VERBOSE[8990] chan_dahdi.c: PRI Span: 3 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:47:20] VERBOSE[8988] chan_dahdi.c: PRI Span: 1 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)
[Apr  1 03:47:24] VERBOSE[8989] chan_dahdi.c: PRI Span: 2 TEI=0 MDL-ERROR (A): 
Got supervisory frame with F=1 in state 7(Multi-frame established)

This left the PRIs in strange states - trying to make a call failed with cause 
101.

So I re-installed the 32-bit OS again, and rebuilt, and the above MDL-ERRORs
were no longer present, and the system operated normally again.

So my question is: does anyone have any clues why there would be a difference
in PRI behaviour between 32-bit and 64-bit builds? Has anyone else run into
anything similar?

Cheers
Tony
-- 
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users