Re: [asterisk-users] AstriEurope coference

[Sevana Oy]

Are there other European Asterisk conferences?

Thanks,
Sevana Oy
Vendor of Asterisk VQM

- Original Message - 
From: "randulo" 
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 


Sent: Tuesday, February 22, 2011 9:56 AM
Subject: Re: [asterisk-users] AstriEurope coference



On Mon, Feb 21, 2011 at 11:56 PM, Albert  wrote:

does anyone know is AstriEurope coference is still on ?


http://www.astrieurop.com/fr/cloture.php

Cancelled.

"Hello,
It is with regret that we announce you the cancellation of the
AstriEurop exhibition on May, 3rd and 4th 2011 in Paris.
We thank all the companies/partners having supported this project."

/r

--
_
-- 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] AstriEurope coference

[randulo]

On Mon, Feb 21, 2011 at 11:56 PM, Albert  wrote:
> does anyone know is AstriEurope coference is still on ?

http://www.astrieurop.com/fr/cloture.php

Cancelled.

"Hello,
It is with regret that we announce you the cancellation of the
AstriEurop exhibition on May, 3rd and 4th 2011 in Paris.
We thank all the companies/partners having supported this project."

/r

--
_
-- 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] NVFaxDetect causing segfault

[Tilghman Lesher]

On Monday 21 February 2011 21:11:28 Shamus Rask wrote:
>3. Is it true that Digium is sidelineing IAX2 and only focusing on
> SIP? Should I be looking to migrate to SIP trunks instead?

Is it true that space aliens stole your brain and replaced it with a head
of cabbage?

-- 
Tilghman

--
_
-- 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] Problem installing FXS module in old digium 4 channel tdm card

[Shaun Ruffell]

On 2/21/11 4:46 PM, C F wrote:

I just installed an FXS module onto a 4 channel tdm thats about 5
years old and it wont work. Running dmesg I can see the following
error:

Zapata Telephony Interface Registered on major 196
Freshmaker version: 71
Freshmaker passed register test
!!! LOOP_CLOSE_TRES  iREG 1C = 1  should be 1000
!!! RING_TRIP_TRES  iREG 1D = 8000  should be 3600
!!! COMMON_MIN_TRES  iREG 1E = 0  should be 1000
!!! COMMON_MAX_TRES  iREG 1F = 0  should be 200
!!! PWR_ALARM_Q1Q2  iREG 20 = 1480  should be 7C0
!!! PWR_ALARM_Q3Q4  iREG 21 = 37C0  should be 2600
!!! PWR_ALARM_Q5Q6  iREG 22 = 3D70  should be 1B80
!!! LOOP_CLOSURE_FILTER  iREG 23 = 3970  should be 8000
!!! RING_TRIP_FILTER  iREG 24 = 78E0  should be 320
!!! TERM_LP_POLE_Q1Q2  iREG 25 = 8B60  should be 8C
!!! TERM_LP_POLE_Q3Q4  iREG 26 = 6A40  should be 100
!!! TERM_LP_POLE_Q5Q6  iREG 27 = 8070  should be 10
!!! CM_BIAS_RINGING  iREG 28 =   should be C00
!!! DCDC_MIN_V  iREG 29 =   should be C00
!!! DCDC_XTRA  iREG 2A =   should be 1000
!!! LOOP_CLOSE_TRES_LOW  iREG 2B =   should be 1000
  ! Init Indirect Registers UNSUCCESSFULLY.
Indirect Registers failed verification.
!!! LOOP_CLOSE_TRES  iREG 1C = 1  should be 1000
!!! RING_TRIP_TRES  iREG 1D = 8000  should be 3600
!!! COMMON_MIN_TRES  iREG 1E = 0  should be 1000
!!! COMMON_MAX_TRES  iREG 1F = 0  should be 200
!!! PWR_ALARM_Q1Q2  iREG 20 = 1480  should be 7C0
!!! PWR_ALARM_Q3Q4  iREG 21 = 37C0  should be 2600
!!! PWR_ALARM_Q5Q6  iREG 22 = 3D70  should be 1B80
!!! LOOP_CLOSURE_FILTER  iREG 23 = 3970  should be 8000
!!! RING_TRIP_FILTER  iREG 24 = 78E0  should be 320
!!! TERM_LP_POLE_Q1Q2  iREG 25 = 8B60  should be 8C
!!! TERM_LP_POLE_Q3Q4  iREG 26 = 6A40  should be 100
!!! TERM_LP_POLE_Q5Q6  iREG 27 = 8070  should be 10
!!! CM_BIAS_RINGING  iREG 28 =   should be C00
!!! DCDC_MIN_V  iREG 29 =   should be C00
!!! DCDC_XTRA  iREG 2A =   should be 1000
!!! LOOP_CLOSE_TRES_LOW  iREG 2B =   should be 1000
  ! Init Indirect Registers UNSUCCESSFULLY.
Indirect Registers failed verification.
Module 0: FAILED FXS (FCC)
Module 1: Installed -- AUTO FXO (FCC mode)
Module 2: Installed -- AUTO FXO (FCC mode)
Module 3: Installed -- AUTO FXO (FCC mode)
Found a Wildcard TDM: Wildcard TDM400P REV E/F (3 modules)

Does this have to do with the fact that the module is way newer than the card?



Not having much direct experience with the wctdm.c driver, that would be 
my guess. You might be able to edit the wctdm_proslic_insane() function 
to force the FLAG_3215 on for the card and see if that gives you a 
different result.


--
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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] [Dahdi 2.4.0] DAHDI_CHANCONFIG failed on channel 1

[Shaun Ruffell]

On 2/21/11 4:52 PM, Gilles wrote:

Hello

On a brand new CentOS 5.5 host, I wanted to install Dahdi before
installing Asterisk 1.4.x.

So I untarred dahdi-linux-complete-2.4.0+2.4.0.tar.gz, followed by
make, make install, make config.



[snip]


Here's what "tail /var/log/messages" shows:

# tail /var/log/messages
...
Feb 21 22:44:54 centos kernel: fd != ff
Feb 21 22:44:54 centos kernel: fe != ff
Feb 21 22:44:54 centos kernel: Freshmaker failed register test
Feb 21 22:44:54 centos kernel: wctdm: probe of :04:0a.0 failed
with error -5


Has someone seen this? Is my Dahdi configuration wrong, or is it some
issue between Dahdi and CentOS?

Thank your for any help.


I don't have much direct experience with the cards supported by the 
wctdm driver, but based on what you show here, it appears more like 
either a fundamental PCI bus incompatibility, the card isn't seated 
properly in the slot, or failed hardware.


--
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org

--
_
-- 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] NVFaxDetect causing segfault

[Shamus Rask]

AstLinux v0.7.6
Asterisk v1.4.39.1

I have found that in some recent version of Asterisk v1.4, NVFaxDetect has
started to cause segfaults on my system. I am using the following code in
extensions.conf:

> [incoming]
> exten => 7057974880,1,Answer
> exten => 7057974880,n,NVFaxDetect(4|t)
> exten => 7057974880,n,Dial(${7941_C}&${9133_K},20,okt)
> exten => 7057974880,n,VoiceMail(u701@default)
>
> exten => fax,1,Dial(IAX2/iaxmodem)
> exten => fax,1,Hangup
>

[incoming] is my IAX2 trunk from my VoIP provider. Faxes used to work in the
manner, but on some recent upgrade they started to produce the following
errors in /var/log/messages:

> Feb 21 21:24:51 pbx user.info kernel: asterisk[2457]: segfault at 8 ip
> 400a5625 sp 9d5fb46c error 4 in libuClibc-0.9.28.so[4006e000+44000]
>

My questions are the following:

   1. Has anyone else seen similar problems with NVFaxDetect?
   2. Can anyone offer any insight/explanation?
   3. Is it true that Digium is sidelineing IAX2 and only focusing on SIP?
   Should I be looking to migrate to SIP trunks instead?


cheers,
   S.
--
_
-- 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] AstriEurope coference

[Albert]

Hi everyone,

does anyone know is AstriEurope coference is still on ?

I saw some notification about cancelation on website, but cant find it
anymore.

Regards,
Albert
--
_
-- 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] [Dahdi 2.4.0] DAHDI_CHANCONFIG failed on channel 1

[Gilles]

Hello

On a brand new CentOS 5.5 host, I wanted to install Dahdi before
installing Asterisk 1.4.x.

So I untarred dahdi-linux-complete-2.4.0+2.4.0.tar.gz, followed by
make, make install, make config.

Next, I created the following files from scratch:

 /etc/modprobe.d/dahdi.conf:
options wctdm opermode=FRANCE
 /etc/dahdi/modules
wctdm
 /etc/dahdi/system.conf
loadzone = fr
defaultzone = fr
fxsks = 1
echocanceller=mg2,1 
 /etc/asterisk/chan_dahdi.conf
[trunkgroups]

[channels]
signalling = fxs_ks
usecallerid = yes
hidecallerid = no
callwaiting = yes
usecallingpres = yes
callwaitingcallerid = yes
threewaycalling = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
echocancel = yes
echocancelwhenbridged = yes
relaxdtmf = yes
rxgain = 0.0
txgain = 0.0
immediate = no
context = from-pstn
channel => 1
 extensions.conf
[from-pstn]
exten => s,1,NoOp(Incoming call)
 

Finally, I ran /etc/init.d/dahdi start, and get the following error:
 
Running dahdi_cfg:  DAHDI_CHANCONFIG failed on channel 1: No such
device or address (6) [FAILED]
 

Here's what "tail /var/log/messages" shows:
 
# tail /var/log/messages
...
Feb 21 22:44:54 centos kernel: fd != ff
Feb 21 22:44:54 centos kernel: fe != ff
Feb 21 22:44:54 centos kernel: Freshmaker failed register test
Feb 21 22:44:54 centos kernel: wctdm: probe of :04:0a.0 failed
with error -5
 

Has someone seen this? Is my Dahdi configuration wrong, or is it some
issue between Dahdi and CentOS?

Thank your for any help.


--
_
-- 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] Problem installing FXS module in old digium 4 channel tdm card

[C F]

I just installed an FXS module onto a 4 channel tdm thats about 5
years old and it wont work. Running dmesg I can see the following
error:

Zapata Telephony Interface Registered on major 196
Freshmaker version: 71
Freshmaker passed register test
!!! LOOP_CLOSE_TRES  iREG 1C = 1  should be 1000
!!! RING_TRIP_TRES  iREG 1D = 8000  should be 3600
!!! COMMON_MIN_TRES  iREG 1E = 0  should be 1000
!!! COMMON_MAX_TRES  iREG 1F = 0  should be 200
!!! PWR_ALARM_Q1Q2  iREG 20 = 1480  should be 7C0
!!! PWR_ALARM_Q3Q4  iREG 21 = 37C0  should be 2600
!!! PWR_ALARM_Q5Q6  iREG 22 = 3D70  should be 1B80
!!! LOOP_CLOSURE_FILTER  iREG 23 = 3970  should be 8000
!!! RING_TRIP_FILTER  iREG 24 = 78E0  should be 320
!!! TERM_LP_POLE_Q1Q2  iREG 25 = 8B60  should be 8C
!!! TERM_LP_POLE_Q3Q4  iREG 26 = 6A40  should be 100
!!! TERM_LP_POLE_Q5Q6  iREG 27 = 8070  should be 10
!!! CM_BIAS_RINGING  iREG 28 =   should be C00
!!! DCDC_MIN_V  iREG 29 =   should be C00
!!! DCDC_XTRA  iREG 2A =   should be 1000
!!! LOOP_CLOSE_TRES_LOW  iREG 2B =   should be 1000
 ! Init Indirect Registers UNSUCCESSFULLY.
Indirect Registers failed verification.
!!! LOOP_CLOSE_TRES  iREG 1C = 1  should be 1000
!!! RING_TRIP_TRES  iREG 1D = 8000  should be 3600
!!! COMMON_MIN_TRES  iREG 1E = 0  should be 1000
!!! COMMON_MAX_TRES  iREG 1F = 0  should be 200
!!! PWR_ALARM_Q1Q2  iREG 20 = 1480  should be 7C0
!!! PWR_ALARM_Q3Q4  iREG 21 = 37C0  should be 2600
!!! PWR_ALARM_Q5Q6  iREG 22 = 3D70  should be 1B80
!!! LOOP_CLOSURE_FILTER  iREG 23 = 3970  should be 8000
!!! RING_TRIP_FILTER  iREG 24 = 78E0  should be 320
!!! TERM_LP_POLE_Q1Q2  iREG 25 = 8B60  should be 8C
!!! TERM_LP_POLE_Q3Q4  iREG 26 = 6A40  should be 100
!!! TERM_LP_POLE_Q5Q6  iREG 27 = 8070  should be 10
!!! CM_BIAS_RINGING  iREG 28 =   should be C00
!!! DCDC_MIN_V  iREG 29 =   should be C00
!!! DCDC_XTRA  iREG 2A =   should be 1000
!!! LOOP_CLOSE_TRES_LOW  iREG 2B =   should be 1000
 ! Init Indirect Registers UNSUCCESSFULLY.
Indirect Registers failed verification.
Module 0: FAILED FXS (FCC)
Module 1: Installed -- AUTO FXO (FCC mode)
Module 2: Installed -- AUTO FXO (FCC mode)
Module 3: Installed -- AUTO FXO (FCC mode)
Found a Wildcard TDM: Wildcard TDM400P REV E/F (3 modules)

Does this have to do with the fact that the module is way newer than the card?

TIA
C F

--
_
-- 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] (no subject)

[Kevin Kirts]

http://i-wikisport.com/product.php?page=32a

--
_
-- 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] AST-2011-002: Multiple array overflow and crash vulnerabilities in UDPTL code

[Asterisk Security Team]

   Asterisk Project Security Advisory - AST-2011-002

Product   Asterisk
Summary   Multiple array overflow and crash vulnerabilities in
  UDPTL code  
   Nature of Advisory Exploitable Stack and Heap Array Overflows  
 Susceptibility   Remote Unauthenticated Sessions 
Severity  Critical
 Exploits Known   No  
  Reported On January 27, 2011
  Reported By Matthew Nicholson   
   Posted On  February 21, 2011   
Last Updated On   February 21, 2011   
Advisory Contact  Matthew Nicholson
CVE Name  

   Description When decoding UDPTL packets, multiple stack and heap based 
   arrays can be made to overflow by specially crafted packets.   
   Systems doing T.38 pass through or termination are vulnerable. 

   Resolution The UDPTL decoding routines have been modified to respect the   
  limits of exploitable arrays.   
  
  In asterisk versions not containing the fix for this issue, 
  disabling T.38 support will prevent this vulnerability from 
  being exploited. T.38 support can be disabled in chan_sip by
  setting the t38pt_udptl option to "no" (it is off by default).  
  
  t38pt_udptl = no
  
  The chan_ooh323 module should also be disabled by adding the
  following line in modles.conf.  
  
  noload => chan_ooh323   

   Affected Versions
Product  Release Series 
 Asterisk Open Source1.4.x  All versions  
 Asterisk Open Source1.6.x  All versions  
   Asterisk Business Edition C.x.x  All versions  
  AsteriskNOW 1.5   All versions  
  s800i (Asterisk Appliance) 1.2.x  All versions  

  Corrected In
  Product   Release   
Asterisk Open Source1.4.39.2, 1.6.1.22, 1.6.2.16.2, 1.8.2.4   
 Asterisk Business Edition  C.3.6.3   

Patches
   URL Branch 
   http://downloads.asterisk.org/pub/security/AST-2011-002-1.4.diff1.4
   http://downloads.asterisk.org/pub/security/AST-2011-002-1.6.1.diff  1.6.1  
   http://downloads.asterisk.org/pub/security/AST-2011-002-1.6.2.diff  1.6.2  
   http://downloads.asterisk.org/pub/security/AST-2011-002-1.8.diff1.8

  Links 

   Asterisk Project Security Advisories are posted at 
   http://www.asterisk.org/security   
  
   This document may be superseded by later versions; if so, the latest   
   version will be posted at  
   http://downloads.digium.com/pub/security/AST-2011-002.pdf and  
   http://downloads.digium.com/pub/security/AST-2011-002.html 

Revision History
DateEditorRevisions Made  
   02/21/11Matthew Nicholson Initial Release  

   Asterisk Project Security Advisory - AST-2011-002
  Copyright (c) 2011 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.


--
_
-- 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:

[asterisk-users] Erroneous email from JIRA

[Russell Bryant]

Greetings,

If you have an account on issues.asterisk.org and just received an email about 
having an account created on a JIRA server, please ignore and accept our 
apologies for the accidental message.  We were doing some test migrations of 
data from issues.asterisk.org into a newer issue tracking system and forgot to 
disable email first.

Thanks,

--
Russell Bryant
Digium, Inc.  |  Engineering Manager, Open Source Software
445 Jan Davis Drive NW   -Huntsville, AL 35806  -  USA
jabber: rbry...@digium.com-=-skype: russell-bryant
www.digium.com -=- www.asterisk.org -=- blogs.asterisk.org



--
_
-- 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] Free calls to the US provider recommendation

[C. Savinovich]

You should try paying for the call, and then you will be able to get good
service


CS



On February 21, 2011 at 2:07 PM Christian  wrote:

> Hi all,
> Sorry for being a little off topic, but I just need some tips on some good
> provider that offers free calls to the US. I have tried out one called
> Whistlephone, but I am not able to receive calls with it and when I use the
> follow me feature it still rings here. So any other I should try?
> Many thanks for your help!
> Christian
>
>
> --
> _
> -- 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 
Christian Savinovich
Telecom & Telephony Consulting
646.982.3572
c.savinov...@itntelecom.com--
_
-- 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] T1 PRI shows yellow/red alarm

[Dean Hoover]

That is certainly an option, but my query was more on the side of is
it possible to trace/log the ESF frames.  From what I have read, there
are signals going back and forth from a lower level than the
D-channel, and in ESF there are codes that can be sent to the other
side to reset the frame.  If that is the case, I would like to be able
to log those frame messages.  If the issue is on my side, then it is
either Asterisk, libpri, zaptel or the card itself that is sending it.

Dean


On Mon, Feb 21, 2011 at 1:34 PM, Juan David Diaz  wrote:
> Your message was:
> 
> Here you go:
>
> /etc/zaptel.conf:
> loadzone = us
> defaultzone=us
>
> span=1,0,0,esf,b8zs
> bchan=1-23
> dchan=24
> span=2,1,0,esf,b8zs
> bchan=25-47
> dchan=48
>
> #Added 2nd 2xT1 card
> span=3,0,0,d4,ami
> e&m=49-72
> span=4,0,0,d4,ami
> fxoks=73-96
> -
>
> m, I would change the timing sources of the spans:
> span=1,1,0,esf,b8zs
> span=2,2,0,esf,b8zs
>
> Have you try to plug the PRI into another Span that has been working
> properly??
> Regards.
> Juan.
> Linux User #441131
>
>
> On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover  wrote:
>>
>> This doesn't represent the 2nd span?
>>
>> span=2,1,0,esf,b8zs
>> bchan=25-47
>> dchan=48
>>
>> Dean
>>
>>
>> On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz 
>> wrote:
>> > I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:
>> > yellow alarm on span 2
>> >
>> > regards.
>> >
>> >
>> > Juan.
>> > Linux User #441131
>> >
>> >
>> > On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:
>> >>
>> >> Here you go:
>> >>
>> >> /etc/zaptel.conf:
>> >> loadzone = us
>> >> defaultzone=us
>> >>
>> >> span=1,0,0,esf,b8zs
>> >> bchan=1-23
>> >> dchan=24
>> >> span=2,1,0,esf,b8zs
>> >> bchan=25-47
>> >> dchan=48
>> >>
>> >> #Added 2nd 2xT1 card
>> >> span=3,0,0,d4,ami
>> >> e&m=49-72
>> >> span=4,0,0,d4,ami
>> >> fxoks=73-96
>> >>
>> >> ---
>> >>
>> >> /etc/asterisk/zapata.conf:
>> >> [channels]
>> >> group=1
>> >> context=default
>> >> signalling=pri_cpe
>> >> switchtype=qsig
>> >> channel=>1-23
>> >>
>> >> group=2
>> >> context=twtelecom-in
>> >> signalling=pri_cpe
>> >> switchtype=5ess
>> >> echocancel=yes
>> >> channel=>25-47
>> >>
>> >> group=3
>> >> context=definity-in
>> >> signalling=em_w
>> >> channel=>49-72
>> >>
>> >> group=10
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>73
>> >>
>> >> group=11
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>74
>> >>
>> >> group=12
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>75
>> >>
>> >> group=13
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>76
>> >>
>> >> group=14
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>77
>> >>
>> >> group=15
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>78
>> >>
>> >> group=16
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>79
>> >>
>> >> group=17
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>80
>> >>
>> >> group=18
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>81
>> >>
>> >> group=19
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>82
>> >>
>> >> group=20
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>83
>> >>
>> >> group=21
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>84
>> >>
>> >> group=22
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>85
>> >>
>> >> group=23
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>86
>> >>
>> >> group=24
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>87
>> >>
>> >> group=25
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>88
>> >>
>> >> group=26
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>89
>> >>
>> >> group=27
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>90
>> >>
>> >> group=28
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>91
>> >>
>> >> group=29
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> thr

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Juan David Diaz]

have you check the PRI crossover cable?

Juan.
Linux User #441131


On Mon, Feb 21, 2011 at 2:35 PM, Juan David Diaz wrote:

> Ooops, my bad I Did not read the zaptel config file correctly,
> my apologize.
>
> span=1,0,0,esf,b8zs
> bchan=1-23
> dchan=24
> *span=2,1,0,esf,b8zs
> bchan=25-47
> dchan=48*
>
> Juan.
> Linux User #441131
>
>
>
> On Mon, Feb 21, 2011 at 2:34 PM, Juan David Diaz wrote:
>
>> Your message was:
>>
>> 
>> Here you go:
>>
>> /etc/zaptel.conf:
>> loadzone = us
>> defaultzone=us
>>
>> span=1,0,0,esf,b8zs
>> bchan=1-23
>> dchan=24
>> span=2,1,0,esf,b8zs
>> bchan=25-47
>> dchan=48
>>
>> #Added 2nd 2xT1 card
>> span=3,0,0,d4,ami
>> e&m=49-72
>> span=4,0,0,d4,ami
>> fxoks=73-96
>>
>> -
>>
>> m, I would change the timing sources of the spans:
>>
>>  span=1,1,0,esf,b8zs
>>
>> span=2,2,0,esf,b8zs
>>
>>
>> Have you try to plug the PRI into another Span that has been working
>> properly??
>>
>> Regards.
>>
>> Juan.
>> Linux User #441131
>>
>>
>>
>> On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover  wrote:
>>
>>> This doesn't represent the 2nd span?
>>>
>>> span=2,1,0,esf,b8zs
>>> bchan=25-47
>>> dchan=48
>>>
>>> Dean
>>>
>>>
>>> On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz 
>>> wrote:
>>> > I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:
>>> > yellow alarm on span 2
>>> >
>>> > regards.
>>> >
>>> >
>>> > Juan.
>>> > Linux User #441131
>>> >
>>> >
>>> > On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:
>>> >>
>>> >> Here you go:
>>> >>
>>> >> /etc/zaptel.conf:
>>> >> loadzone = us
>>> >> defaultzone=us
>>> >>
>>> >> span=1,0,0,esf,b8zs
>>> >> bchan=1-23
>>> >> dchan=24
>>> >> span=2,1,0,esf,b8zs
>>> >> bchan=25-47
>>> >> dchan=48
>>> >>
>>> >> #Added 2nd 2xT1 card
>>> >> span=3,0,0,d4,ami
>>> >> e&m=49-72
>>> >> span=4,0,0,d4,ami
>>> >> fxoks=73-96
>>> >>
>>> >> ---
>>> >>
>>> >> /etc/asterisk/zapata.conf:
>>> >> [channels]
>>> >> group=1
>>> >> context=default
>>> >> signalling=pri_cpe
>>> >> switchtype=qsig
>>> >> channel=>1-23
>>> >>
>>> >> group=2
>>> >> context=twtelecom-in
>>> >> signalling=pri_cpe
>>> >> switchtype=5ess
>>> >> echocancel=yes
>>> >> channel=>25-47
>>> >>
>>> >> group=3
>>> >> context=definity-in
>>> >> signalling=em_w
>>> >> channel=>49-72
>>> >>
>>> >> group=10
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>73
>>> >>
>>> >> group=11
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>74
>>> >>
>>> >> group=12
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>75
>>> >>
>>> >> group=13
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>76
>>> >>
>>> >> group=14
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>77
>>> >>
>>> >> group=15
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>78
>>> >>
>>> >> group=16
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>79
>>> >>
>>> >> group=17
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>80
>>> >>
>>> >> group=18
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>81
>>> >>
>>> >> group=19
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>82
>>> >>
>>> >> group=20
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>83
>>> >>
>>> >> group=21
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>84
>>> >>
>>> >> group=22
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>85
>>> >>
>>> >> group=23
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>86
>>> >>
>>> >> group=24
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>87
>>> >>
>>> >> group=25
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>88
>>> >>
>>> >> group=26
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>89
>>> >>
>>> >> group=27
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> transfer=yes
>>> >> channel=>90
>>> >>
>>> >> group=28
>>> >> context=testivr-in
>>> >> signalling=fxo_ks
>>> >> threewaycalling=yes
>>> >> t

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Juan David Diaz]

Ooops, my bad I Did not read the zaptel config file correctly, my apologize.

span=1,0,0,esf,b8zs
bchan=1-23
dchan=24
*span=2,1,0,esf,b8zs
bchan=25-47
dchan=48*

Juan.
Linux User #441131


On Mon, Feb 21, 2011 at 2:34 PM, Juan David Diaz wrote:

> Your message was:
>
> 
> Here you go:
>
> /etc/zaptel.conf:
> loadzone = us
> defaultzone=us
>
> span=1,0,0,esf,b8zs
> bchan=1-23
> dchan=24
> span=2,1,0,esf,b8zs
> bchan=25-47
> dchan=48
>
> #Added 2nd 2xT1 card
> span=3,0,0,d4,ami
> e&m=49-72
> span=4,0,0,d4,ami
> fxoks=73-96
>
> -
>
> m, I would change the timing sources of the spans:
>
>  span=1,1,0,esf,b8zs
>
> span=2,2,0,esf,b8zs
>
>
> Have you try to plug the PRI into another Span that has been working
> properly??
>
> Regards.
>
> Juan.
> Linux User #441131
>
>
>
> On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover  wrote:
>
>> This doesn't represent the 2nd span?
>>
>> span=2,1,0,esf,b8zs
>> bchan=25-47
>> dchan=48
>>
>> Dean
>>
>>
>> On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz 
>> wrote:
>> > I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:
>> > yellow alarm on span 2
>> >
>> > regards.
>> >
>> >
>> > Juan.
>> > Linux User #441131
>> >
>> >
>> > On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:
>> >>
>> >> Here you go:
>> >>
>> >> /etc/zaptel.conf:
>> >> loadzone = us
>> >> defaultzone=us
>> >>
>> >> span=1,0,0,esf,b8zs
>> >> bchan=1-23
>> >> dchan=24
>> >> span=2,1,0,esf,b8zs
>> >> bchan=25-47
>> >> dchan=48
>> >>
>> >> #Added 2nd 2xT1 card
>> >> span=3,0,0,d4,ami
>> >> e&m=49-72
>> >> span=4,0,0,d4,ami
>> >> fxoks=73-96
>> >>
>> >> ---
>> >>
>> >> /etc/asterisk/zapata.conf:
>> >> [channels]
>> >> group=1
>> >> context=default
>> >> signalling=pri_cpe
>> >> switchtype=qsig
>> >> channel=>1-23
>> >>
>> >> group=2
>> >> context=twtelecom-in
>> >> signalling=pri_cpe
>> >> switchtype=5ess
>> >> echocancel=yes
>> >> channel=>25-47
>> >>
>> >> group=3
>> >> context=definity-in
>> >> signalling=em_w
>> >> channel=>49-72
>> >>
>> >> group=10
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>73
>> >>
>> >> group=11
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>74
>> >>
>> >> group=12
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>75
>> >>
>> >> group=13
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>76
>> >>
>> >> group=14
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>77
>> >>
>> >> group=15
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>78
>> >>
>> >> group=16
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>79
>> >>
>> >> group=17
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>80
>> >>
>> >> group=18
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>81
>> >>
>> >> group=19
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>82
>> >>
>> >> group=20
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>83
>> >>
>> >> group=21
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>84
>> >>
>> >> group=22
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>85
>> >>
>> >> group=23
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>86
>> >>
>> >> group=24
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>87
>> >>
>> >> group=25
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>88
>> >>
>> >> group=26
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>89
>> >>
>> >> group=27
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>90
>> >>
>> >> group=28
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>91
>> >>
>> >> group=29
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>92
>> >>
>> >> group=30
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes
>> >> transfer=yes
>> >> channel=>93
>> >>
>> >> group=31
>> >> context=testivr-in
>> >> signalling=fxo_ks
>> >> threewaycalling=yes

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Juan David Diaz]

Your message was:


Here you go:

/etc/zaptel.conf:
loadzone = us
defaultzone=us

span=1,0,0,esf,b8zs
bchan=1-23
dchan=24
span=2,1,0,esf,b8zs
bchan=25-47
dchan=48

#Added 2nd 2xT1 card
span=3,0,0,d4,ami
e&m=49-72
span=4,0,0,d4,ami
fxoks=73-96
-

m, I would change the timing sources of the spans:

span=1,1,0,esf,b8zs

span=2,2,0,esf,b8zs


Have you try to plug the PRI into another Span that has been working
properly??

Regards.

Juan.
Linux User #441131


On Mon, Feb 21, 2011 at 2:23 PM, Dean Hoover  wrote:

> This doesn't represent the 2nd span?
>
> span=2,1,0,esf,b8zs
> bchan=25-47
> dchan=48
>
> Dean
>
>
> On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz 
> wrote:
> > I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:
> > yellow alarm on span 2
> >
> > regards.
> >
> >
> > Juan.
> > Linux User #441131
> >
> >
> > On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:
> >>
> >> Here you go:
> >>
> >> /etc/zaptel.conf:
> >> loadzone = us
> >> defaultzone=us
> >>
> >> span=1,0,0,esf,b8zs
> >> bchan=1-23
> >> dchan=24
> >> span=2,1,0,esf,b8zs
> >> bchan=25-47
> >> dchan=48
> >>
> >> #Added 2nd 2xT1 card
> >> span=3,0,0,d4,ami
> >> e&m=49-72
> >> span=4,0,0,d4,ami
> >> fxoks=73-96
> >>
> >> ---
> >>
> >> /etc/asterisk/zapata.conf:
> >> [channels]
> >> group=1
> >> context=default
> >> signalling=pri_cpe
> >> switchtype=qsig
> >> channel=>1-23
> >>
> >> group=2
> >> context=twtelecom-in
> >> signalling=pri_cpe
> >> switchtype=5ess
> >> echocancel=yes
> >> channel=>25-47
> >>
> >> group=3
> >> context=definity-in
> >> signalling=em_w
> >> channel=>49-72
> >>
> >> group=10
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>73
> >>
> >> group=11
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>74
> >>
> >> group=12
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>75
> >>
> >> group=13
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>76
> >>
> >> group=14
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>77
> >>
> >> group=15
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>78
> >>
> >> group=16
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>79
> >>
> >> group=17
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>80
> >>
> >> group=18
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>81
> >>
> >> group=19
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>82
> >>
> >> group=20
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>83
> >>
> >> group=21
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>84
> >>
> >> group=22
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>85
> >>
> >> group=23
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>86
> >>
> >> group=24
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>87
> >>
> >> group=25
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>88
> >>
> >> group=26
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>89
> >>
> >> group=27
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>90
> >>
> >> group=28
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>91
> >>
> >> group=29
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>92
> >>
> >> group=30
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>93
> >>
> >> group=31
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>94
> >>
> >> group=32
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>95
> >>
> >> group=33
> >> context=testivr-in
> >> signalling=fxo_ks
> >> threewaycalling=yes
> >> transfer=yes
> >> channel=>96
> >>
> >> ---
> >>
> >> On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz 
> >> wrote:
> >> > Dean,
> >> > what's your zaptel & Zapata config_
> >> > regards
> >> > Juan.
> >> > Linux User #441131
> >> >
> >> >
> >> > On Mo

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Dean Hoover]

This doesn't represent the 2nd span?

span=2,1,0,esf,b8zs
bchan=25-47
dchan=48

Dean


On Mon, Feb 21, 2011 at 1:18 PM, Juan David Diaz  wrote:
> I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:
> yellow alarm on span 2
>
> regards.
>
>
> Juan.
> Linux User #441131
>
>
> On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:
>>
>> Here you go:
>>
>> /etc/zaptel.conf:
>> loadzone = us
>> defaultzone=us
>>
>> span=1,0,0,esf,b8zs
>> bchan=1-23
>> dchan=24
>> span=2,1,0,esf,b8zs
>> bchan=25-47
>> dchan=48
>>
>> #Added 2nd 2xT1 card
>> span=3,0,0,d4,ami
>> e&m=49-72
>> span=4,0,0,d4,ami
>> fxoks=73-96
>>
>> ---
>>
>> /etc/asterisk/zapata.conf:
>> [channels]
>> group=1
>> context=default
>> signalling=pri_cpe
>> switchtype=qsig
>> channel=>1-23
>>
>> group=2
>> context=twtelecom-in
>> signalling=pri_cpe
>> switchtype=5ess
>> echocancel=yes
>> channel=>25-47
>>
>> group=3
>> context=definity-in
>> signalling=em_w
>> channel=>49-72
>>
>> group=10
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>73
>>
>> group=11
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>74
>>
>> group=12
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>75
>>
>> group=13
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>76
>>
>> group=14
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>77
>>
>> group=15
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>78
>>
>> group=16
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>79
>>
>> group=17
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>80
>>
>> group=18
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>81
>>
>> group=19
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>82
>>
>> group=20
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>83
>>
>> group=21
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>84
>>
>> group=22
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>85
>>
>> group=23
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>86
>>
>> group=24
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>87
>>
>> group=25
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>88
>>
>> group=26
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>89
>>
>> group=27
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>90
>>
>> group=28
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>91
>>
>> group=29
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>92
>>
>> group=30
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>93
>>
>> group=31
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>94
>>
>> group=32
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>95
>>
>> group=33
>> context=testivr-in
>> signalling=fxo_ks
>> threewaycalling=yes
>> transfer=yes
>> channel=>96
>>
>> ---
>>
>> On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz 
>> wrote:
>> > Dean,
>> > what's your zaptel & Zapata config_
>> > regards
>> > Juan.
>> > Linux User #441131
>> >
>> >
>> > On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover  wrote:
>> >>
>> >> We are running Asterisk version 1.4.23-1, libpri-1.4.9 and
>> >> zaptel-1.4.12.1 and two Digium TE220Ps.  Debugs are set to 10.
>> >>
>> >> We have a T1 PRI connected to the telco.  Over the last 4-5 days, we
>> >> have getting Yellow/Red alarms coming from the T1 PRI.  The other two
>> >> ports in use are connected to internal test switches (Avaya
>> >> Legend/Avaya Definity), and are not showing any errors.
>> >>
>> >> /var/log/asterisk/messages reports:
>> >> [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4)
>> >> on Primary D-channel of span 2
>> >> [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on
>> >> D-channel for span 2
>> >>
>> >> /var/log/syslog reports:
>> >> Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting
>> >> yellow alarm on span 2
>> >> Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto
>> >> card
>> >> 0!
>> >> Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto
>> >> card
>> >> 0!
>> >> Feb 21 12:22:01 asterisk kernel

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Juan David Diaz]

I don't see any problem.. but, i don't see the 2nd SPAN @ zaptel:

*yellow alarm on span 2*


regards.


Juan.
Linux User #441131


On Mon, Feb 21, 2011 at 2:11 PM, Dean Hoover  wrote:

> Here you go:
>
> /etc/zaptel.conf:
> loadzone = us
> defaultzone=us
>
> span=1,0,0,esf,b8zs
> bchan=1-23
> dchan=24
> span=2,1,0,esf,b8zs
> bchan=25-47
> dchan=48
>
> #Added 2nd 2xT1 card
> span=3,0,0,d4,ami
> e&m=49-72
> span=4,0,0,d4,ami
> fxoks=73-96
>
> ---
>
> /etc/asterisk/zapata.conf:
> [channels]
> group=1
> context=default
> signalling=pri_cpe
> switchtype=qsig
> channel=>1-23
>
> group=2
> context=twtelecom-in
> signalling=pri_cpe
> switchtype=5ess
> echocancel=yes
> channel=>25-47
>
> group=3
> context=definity-in
> signalling=em_w
> channel=>49-72
>
> group=10
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>73
>
> group=11
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>74
>
> group=12
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>75
>
> group=13
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>76
>
> group=14
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>77
>
> group=15
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>78
>
> group=16
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>79
>
> group=17
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>80
>
> group=18
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>81
>
> group=19
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>82
>
> group=20
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>83
>
> group=21
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>84
>
> group=22
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>85
>
> group=23
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>86
>
> group=24
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>87
>
> group=25
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>88
>
> group=26
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>89
>
> group=27
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>90
>
> group=28
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>91
>
> group=29
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>92
>
> group=30
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>93
>
> group=31
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>94
>
> group=32
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>95
>
> group=33
> context=testivr-in
> signalling=fxo_ks
> threewaycalling=yes
> transfer=yes
> channel=>96
>
> ---
>
> On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz 
> wrote:
> > Dean,
> > what's your zaptel & Zapata config_
> > regards
> > Juan.
> > Linux User #441131
> >
> >
> > On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover  wrote:
> >>
> >> We are running Asterisk version 1.4.23-1, libpri-1.4.9 and
> >> zaptel-1.4.12.1 and two Digium TE220Ps.  Debugs are set to 10.
> >>
> >> We have a T1 PRI connected to the telco.  Over the last 4-5 days, we
> >> have getting Yellow/Red alarms coming from the T1 PRI.  The other two
> >> ports in use are connected to internal test switches (Avaya
> >> Legend/Avaya Definity), and are not showing any errors.
> >>
> >> /var/log/asterisk/messages reports:
> >> [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4)
> >> on Primary D-channel of span 2
> >> [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on
> >> D-channel for span 2
> >>
> >> /var/log/syslog reports:
> >> Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting
> >> yellow alarm on span 2
> >> Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card
> >> 0!
> >> Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card
> >> 0!
> >> Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing
> >> yellow alarm on span 2
> >>
> >> Intensive PRI debugging does not show any errors prior to the alarm.
> >>
> >> The other part to this is for a while it was pretty intermittent.  One
> >> day we would get it 2 times, another 8-12 times.  Today, however, it
> >> seems to be happening around every 11-13 minutes.  Before this
> >> started, there were no errors for the 6 days

Re: [asterisk-users] T1 PRI shows yellow/red alarm

[Dean Hoover]

Here you go:

/etc/zaptel.conf:
loadzone = us
defaultzone=us

span=1,0,0,esf,b8zs
bchan=1-23
dchan=24
span=2,1,0,esf,b8zs
bchan=25-47
dchan=48

#Added 2nd 2xT1 card
span=3,0,0,d4,ami
e&m=49-72
span=4,0,0,d4,ami
fxoks=73-96

---

/etc/asterisk/zapata.conf:
[channels]
group=1
context=default
signalling=pri_cpe
switchtype=qsig
channel=>1-23

group=2
context=twtelecom-in
signalling=pri_cpe
switchtype=5ess
echocancel=yes
channel=>25-47

group=3
context=definity-in
signalling=em_w
channel=>49-72

group=10
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>73

group=11
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>74

group=12
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>75

group=13
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>76

group=14
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>77

group=15
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>78

group=16
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>79

group=17
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>80

group=18
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>81

group=19
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>82

group=20
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>83

group=21
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>84

group=22
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>85

group=23
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>86

group=24
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>87

group=25
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>88

group=26
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>89

group=27
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>90

group=28
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>91

group=29
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>92

group=30
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>93

group=31
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>94

group=32
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>95

group=33
context=testivr-in
signalling=fxo_ks
threewaycalling=yes
transfer=yes
channel=>96

---

On Mon, Feb 21, 2011 at 12:58 PM, Juan David Diaz  wrote:
> Dean,
> what's your zaptel & Zapata config_
> regards
> Juan.
> Linux User #441131
>
>
> On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover  wrote:
>>
>> We are running Asterisk version 1.4.23-1, libpri-1.4.9 and
>> zaptel-1.4.12.1 and two Digium TE220Ps.  Debugs are set to 10.
>>
>> We have a T1 PRI connected to the telco.  Over the last 4-5 days, we
>> have getting Yellow/Red alarms coming from the T1 PRI.  The other two
>> ports in use are connected to internal test switches (Avaya
>> Legend/Avaya Definity), and are not showing any errors.
>>
>> /var/log/asterisk/messages reports:
>> [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4)
>> on Primary D-channel of span 2
>> [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on
>> D-channel for span 2
>>
>> /var/log/syslog reports:
>> Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting
>> yellow alarm on span 2
>> Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card
>> 0!
>> Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card
>> 0!
>> Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing
>> yellow alarm on span 2
>>
>> Intensive PRI debugging does not show any errors prior to the alarm.
>>
>> The other part to this is for a while it was pretty intermittent.  One
>> day we would get it 2 times, another 8-12 times.  Today, however, it
>> seems to be happening around every 11-13 minutes.  Before this
>> started, there were no errors for the 6 days prior.
>>
>> The first response from the telco 4 days ago said that it was an issue
>> on their T3, then came back saying we were sending something to reset
>> the circuit, but I interpret "PRI got event" as meaning we received
>> something from them.
>>
>> They put a COM tracer in our building, on that circuit, since Friday
>> afternoon.  They took it with them to examine the results this
>> morning, and are supposed to call me when they know something.
>>
>> While they are doing that, I want to make sure that I have all the
>> information I need in order to diagnose it.  I haven't found a way to
>> trace the actual B8ZS/ESF frames, and was wondering 

[asterisk-users] Free calls to the US provider recommendation

[Christian]

Hi all,
Sorry for being a little off topic, but I just need some tips on some good 
provider that offers free calls to the US. I have tried out one called 
Whistlephone, but I am not able to receive calls with it and when I use the 
follow me feature it still rings here. So any other I should try?
Many thanks for your help!
Christian


--
_
-- 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] T1 PRI shows yellow/red alarm

[Juan David Diaz]

Dean,

what's your zaptel & Zapata config_

regards

Juan.
Linux User #441131


On Mon, Feb 21, 2011 at 1:44 PM, Dean Hoover  wrote:

> We are running Asterisk version 1.4.23-1, libpri-1.4.9 and
> zaptel-1.4.12.1 and two Digium TE220Ps.  Debugs are set to 10.
>
> We have a T1 PRI connected to the telco.  Over the last 4-5 days, we
> have getting Yellow/Red alarms coming from the T1 PRI.  The other two
> ports in use are connected to internal test switches (Avaya
> Legend/Avaya Definity), and are not showing any errors.
>
> /var/log/asterisk/messages reports:
> [Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4)
> on Primary D-channel of span 2
> [Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on
> D-channel for span 2
>
> /var/log/syslog reports:
> Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting
> yellow alarm on span 2
> Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0!
> Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0!
> Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing
> yellow alarm on span 2
>
> Intensive PRI debugging does not show any errors prior to the alarm.
>
> The other part to this is for a while it was pretty intermittent.  One
> day we would get it 2 times, another 8-12 times.  Today, however, it
> seems to be happening around every 11-13 minutes.  Before this
> started, there were no errors for the 6 days prior.
>
> The first response from the telco 4 days ago said that it was an issue
> on their T3, then came back saying we were sending something to reset
> the circuit, but I interpret "PRI got event" as meaning we received
> something from them.
>
> They put a COM tracer in our building, on that circuit, since Friday
> afternoon.  They took it with them to examine the results this
> morning, and are supposed to call me when they know something.
>
> While they are doing that, I want to make sure that I have all the
> information I need in order to diagnose it.  I haven't found a way to
> trace the actual B8ZS/ESF frames, and was wondering if there was a way
> for me to log those events.  It's not that I don't trust them, but by
> the same token I haven't changed anything on my end, the other port on
> the Digium card isn't reporting an issue, and a complete shutdown of
> the Asterisk server didn't change the results.
>
> Any advice would be greatly appreciated.
>
> Dean Hoover
> Milwaukee, Wisconsin
>
> --
> _
> -- 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

[asterisk-users] T1 PRI shows yellow/red alarm

[Dean Hoover]

We are running Asterisk version 1.4.23-1, libpri-1.4.9 and
zaptel-1.4.12.1 and two Digium TE220Ps.  Debugs are set to 10.

We have a T1 PRI connected to the telco.  Over the last 4-5 days, we
have getting Yellow/Red alarms coming from the T1 PRI.  The other two
ports in use are connected to internal test switches (Avaya
Legend/Avaya Definity), and are not showing any errors.

/var/log/asterisk/messages reports:
[Feb 21 12:21:56] NOTICE[4795] chan_dahdi.c: PRI got event: Alarm (4)
on Primary D-channel of span 2
[Feb 21 12:21:56] DEBUG[4795] chan_dahdi.c: Got event Alarm (4) on
D-channel for span 2

/var/log/syslog reports:
Feb 21 12:21:56 asterisk kernel: [509981.796536] wct2xxp: Setting
yellow alarm on span 2
Feb 21 12:21:56 asterisk kernel: [509981.796562] timing source auto card 0!
Feb 21 12:21:56 asterisk kernel: [509981.813535] timing source auto card 0!
Feb 21 12:22:01 asterisk kernel: [509986.813869] wct2xxp: Clearing
yellow alarm on span 2

Intensive PRI debugging does not show any errors prior to the alarm.

The other part to this is for a while it was pretty intermittent.  One
day we would get it 2 times, another 8-12 times.  Today, however, it
seems to be happening around every 11-13 minutes.  Before this
started, there were no errors for the 6 days prior.

The first response from the telco 4 days ago said that it was an issue
on their T3, then came back saying we were sending something to reset
the circuit, but I interpret "PRI got event" as meaning we received
something from them.

They put a COM tracer in our building, on that circuit, since Friday
afternoon.  They took it with them to examine the results this
morning, and are supposed to call me when they know something.

While they are doing that, I want to make sure that I have all the
information I need in order to diagnose it.  I haven't found a way to
trace the actual B8ZS/ESF frames, and was wondering if there was a way
for me to log those events.  It's not that I don't trust them, but by
the same token I haven't changed anything on my end, the other port on
the Digium card isn't reporting an issue, and a complete shutdown of
the Asterisk server didn't change the results.

Any advice would be greatly appreciated.

Dean Hoover
Milwaukee, Wisconsin

--
_
-- 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] Assigning an extension to a roaming phone

[Warren Selby]

On Mon, Feb 21, 2011 at 12:37 PM, Warren Selby wrote:

> Then you need to include the [roaming-ext] context in whatever context your
> phones dial from.  The basic idea behind this is that you need to store the
> extension where your roamer is currently sitting in your DB, which you were
> doing.  By adding the ${CALLERID(num)} to the database, you give it an idea
> of where the calls should go.  Now, this means your ${CALLERID(num)}
> variable needs to match your SIP endpoint's name, of course, but if these
> don't currently match, I'm pretty sure there is a variable you can use to
> achieve the same effect.
>

I meant to say, you were not currently storing the extension in your DB,
only the roaming digits.  Sorry for the confusion.

-- 
Thanks,
--Warren Selby, dCAP
http://www.selbytech.com
--
_
-- 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] Assigning an extension to a roaming phone

[Warren Selby]

On Mon, Feb 21, 2011 at 11:33 AM, Danny Nicholas  wrote:

>
> [Feb 21 17:53:06] WARNING[26195]: chan_sip.c:2921 create_addr: No such
> host:
> 001
> [Feb 21 17:53:06] WARNING[26195]: app_dial.c:1202 dial_exec_full:
> Unable to create channel of type 'SIP' (cause 3 - No route to
> destination)
>

Your dialplan needs to be similar to the following (this is off the top of
my head, so you may need to adjust for typos or whatever):

[roaming-ext]
;Create a new roaming extension
exten => 3001,1(readop),Verbose(Create roaming extension)
exten => 3001,n,Read(digito,beep,3)
exten => 3001,n,Playback(you-entered)
exten => 3001,n,SayDigits(${digito})
exten => 3001,n,Verbose(Setting roaming extension 4${digito} to call
${CALLERID(num)})
exten => 3001,n,Set(DB(roam/${digito})=${CALLERID(num)})
exten => 3001,n,Playback(vm-goodbye)
exten => 3001,n,Hangup()

;Dial a roaming extension
exten => _4XXX,1,Verbose(Calling roaming extension ${EXTEN})
exten => _4XXX,n,Set(ROAMEXT=${DB(roam/${EXTEN:1})})
exten => _4XXX,n,Dial(SIP/${ROAMEXT},30)

Then you need to include the [roaming-ext] context in whatever context your
phones dial from.  The basic idea behind this is that you need to store the
extension where your roamer is currently sitting in your DB, which you were
doing.  By adding the ${CALLERID(num)} to the database, you give it an idea
of where the calls should go.  Now, this means your ${CALLERID(num)}
variable needs to match your SIP endpoint's name, of course, but if these
don't currently match, I'm pretty sure there is a variable you can use to
achieve the same effect.


-- 
Thanks,
--Warren Selby, dCAP
http://www.selbytech.com
--
_
-- 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] SIP METHOD BYE

[Fellipe ...]

Hello everybody!

I get this message when making outbound calls:

[Feb
 21 14:24:46] WARNING[25204]: chan_sip.c:3621 __sip_autodestruct: 
Autodestruct on dialog 'ee162385cac5cc9c@10.1.1.13' with owner in place 
(Method: BYE)

All inbound calls are fine.
In other SIP users everything seems fine and I can make outbound calls.

Asterisk: 1.8.2/

Any idea???

Best regards,

Fellipe   --
_
-- 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] trunk not working if I register a phone at the same IP as the trunk peer's IP

[Ricardo Carvalho]

Thanks Faisal, in fact I made a test that confirmed that in realtime
asterisk doesn’t supported static peers, like you told me.
Do you know if newer versions of asterisk, like 1.8, have this issue already
solved?

Regards,
Ricardo.




On Wed, Feb 16, 2011 at 6:26 PM, Faisal Hanif  wrote:

> I have played a lot on this issue with asterisk config but in realtime it
> doesn’t supported static peers with version 1.6.2.14.
>
>
>
> *From:* Ricardo Carvalho [mailto:rjcarvalho.li...@gmail.com]
> *Sent:* Wednesday, February 16, 2011 10:21 PM
>
> *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> *Cc:* Faisal Hanif
> *Subject:* Re: [asterisk-users] trunk not working if I register a phone at
> the same IP as the trunk peer's IP
>
>
>
> Isn't this a limitation that can be surpassed with some configuration that
> I'm lacking in my sip.conf or extensions.conf of my asterisk?
>
>
>
> Ricardo.
>
>
>
>
>
>
>
>
>
> On Wed, Feb 16, 2011 at 4:54 PM, Faisal Hanif  wrote:
>
> Well a quick n easy fix for you is you can configure you call sending peers
> to use username & secret in INVITE. As far as I know it possible in almost
> all CISCO, Avaya and all other standard Gateway and SBCs which follows full
> SIP RFCs.
>
>
>
> If you can’t do it then you need to use curl as realtime engine instead of
> MySQL. It will call a URL for each SIP request which you can handle with
> flexibility in your CGI scripts with apache. But be careful as per my
> experience asterisk 1.6 with curl as realtime engine can handle a max of 120
> registration in parallel if registration refresh time is 120 seconds.
>
>
>
> Faisal Hanif
>
>
>
> *From:* asterisk-users-boun...@lists.digium.com [mailto:
> asterisk-users-boun...@lists.digium.com] *On Behalf Of *Ricardo Carvalho
> *Sent:* Wednesday, February 16, 2011 9:41 PM
> *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> *Subject:* [asterisk-users] trunk not working if I register a phone at the
> same IP as the trunk peer's IP
>
>
>
> How should I configure my asterisk server so that I can receive calls from
> an unregistered peer from whom I also receive registrations of sip phones?
>
>
>
> I'm asking you this, because with my actual configuration, when I register
> a contact from that peer's IP, no more inbound calls are accepted from that
> peer, as my asterisk rejects those INVITEs with "407 Proxy Authentication
> Required", I assume because they don't carry the registered contact
> registration!!!
>
> My SIP contacts have type=friend and all inbound calls not coming from my
> registered phones fall in the default context without authentication, so
> that someone in the Internet be able to call freely through the Internet
> anyone in my server's dial plan.
>
>
>
> Some ideas?
>
>
>
> Regards,
>
> Ricardo Carvalho.
>
>
> --
> _
> -- 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] Assigning an extension to a roaming phone

[Danny Nicholas]

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Axelle
Sent: Monday, February 21, 2011 11:09 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Assigning an extension to a roaming phone

Hi Danny,

Thanks again for your help !




> line 2 plays "enter roaming number" (you have to record it)

well, I'm trying to use a pre-recorded sound.
But it does not play it.

exten => 3001,n,playback(vm-youhave)
I do have the file in /usr/share/asterisk/sounds:
-rw-r--r-- 1 root root 1452 2008-03-06 00:39 vm-youhave.gsm
but still it does not play it ?!

The goodbye at the end does play correctly.

** vm-goodbye is in /usr/share/asterisk/sounds?

> Part two
> exten => _4XXX,1,Set(ROAM=${DB(roam/ext)})
> exten => _4XXX,n,Dial(SIP/${ROAM},30,,mKkTt)
>
> line 1 user dials 4001 and gets ${ROAM} set from ASTDB
> line 2 attempts to dial SIP extension based on ${ROAM} value.

I dialed 3001, then 001. It does say 001 back.
But then 4001 does not work.

[Feb 21 17:53:06] WARNING[26195]: chan_sip.c:2921 create_addr: No such host:
001
[Feb 21 17:53:06] WARNING[26195]: app_dial.c:1202 dial_exec_full:
Unable to create channel of type 'SIP' (cause 3 - No route to
destination)

-- Axelle

I doubt you have an extension 001 in your list (the number 4001 is trying to
dial).  Is the ${ROAM} trying to reach an in-house extension or an outside
number?


--
_
-- 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] Assigning an extension to a roaming phone

[Axelle]

Hi Danny,

Thanks again for your help !


> Exten => 4001,1,Dial(DAHDI/g1/5551212)
> Or
> Exten => 4001,1,Dial(SIP/5551...@myprovider.com)

It looks like I'd be using Dial(SIP/...) as for other numbers I have a
macro such as this:
[macro-dialSIP]
exten => s,1,Dial(SIP/${ARG1})
exten => s,2,Goto(s-${DIALSTATUS},1)
exten => s-CANCEL,1,Hangup
etc

> line 2 plays "enter roaming number" (you have to record it)

well, I'm trying to use a pre-recorded sound.
But it does not play it.

exten => 3001,n,playback(vm-youhave)
I do have the file in /usr/share/asterisk/sounds:
-rw-r--r-- 1 root root 1452 2008-03-06 00:39 vm-youhave.gsm
but still it does not play it ?!

The goodbye at the end does play correctly.

> Part two
> exten => _4XXX,1,Set(ROAM=${DB(roam/ext)})
> exten => _4XXX,n,Dial(SIP/${ROAM},30,,mKkTt)
>
> line 1 user dials 4001 and gets ${ROAM} set from ASTDB
> line 2 attempts to dial SIP extension based on ${ROAM} value.

I dialed 3001, then 001. It does say 001 back.
But then 4001 does not work.

[Feb 21 17:53:06] WARNING[26195]: chan_sip.c:2921 create_addr: No such host: 001
[Feb 21 17:53:06] WARNING[26195]: app_dial.c:1202 dial_exec_full:
Unable to create channel of type 'SIP' (cause 3 - No route to
destination)

-- Axelle

--
_
-- 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] Difference mohsuggest & mohinterpret

[Jonas Kellens]

Hello list,

what is the difference between mohsuggest & mohinterpret when defining a 
SIP peer ?!


If a certain SIP peer puts another channel on hold, what field then 
determines the moh class that Asterisk will choose to play to that channel ?



If I take the test and call from peer A to peer B, and peer A puts peer 
B in hold, then the class of peer B is taken... that's not what I want.


If I call an external number from peer A, and put this channel on hold, 
then the 'default' class is chosen and played to the external number, 
which is also not what I want.



So where do I define (on a peer basis) which type of music on hold is 
played to the number (internal & external) dialed ?



Kind regards,
Jonas.
--
_
-- 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] Dialplan execution stops on app call even with TryExec (Am I missing something simple?)

[Jay Reeder]

 We're having an issue where we call ReceiveFax in a context that
includes a hangup extension and half the time dialplan execution doesn't
continue after the fax is received successfully.  Am I missing something
simple here?  Below is a sample call where this happened:

The last log line for this channel/call is:

[Feb 21 09:10:53] VERBOSE[13730] res_fax_digium.c: -- Channel 
'SIP/Level3_sip_peer_mcqueen-2c3d' FAX session '228' is complete, result: 
'SUCCESS' (FAX_SUCCESS), error: 'NO_ERROR', pages: 8, resolution: '204x196', 
transfer rate: '9600', remoteSID: 'TIME'

The context it's executing in is:

[ext-fax-voicenation]
exten => s,1,Noop(Receiving Fax for: ${FROM_DID} From: ${CALLERID(all)})
exten => s,n(receivefax),StopPlaytones
exten => 
s,n,Set(FAX_FILE_NAME=/var/www/html/vncake/fax_temp/${FROM_DID}-${CALLERID(number)}-${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)}-${UNIQUEID}.tif)
; Gafachi is known to have a broken ecm implementation - disable on receive - 
also send with 'z' option
exten => s,n,Set(trunk_name=${CUT(CHANNEL,-,1)})
exten => s,n,Noop(trunk name is ${trunk_name:4})
exten => s,n,ExecIf($[ "${trunk_name:4:7}" = "gafachi"]?Set(FAXOPT(ecm)=no))
;--
; Level3 V17/V34 modems were unreliable and V17 (14400) wasn't working so we 
downgrade to slower fax-modems
exten => s,n,Set(FAXOPT(modem)="V27,V29")
;--
exten => s,n,Set(FAXDELIVERED=no)
exten => s,n,TryExec(ReceiveFAX(${FAX_FILE_NAME},f))
exten => s,n,System(/var/www/html/vncake/cake/console/cake -app 
/var/www/html/vncake/app email_fax ${FAX_FILE_NAME} ${FAXPAGES} 
err:${FAXOPT(error)})
exten => s,n,Set(FAXDELIVERED=yes)
exten => s,n,ExecIf($["${FAXOPT(error)}"=""]?Set(FAXSTATUS=FAILED LICENSE 
EXCEEDED))
exten => s,n,ExecIf($["${FAXOPT(error)}"!="" && 
"${FAXOPT(error)}"!="NO_ERROR"]?Set(FAXSTATUS="FAILED FAXOPT: error: 
${FAXOPT(error)} status: ${FAXOPT(status)} statusstr: ${FAXOPT(statusstr)}"))
exten => s,n,Hangup
exten => h,1,Noop(*** process fax now ***)
exten => h,n,GotoIf($["${FAXDELIVERED}" = "yes"]?end)
; if hangup while processing script above(before flag set =yes) then will jump 
to hangup and double process - need to pause here so script can make adjustments
exten => h,n,System(/bin/sleep 5)
exten => h,n,System(/var/www/html/vncake/cake/console/cake -app 
/var/www/html/vncake/app email_fax ${FAX_FILE_NAME} ${FAXPAGES} 
err:${FAXOPT(error)})
exten => h,n,Set(FAXDELIVERED=yes)
exten => h,n(end),Macro(hangupcall,)
exten => h,process+101(failed),Noop(FAX ${FAXSTATUS} for:${FAX_RX_EMAIL} , 
From: ${CALLERID(all)})
; email to notify instability in the fax module
exten => h,n,ExecIf($["${FAXOPT(error)}" = "FILE_IO_FAIL"]?System("echo \"** 
Asterisk Fax FILE_IO_FAIL - will reload. Thank you. Asterisk :)\" | mail -s 
\"** Asterisk Fax FILE_IO_FAIL\" **email address was here**"))
; Restart Asterisk if FILE IO FAILURE on fax - indicates instability in fax 
module
; accomplished by cron job that will restart asterisk as root when this file is 
found
exten => h,n,ExecIf($["${FAXOPT(error)}" = "FILE_IO_FAIL"]?System("echo 
\"FAX_IO_FAILURE\" >> /tmp/FAX_IO_FAILURE"))
exten => h,n,Macro(hangupcall,)

; end of [ext-fax]




What am I missing here?  Half the time we don't get back into the
dialplan from the ReceiveFax even though wrapped in TryExec.  Before
wrapping the call in TryExec, I would get a log entry about ReceiveFax
exiting non-zero (after successful fax receipt) and no other log entry
for the call.

This is running on 1.6.2.17 rc3 ... we upgraded because the same thing
was happening with 1.6.2.6.

Any help would be appreciated.

Thanks,

Jay
--
_
-- 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] Assigning an extension to a roaming phone

[Danny Nicholas]

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Axelle
Sent: Monday, February 21, 2011 9:14 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Assigning an extension to a roaming phone

Hi again,

> Ok, so you need a "roaming magic dial" where 4XXX dials the assigned
phone.

Yes.

> Your original command
> - exten => _4XXX,n,Dial(SIP/${ROAM})
> Technically should work, just has no timeouts or control on it.
> The ,30 gives the Dial 30 seconds (about 6 rings) to complete, and mKkTt
> gives the caller music-on-hold until answer/time then lets the dialee
> re-transfer the call.
>
> As I understand what you just wrote, folks come into your shop with a cell
> phone (555-1212) and dial a number 3001 to tell your inhouse folks to
reach
> the cell at 4XXX.  Say "Joe" comes in and dials 3001.  Asterisk should say
> "what is your name".  He says "Joe" and Asterisk says "callers can now
reach
> Joe at 4001".  "Jim" comes in and does the same thing and gets 4002 until
> 999 folks do it.  Is that correct?

Well all I need is:
Joe dials 3001
Asterisk says "Callers can now reach you at 4001"
then, another caller can call 4001 and reach Joe.

But to my understanding, the lines below do something a bit more
complicated:
(please correct if wrong). And unfortunately they do not work in my case...

exten => 3001,1(readop),BackGround(beep)
Joe dials 3001 and gets a beep

exten => 3001,n,Read(digito,vm-youhave,3)
Asterisk says hello (I don't care the actual message, just to know
when I should start dialing) and reads 3 digits from Joe. Let's says
he dials 001.
Actually, this part does not work. Asterisk does not say 'you have'?!

exten => 3001,n,Read(digito,vm-youhave,3)
Asterisk says 001.

exten => 3001,n,Set(ROAM=${digito})
exten => 3001,n,Set(DB(roam/ext)=${digito})
Not very sure what this exactly does, but looks like assigning 001 to
roaming user.

exten => 3001,n,playback(vm-goodbye)
Asterisk says goodbye (works)

exten => 3001,n,hangup
Finish connection.

exten => _4XXX,1,Set(ROAM=${DB(roam/ext)})
Now an end-user dialing 4001. Don't know how this routes to my roaming
user...

exten => _4XXX,n,Dial(SIP/${ROAM},30,,mKkTt)
Dial the roaming user.
Does not work, Asterisk says 4001 is not attributed.

I still cannot reach my roaming user...

-- Axelle

Here goes today's shot at fixing this; 
The _4XXX,n,Dial(SIP/${ROAM}).. line assumes that the line is a defined SIP
extension in your Asterisk PBX.  
Let's say that your shop has 100 phones in it that are defined as 2000-2100.
To reach a "normal" in-house user, you would use this dialplan snippet
Exten => _2XXX,1,Dial(SIP/{$EXTEN},20,m)

If Joe comes in with his cell phone and wants to be called there, dial
SIP(anything) isn't going to connect to him unless you are "bouncing out"
over a SIP provider (DIAL(SIP/5551...@myprovider.com)).  You would most
likely reach him using a DAHDI dial (DIAL(DAHDI/g1/5551212))

So let's say Joe has a cell and we want to call him at 4001.  We use this
line
Exten => 4001,1,Dial(DAHDI/g1/5551212)
Or 
Exten => 4001,1,Dial(SIP/5551...@myprovider.com)

In either of these cases, ${ROAM} is a pseudo extension, not a real
reassignment.  

In another case, the 100 in-house extensions are in sections like Widgets
2000-2033, Gadgets 2034-2066 and Foobar 2067-2100.  Joe moves from section
to section, so we want to locate him in the section.  When Joe is in
Widgets, he dials 3001 and enters 001.  Now we find him in the Widget
section.  He dials 3001 again and enters 034.  Now he's in Gadgets.
Since Joe is at an in-house number, we can use FOLLOWME to put him at any
in-house phone.

Addressing two of your 3001 items:
exten => 3001,n,Read(digito,vm-youhave,3)
Asterisk says hello (I don't care the actual message, just to know
when I should start dialing) and reads 3 digits from Joe. Let's says
he dials 001.
Actually, this part does not work. Asterisk does not say 'you have'?!

exten => 3001,n,SayDigits(${digito})
Asterisk says 001.

I would have coded this like so:
exten => 3001,1,noop(get roam)
exten => 3001,n,playback(enterroamno)
exten => 3001,n,Read(digito,beep,3)
exten => 3001,n,playback(roamsetto)
exten => 3001,n,SayDigits(${digito})
exten => 3001,n,Set(DB(roam/ext)=${digito})

line 2 plays "enter roaming number" (you have to record it)
line 3 plays beep and accepts 3 digits
line 4 plays "you entered " (have to record it)
line 5 plays the 3 digits
line 6 sets a key in ASTDB for what you entered

Part two
exten => _4XXX,1,Set(ROAM=${DB(roam/ext)})
exten => _4XXX,n,Dial(SIP/${ROAM},30,,mKkTt)

line 1 user dials 4001 and gets ${ROAM} set from ASTDB
line 2 attempts to dial SIP extension based on ${ROAM} value.

Hope this helps.


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Th

Re: [asterisk-users] Assigning an extension to a roaming phone

[Axelle]

Hi again,

> Ok, so you need a "roaming magic dial" where 4XXX dials the assigned phone.

Yes.

> Your original command
> - exten => _4XXX,n,Dial(SIP/${ROAM})
> Technically should work, just has no timeouts or control on it.
> The ,30 gives the Dial 30 seconds (about 6 rings) to complete, and mKkTt
> gives the caller music-on-hold until answer/time then lets the dialee
> re-transfer the call.
>
> As I understand what you just wrote, folks come into your shop with a cell
> phone (555-1212) and dial a number 3001 to tell your inhouse folks to reach
> the cell at 4XXX.  Say "Joe" comes in and dials 3001.  Asterisk should say
> "what is your name".  He says "Joe" and Asterisk says "callers can now reach
> Joe at 4001".  "Jim" comes in and does the same thing and gets 4002 until
> 999 folks do it.  Is that correct?

Well all I need is:
Joe dials 3001
Asterisk says "Callers can now reach you at 4001"
then, another caller can call 4001 and reach Joe.

But to my understanding, the lines below do something a bit more complicated:
(please correct if wrong). And unfortunately they do not work in my case...

exten => 3001,1(readop),BackGround(beep)
Joe dials 3001 and gets a beep

exten => 3001,n,Read(digito,vm-youhave,3)
Asterisk says hello (I don't care the actual message, just to know
when I should start dialing) and reads 3 digits from Joe. Let's says
he dials 001.
Actually, this part does not work. Asterisk does not say 'you have'?!

exten => 3001,n,SayDigits(${digito})
Asterisk says 001.

exten => 3001,n,Set(ROAM=${digito})
exten => 3001,n,Set(DB(roam/ext)=${digito})
Not very sure what this exactly does, but looks like assigning 001 to
roaming user.

exten => 3001,n,playback(vm-goodbye)
Asterisk says goodbye (works)

exten => 3001,n,hangup
Finish connection.

exten => _4XXX,1,Set(ROAM=${DB(roam/ext)})
Now an end-user dialing 4001. Don't know how this routes to my roaming user...

exten => _4XXX,n,Dial(SIP/${ROAM},30,,mKkTt)
Dial the roaming user.
Does not work, Asterisk says 4001 is not attributed.

I still cannot reach my roaming user...

-- Axelle

--
_
-- 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] calls are not going thru e1 line

[Albert]

Hi Andrew,

I am using current versions of software, find below versions:

1.) asterisk
voice:~# asterisk -V
Asterisk 1.8.2.3

2.)dahdi

*CLI> dahdi show version
DAHDI Version: 2.4.0 Echo Canceller: MG2

3.) lipri
*CLI> pri show version
libpri version: 1.4.11.5

I've already tried to call over each channel from 1 to 15 (i have only
15B channels)

exten => _X.,n,Dial(DAHDI/1/${EXTEN})
exten => _X.,n,Dial(DAHDI/2/${EXTEN})

exten => _X.,n,Dial(DAHDI/15/${EXTEN})

but everytime i am getting the same DIALSTATUS

-- Channel 0/1, span 1 got hangup request, cause 31
...
-- Auto fallthrough, channel 'SIP/2000-0002' status is 'CHANUNAVAIL'


Regards,
Robert
On 21.02.2011 12:13, Andrew Thomas wrote:
> I'm curious as to what versions of everything you are using.  Reason
> being this line "-- DAHDI/i1/00256312261627-1 is proceeding passing
> it to SIP/5000-".
>
> It states "DAHDI/i1/00256312261627-1..." and I don't recall seeing that
> before (my 2.4.0 says "-- DAHDI/1-1 is proceeding passing it to
> SIP/801-000c" [1-1 being the span and channel numbers]).
>
> What happens if you change "exten => _X.,n,Dial(DAHDI/g1/${EXTEN})" to
> "exten => _X.,n,Dial(DAHDI/1/${EXTEN})"?

--
_
-- 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] DTMF and Snom

[Dan Journo]

> Hello list,

>

> I'm having some troubles with DTMF tones. When pressing numbers on a Snom

> phone, the DTMF-signal takes too long.





I had this problem after upgrading Asterisk. What version of Asterisk are you 
currently using?
Has the Snow worked fine before? Or have you always had the problem?

Dan Journo
Kesher Communications (UK)
Business Phone Systems | Hosted 
PBX


--
_
-- 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] calls are not going thru e1 line

[Andrew Thomas]

I'm curious as to what versions of everything you are using.  Reason
being this line "-- DAHDI/i1/00256312261627-1 is proceeding passing
it to SIP/5000-".

It states "DAHDI/i1/00256312261627-1..." and I don't recall seeing that
before (my 2.4.0 says "-- DAHDI/1-1 is proceeding passing it to
SIP/801-000c" [1-1 being the span and channel numbers]).

What happens if you change "exten => _X.,n,Dial(DAHDI/g1/${EXTEN})" to
"exten => _X.,n,Dial(DAHDI/1/${EXTEN})"?



-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Albert
Sent: 17 February 2011 16:56
To: asterisk-users@lists.digium.com
Subject: Re: [asterisk-users] calls are not going thru e1 line


On 17.02.2011 17:47, Danny Nicholas wrote: 

Post your "dahdi show channels" output.

Have you checked the lines with a regular handset?

here it is:
*CLI> dahdi show status
Description  Alarms  IRQbpviol CRC4
Fra Codi Options  LBO
T2XXP (PCI) Card 0 Span 1OK  0  0  0
CCS HDB3 CRC4 0 db (CSU)/0-133 feet (DSX-1)
T2XXP (PCI) Card 0 Span 2UNCONFI 0  0  0
CAS Unk   0 db (CSU)/0-133 feet (DSX-1)

*CLI> dahdi show channels
   Chan Extension  Context Language   MOH Interpret
BlockedState 
 pseudodefaultdefault
In Service
  1incoming_calls  en default
In Service
  2incoming_calls  en default
In Service
  3incoming_calls  en default
In Service
  4incoming_calls  en default
In Service
  5incoming_calls  en default
In Service
  6incoming_calls  en default
In Service
  7incoming_calls  en default
In Service
  8incoming_calls  en default
In Service
  9incoming_calls  en default
In Service
 10incoming_calls  en default
In Service
 11incoming_calls  en default
In Service
 12incoming_calls  en default
In Service
 13incoming_calls  en default
In Service
 14incoming_calls  en default
In Service
 15incoming_calls  en default
In Service
 17incoming_calls  en default
In Service
 18incoming_calls  en default
In Service
 19incoming_calls  en default
In Service
 20incoming_calls  en default
In Service
 21incoming_calls  en default
In Service
 22incoming_calls  en default
In Service
 23incoming_calls  en default
In Service
 24incoming_calls  en default
In Service
 25incoming_calls  en default
In Service
 26incoming_calls  en default
In Service
 27incoming_calls  en default
In Service
 28incoming_calls  en default
In Service
 29incoming_calls  en default
In Service
 30incoming_calls  en default
In Service
 31incoming_calls  en default
In Service

Yes, is was checked and calls were going through line.

Regards,
Albert


 If you have received this communication in error we would appreciate
you advising us either by telephone or return of e-mail. The contents
of this message, and any attachments, are the property of DataVox,
and are intended for the confidential use of the named recipient only.
If you are not the intended recipient, employee or agent responsible
for delivery of this message to the intended recipient, take note that
any dissemination, distribution or copying of this communication and
its attachments is strictly prohibited, and may be subject to civil or
criminal action for which you may be liable.
Every effort has been made to ensure that this e-mail or any attachments
are free from viruses. While the company has taken every reasonable
precaution to minimise this risk, neither company, nor the sender can
accept liability for any damage which you sustain as a result of viruses.
It is recommended that you should carry out your own virus checks
before opening any attachments. 

Registered in England. No. 27459085.



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