Re: [asterisk-users] Outgoing SIP calls dropped after 30 seconds.

2008-11-08 Thread Kurt Knudsen
Not using the CDR for billing, but I do use it to see usage and to
know if it's cheaper to purchase a provider with unlimited incoming
and pay-per-minute outgoing. I disabled 'SIP Transformation' in the
SonicWall and so far so good (10/10 calls worked, more testing to be
had, stay tuned.)

On Sat, Nov 8, 2008 at 5:12 AM, Steve Totaro
<[EMAIL PROTECTED]> wrote:
> Usually, calls terminating at 30 seconds is a sure sign that you need to add
> an Answer() in your dialplan.  Try dropping that in before you dial out.  I
> have seen this so many times and Answer() has always fixed the issue.  The
> magic number is 30 seconds.
>
> Depending on if you use your CDRs for anything, especially billing, you may
> need to figure a way around that, since even if a call rings out, the CDR
> will reflect Answered.
>
> --
> Thanks,
> Steve Totaro
> +18887771888 (Toll Free)
> +12409381212 (Cell)
> +12024369784 (Skype)
>
>
>
> On Fri, Nov 7, 2008 at 10:38 PM, Grey Man <[EMAIL PROTECTED]> wrote:
>>
>> To get to the bottom of it I'd recommend determining why the ACKs are
>> not getting through to Asterisk rather than trying to work around it.
>> I'm actually suprised Asterisk terminates the call by default when it
>> doesn't get the ACK to it's 200 Ok response that must be new for
>> 1.4.22 as I haven't seen that behaviour in earlier versions. In my
>> opinion it's unwarranted behaviour, if Asterisk is getting RTP then it
>> should leave the call up irrespective of whether it gets an ACK or
>> not.
>>
>> From the original SIP trace the ACK does not appear to be arriving at
>> your Asterisk server at all. Try doing a packet trace on the network
>> segment where the calling SIP agent is and see where it's trying to
>> send the ACK to. My guess would be your firewall is incorrectly
>> handling the SIP messages. Generally it's very bad news to use an ALG
>> or firewall to mangle SIP packets as they almost always get it wrong.
>>
>> In your case there is a Record-Route header in the response so the ACK
>> request should be being sent to that address. Perhaps your firewall is
>> not correctly mangling that to allow the request to find its way back
>> to your Asterisk server.
>>
>> Record-Route: 
>>
>> Regards,
>>
>> Greyman.
>>
>> ___
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> 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 --
>
> 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 --

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


Re: [asterisk-users] Outgoing SIP calls dropped after 30 seconds.

2008-11-07 Thread Kurt Knudsen
That seems to have sort of worked. It seems the phone decided to end
the call this time, instead of Asterisk and now the call is dangling
inside of 'sip show channels'.

So that solution didn't work :(

On Fri, Nov 7, 2008 at 4:28 PM, Kurt Knudsen <[EMAIL PROTECTED]> wrote:
> Ok, recompiling it now with a 1 instead of XMIT_CRITICAL. Will check
> back to see if it worked. Would be nice if it did :)
>
> Thanks,
>
> Kurt
>
> On Fri, Nov 7, 2008 at 3:38 PM, Doug <[EMAIL PROTECTED]> wrote:
>> At 14:15 11/7/2008, SIP wrote:
>>  >Kurt Knudsen wrote:
>>  >> Specs: Asterisk 1.4.22 running behind a SonicWall (transparent mode)
>>  >> with a public IP address. We have our phone system setup as 172.16.2.x
>>  >> that connect through the SonicWall to Asterisk. Incoming calls work
>>  >> flawlessly and we no longer get one-way audio. We are only using SIP
>>  >> (3 trunks now, instead of 2) and having all 3 in use is not an issue.
>>
>>
>>
>>  >> Question: Why does it sometimes work and sometimes not? This makes no
>>  >> sense and it happens on all phones. Any suggestions?
>>  >>
>>  >>
>>  >>
>>  >
>>  >
>>  >We see this on occasion. It sounds a lot like Asterisk doing its usual
>>  >routine of deciding that you can't POSSIBLY have a call going through
>>  >because it can't receive an ACK response properly.  Asterisk tries
>>  >several times to send an ACK and get a response. If the remote system
>>  >routes ACKs differently than it routes everything else, often times
>>  >those ACKs get lost, and Asterisk assumes that the call can't be
>>  >working, so it destroys it.
>>  >
>>  >ACK handling is a bit tricky in the real world, and we've run across
>>  >countless incorrectly-configured SIP servers that don't handle it
>>  >properly, so calls to them last just about exactly 30 seconds and then
>>  >drop.
>>  >
>>  >There is, unfortunately, no way to turn off Asterisk's 'intelligent'
>>  >behaviour in this scenario short of possibly patching the code.
>>
>> http://lists.digium.com/pipermail/asterisk-users/2007-May/187951.html
>>
>>
>> ___
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> 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 --

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


Re: [asterisk-users] Outgoing SIP calls dropped after 30 seconds.

2008-11-07 Thread Kurt Knudsen
Ok, recompiling it now with a 1 instead of XMIT_CRITICAL. Will check
back to see if it worked. Would be nice if it did :)

Thanks,

Kurt

On Fri, Nov 7, 2008 at 3:38 PM, Doug <[EMAIL PROTECTED]> wrote:
> At 14:15 11/7/2008, SIP wrote:
>  >Kurt Knudsen wrote:
>  >> Specs: Asterisk 1.4.22 running behind a SonicWall (transparent mode)
>  >> with a public IP address. We have our phone system setup as 172.16.2.x
>  >> that connect through the SonicWall to Asterisk. Incoming calls work
>  >> flawlessly and we no longer get one-way audio. We are only using SIP
>  >> (3 trunks now, instead of 2) and having all 3 in use is not an issue.
>
>
>
>  >> Question: Why does it sometimes work and sometimes not? This makes no
>  >> sense and it happens on all phones. Any suggestions?
>  >>
>  >>
>  >>
>  >
>  >
>  >We see this on occasion. It sounds a lot like Asterisk doing its usual
>  >routine of deciding that you can't POSSIBLY have a call going through
>  >because it can't receive an ACK response properly.  Asterisk tries
>  >several times to send an ACK and get a response. If the remote system
>  >routes ACKs differently than it routes everything else, often times
>  >those ACKs get lost, and Asterisk assumes that the call can't be
>  >working, so it destroys it.
>  >
>  >ACK handling is a bit tricky in the real world, and we've run across
>  >countless incorrectly-configured SIP servers that don't handle it
>  >properly, so calls to them last just about exactly 30 seconds and then
>  >drop.
>  >
>  >There is, unfortunately, no way to turn off Asterisk's 'intelligent'
>  >behaviour in this scenario short of possibly patching the code.
>
> http://lists.digium.com/pipermail/asterisk-users/2007-May/187951.html
>
>
> ___
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> 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 --

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


[asterisk-users] Outgoing SIP calls dropped after 30 seconds.

2008-11-07 Thread Kurt Knudsen
Specs: Asterisk 1.4.22 running behind a SonicWall (transparent mode)
with a public IP address. We have our phone system setup as 172.16.2.x
that connect through the SonicWall to Asterisk. Incoming calls work
flawlessly and we no longer get one-way audio. We are only using SIP
(3 trunks now, instead of 2) and having all 3 in use is not an issue.

Problem: Make a call on a Polycom 320 IP phone to any number and (4/5
times) it will drop the call after 30 seconds. I noticed that the
little timer that pops up on the LCD on the phone is missing when a
call will be dropped. This timer appears when the phone is answered,
so I have about 30 seconds to talk to them before the call is just
dropped.

Known Causes: It's a NAT issue, I know that much, I just don't know
how to fix it. SIP debugging shows that it attempts to retransmit
packets to my phone and since it can't, it drops it after 30 seconds.

Log snippet:
-- Executing [EMAIL PROTECTED]:19] Dial("SIP/203-b7a2b558",
"SIP/bw_outbound/+18005551212|300|") in new stack
Audio is at  port 11968
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 216.82.224.202:5060:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP :5060;branch=z9hG4bK6ea30a1a;rport
From: "8881231234" ;tag=as3ed791f3
To: 
Contact: 
Call-ID: [EMAIL PROTECTED] IP
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 07 Nov 2008 19:06:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 291

v=0
o=root 21520 21520 IN IP4 151.196.61.115
s=session
c=IN IP4 
t=0 0
m=audio 11968 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

-- Called bw_outbound/+18885551212
FreePBX*CLI>
<--- SIP read from 216.82.224.202:5060 --->
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP public IP:5060;branch=z9hG4bK6ea30a1a;rport=5060
From: "8881231234" ;tag=as3ed791f3
To: 
Call-ID: [EMAIL PROTECTED] IP
CSeq: 102 INVITE
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0

<->
--- (8 headers 0 lines) ---
FreePBX*CLI>
<--- SIP read from 216.82.224.202:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP public IP:5060;branch=z9hG4bK6ea30a1a;rport=5060
Record-Route: 
From: "8881231234" ;tag=as3ed791f3
To: ;tag=VPST50603522629853
Call-ID: [EMAIL PROTECTED] IP
CSeq: 102 INVITE
Contact: 
Content-Type: application/sdp
Content-Length: 184

v=0
o=- 1226084867 1226084868 IN IP4 209.244.42.253
s=-
c=IN IP4 209.244.42.253
t=0 0
m=audio 64706 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

<->
--- (10 headers 9 lines) ---
Found RTP audio format 0
Found RTP audio format 101
Peer audio RTP is at port 209.244.42.253:64706
Found audio description format telephone-event for ID 101
Got unsupported a:fmtp in SDP offer
Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x4
(ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1
(telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 209.244.42.253:64706
-- SIP/bw_outbound-08bf43d0 is making progress passing it to
SIP/203-b7a2b558
Audio is at public IP port 16244
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Transmitting (NAT) to 172.16.2.203:5060 --->
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
172.16.2.203;branch=z9hG4bKed293df65EAFD78F;received=172.16.2.203
From: "Me" ;tag=28354B-27A53F00
To: ;tag=as600b952c
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: 
Content-Type: application/sdp
Content-Length: 291

v=0
o=root 21520 21520 IN IP4 public IP
s=session
c=IN IP4 public IP
t=0 0
m=audio 16244 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv


<->
--- (10 headers 9 lines) ---
Found RTP audio format 0
Found RTP audio format 101
Peer audio RTP is at port 209.244.42.253:64706
Found audio description format telephone-event for ID 101
Got unsupported a:fmtp in SDP offer
Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x4
(ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1
(telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 209.244.42.253:64706
list_route: hop: 
set_destination: Parsing  for
address/port to send to
set_destination: set destination to 216.82.224.202, port 5060
Transmitting (no NAT) to 216.82.224.202:5060:
ACK sip:[EMAIL PROTECTED]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP public IP:5060;branch=z9h

[asterisk-users] No incoming audio on Dahdi channels (TDM410P)

2008-10-26 Thread Kurt Knudsen
A previous issue has popped up and once again I'm out of ideas. During
the evenings it seems that the TDM channels will spike (dahdi_monitor)
and will refuse to listen for audio of any type, this includes DTMF.
The only resolution I know of is to stop Asterisk and restart the
dahdi service, but that's not a solution.

All channels look like this, even the FXS.

[EMAIL PROTECTED] Hardware]# dahdi_monitor 1 -vv

Visual Audio Levels.

 Use chan_dahdi.conf file to adjust the gains if needed.

( # = Audio Level  * = Max Audio Hit )
<(RX <(TX
 ###*
Rx: 30076 (30076) Tx: 0 (0)

I've stopped every service except SSH and networking (according to
service --status-all) and nothing has changed.

[EMAIL PROTECTED] cat /proc/interrupts
   CPU0
  0:   77924086IO-APIC-edge  timer
  1:  3IO-APIC-edge  i8042
  6:  6IO-APIC-edge  floppy
  7:  0IO-APIC-edge  parport0
  8:  1IO-APIC-edge  rtc
  9:  1   IO-APIC-level  acpi
 12:  4IO-APIC-edge  i8042
 14: 104093IO-APIC-edge  ide0
 15: 690398IO-APIC-edge  ide1
201:   77835719   IO-APIC-level  wctdm24xxp0
209: 770795   IO-APIC-level  eth1
NMI:  0
LOC:   77927794
ERR:  0
MIS:  0

Nothing looks shared, but then I see this in lspci -vb:
00:02.0 VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)
(prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. Unknown device 5578
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at d000 (32-bit, prefetchable)
Memory at dff8 (32-bit, non-prefetchable)
Capabilities: [d0] Power Management version 1
...
...
01:01.0 Ethernet controller: Digium, Inc. Unknown device 8005 (rev 11)
Subsystem: Digium, Inc. Unknown device 8005
Flags: bus master, medium devsel, latency 32, IRQ 11
I/O ports at cc00
Memory at dfdffc00 (32-bit, non-prefetchable)
Expansion ROM at dfdc [disabled]
Capabilities: [c0] Power Management version 2

Is that normal? Here's the output of dahdi_diag 1:
dahdi: Dump of DAHDI Channel 1 (WCTDM/0/0,1,1):

dahdi: flags: 201 hex, writechunk: ee0d008c, readchunk: ee0d0098
dahdi: rxgain: f8b8c480, txgain: f8b8c480, gainalloc: 0
dahdi: span: e9460054, sig: 2004 hex, sigcap: 6085 hex
dahdi: inreadbuf: -1, outreadbuf: -1, inwritebuf: -1, outwritebuf: -1
dahdi: blocksize: 0, numbufs: 2, txbufpolicy: 0, txbufpolicy: 0
dahdi: txdisable: 0, rxdisable: 0, iomask: 0
dahdi: curzone: , tonezone: 0, curtone: , tonep: 0
dahdi: digitmode: 0, txdialbuf: , dialing: 0, aftdialtimer: 0, cadpos. 0
dahdi: confna: 0, confn: 0, confmode: 0, confmute: 0
dahdi: ec: , echocancel: 0, deflaw: 0, xlaw: f8b6f2a0
dahdi: echostate: 00, echotimer: 0, echolastupdate: 0
dahdi: itimer: 0, otimer: 0, ringdebtimer: 0

No idea what any of that means or how it's relevant.

dmesg is full of interrupt misses and polarity reversals:
...
wctdm24xxp0: Missed interrupt. Increasing latency to 18 ms in order to
compensate.
wctdm24xxp0: Missed interrupt. Increasing latency to 19 ms in order to
compensate.
29794979 Polarity reversed (1 -> -1)
29795839 Polarity reversed (-1 -> 1)
wctdm24xxp0: Missed interrupt. Increasing latency to 20 ms in order to
compensate.
wctdm24xxp0: Missed interrupt. Increasing latency to 21 ms in order to
compensate.
wctdm24xxp0: Missed interrupt. Increasing latency to 22 ms in order to
compensate.
31595924 Polarity reversed (1 -> -1)
31596867 Polarity reversed (-1 -> 1)
...
RING on 1/2!
74920374 Polarity reversed (-1 -> 1)
NO RING on 1/2!
74921961 Polarity reversed (1 -> -1)
RING on 1/2!
NO RING on 1/2!
NO BATTERY on 1/2!
BATTERY on 1/2 (-)!

Running AsteriskNow 1.5. X Windows is disabled. Ideas? Suggestions?
Thoughts? Going to build another PC and toss this in there to see what
happens tonight.

Thanks.

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

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


[asterisk-users] TDM410P with EC doesn't detect DTMF after being on for ~1 hour

2008-10-20 Thread Kurt Knudsen
Now that I have a new card and my echo problems are 'mostly' solved, I
have another major issue to deal with. After about an hour or so the
card will stop detecting DTMF tones on incoming calls. dahdi_monitor
shows the following:

[EMAIL PROTECTED] wctdm24xxp]# dahdi_monitor 1 -v

Visual Audio Levels.

 Use chan_dahdi.conf file to adjust the gains if needed.

( # = Audio Level  * = Max Audio Hit )
<(RX <(TX
 ###*

The channel is spiked and I need to stop asterisk and restart dahdi.
Here's what the full log shows when it sees an incoming call:
[Oct 20 18:49:38] VERBOSE[10629] logger.c: -- Starting simple
switch on 'DAHDI/1-1'
[Oct 20 18:49:39] NOTICE[10629] chan_dahdi.c: Got event 17 (Polarity
Reversal)...
[Oct 20 18:49:42] NOTICE[10629] chan_dahdi.c: Got event 18 (Ring Begin)...
[Oct 20 18:49:44] NOTICE[10629] chan_dahdi.c: Got event 2 (Ring/Answered)...
[Oct 20 18:49:44] VERBOSE[10629] logger.c: -- Executing
[EMAIL PROTECTED]:1] ExecIf("DAHDI/1-1", "1|SetCallerPres|unavailable")
in new stack
[Oct 20 18:49:44] VERBOSE[10629] logger.c: -- Executing
[EMAIL PROTECTED]:2] ExecIf("DAHDI/1-1", "1|Set|CALLERID(all)=unknown
<000>") in new stack

The 3 events are always there when DTMF is ignored/not detected.
Here's what the log shows with a correct call:
[Oct 20 18:37:16] DEBUG[10563] dsp.c: dsp busy pattern set to 500,500
[Oct 20 18:37:16] VERBOSE[10611] logger.c: -- Starting simple
switch on 'DAHDI/1-1'
[Oct 20 18:37:17] VERBOSE[10611] logger.c: -- Executing
[EMAIL PROTECTED]:1] ExecIf("DAHDI/1-1", "0|SetCallerPres|unavailable")
in new stack
[Oct 20 18:37:17] VERBOSE[10611] logger.c: -- Executing
[EMAIL PROTECTED]:2] ExecIf("DAHDI/1-1", "0|Set|CALLERID(all)=unknown
<000>") in new stack
[Oct 20 18:37:17] VERBOSE[10611] logger.c: -- Executing
[EMAIL PROTECTED]:3] Goto("DAHDI/1-1", "voicemenu-custom-3|s|1") in new
stack
[Oct 20 18:37:17] VERBOSE[10611] logger.c: -- Goto (voicemenu-custom-3,s,1)
[Oct 20 18:37:17] VERBOSE[10611] logger.c: -- Executing
[EMAIL PROTECTED]:2] Wait("DAHDI/1-1", "2") in new stack
[Oct 20 18:37:17] DEBUG[10611] chan_dahdi.c: Ignore switch to REVERSED
Polarity on channel 1, state 4
[Oct 20 18:37:17] DEBUG[10611] chan_dahdi.c: Ignoring Polarity switch
to IDLE on channel 1, state 4
[Oct 20 18:37:17] DEBUG[10611] chan_dahdi.c: Polarity Reversal event
occured - DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0,
pdelay= 600, tv= 47$
[Oct 20 18:37:19] VERBOSE[10611] logger.c: -- Executing
[EMAIL PROTECTED]:3] Set("DAHDI/1-1", "TIMEOUT(digit)=2") in new
stack
[Oct 20 18:37:19] VERBOSE[10611] logger.c: -- Digit timeout set to 2

The events are ignored and the call goes through as it should. Also,
when the call FAILS, the caller ID does not work. Here's the last bit
of dmesg:

NO BATTERY on 1/1!
BATTERY on 1/1 (+)!
26939263 Polarity reversed (1 -> -1)
NO BATTERY on 1/1!
26940073 Polarity reversed (-1 -> 1)
BATTERY on 1/1 (+)!
RING on 1/1!
26984808 Polarity reversed (1 -> -1)
NO RING on 1/1!
26986380 Polarity reversed (-1 -> 1)
NO BATTERY on 1/1!
BATTERY on 1/1 (+)!

I have no idea what that means (module is running with debug=1). Any ideas?

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

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


Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-20 Thread Kurt Knudsen
Well, when it fails over to the Dahdi trunk, it doesn't dial properly,
so I think I broke the macro. I will add the Set(GROUP()) stuff inside
of that macro-trunkdial-0.3 context and see if that helps. But it's
weird that I can't dial out. Here's a bit of the full log:

DEBUG[8221] app_macro.c: Executed application: Dial
VERBOSE[8221] logger.c: -- Executing
[EMAIL PROTECTED]:2] GotoIf("SIP/207-0a1b3590", "20
> 0 1-CONGESTION|1:1-out|1") in new stack
VERBOSE[8221] logger.c: -- Goto
(macro-trunkdial-failover-0.3,1-CONGESTION,1)
DEBUG[8221] app_macro.c: Executed application: Gotoif
VERBOSE[8221] logger.c: -- Executing
[EMAIL PROTECTED]:1] Dial("SIP/207-0a1b3590",
"Dahdi/g1/18005551212") in new stack
DEBUG[8221] dsp.c: dsp busy pattern set to 500,500
DEBUG[8221] chan_dahdi.c: Dialing '18005551212'
DEBUG[8221] chan_dahdi.c: Deferring dialing...
VERBOSE[8221] logger.c: -- Called g1/18005551212
DEBUG[8221] chan_dahdi.c: Sent deferred digit string: T18005551212w
DEBUG[8221] chan_dahdi.c: Done dialing, but waiting for progress
detection before doing more...
VERBOSE[8221] logger.c: -- Hungup 'DAHDI/1-1'

Not sure how it broke, but it won't use the Dahdi channel :( It just
goes to a busy signal after you dial. I tested on an analog phone and
it can dial out normally, so it's the system.

Thanks.

On Mon, Oct 20, 2008 at 2:29 PM, Jeremy Mann <[EMAIL PROTECTED]> wrote:
> I have a macro to dial out, similar to yours in that it fails over to 
> Zap/Dahdi trunks in the event our bandwidth stuff is overloaded.
>
> I run this in a macro, and only set and check groups within that macro.  I'm 
> confused why yours would attach to "phones" in any way, unless you mean phone 
> to phone calls, in that case don't set the group?
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Knudsen
> Sent: Monday, October 20, 2008 1:17 PM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent 
> one-way audio
>
> The GotoIf works, because it does failover sometimes, just not all the
> time, I followed instructions from here:
>
> http://www.voip-info.org/wiki-Asterisk+cmd+GotoIf
>
> And it seems to work in other areas that I use it in a similar way. I
> only have the Set(GROUP()) when we are making outgoing calls on the
> SIP trunk or when there's an incoming call on the SIP trunk. Anything
> on Dahdi doesn't get included. I don't know how to tell my phones and
> channels apart, I'm not trying to add the phones to the group, just
> the channels. Can you paste some of your extensions.conf since you
> also use Bandwidth.com?
>
> Thanks.
>
> On Mon, Oct 20, 2008 at 8:30 PM,  <[EMAIL PROTECTED]> wrote:
>> -- Kurt Knudsen wrote :
>> Hello,
>>
>>
>>
>> We have 2 SIP trunks from Bandwidth.com and if both are in use and someone
>> tries to dial out, they cause another call to get one-way audio (the caller
>> hears us, we cannot hear them). This happens 100% of the time and
>> Bandwidth.com doesn't offer any support. I don't see any setting that tells
>> Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
>> currently using, or attempting to use, groups to solve this problem, but
>> sometimes it works, sometimes it doesn't. It breaks when a call goes out on
>> a Queue, because it seems to add each phone to the group, which breaks my
>> GotoIf() statement. Here's some relevant information:
>>
>>
>>
>> Users.conf (added by Asterisk-GUI)
>>
>> [trunk_2]
>>
>> provider = Bandwidth (SIP)  ; GUI metadata
>>
>> context = DID_trunk_2
>>
>> hasexten = no
>>
>> hasiax = no
>>
>> hassip = yes
>>
>> host = 216.82.224.202
>>
>> registeriax = no
>>
>> registersip = no
>>
>> usecallerid = yes
>>
>> nat = no ;Testing
>>
>> trunkname = Bandwidth.com (Sip)  ; GUI metadata
>>
>> username =
>>
>> secret =
>>
>> disallow = all
>>
>> allow = ulaw,alaw,g726
>>
>>
>>
>> sip.conf
>>
>> [general]
>>
>> context = frombandwidth
>>
>> ;other variables, etc.
>>
>>
>>
>> ;Added according to Bandwidth.com's wiki entry. Changed to inband because we
>> were having DTMF issues.
>>
>> [bandwidth.com_inbound]
>>
>> host=216.82.224.202
>>
>> port=5060
>>
>> type=peer
>>
>> disallow=all
>>
>> allo

Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-20 Thread Kurt Knudsen
The GotoIf works, because it does failover sometimes, just not all the
time, I followed instructions from here:

http://www.voip-info.org/wiki-Asterisk+cmd+GotoIf

And it seems to work in other areas that I use it in a similar way. I
only have the Set(GROUP()) when we are making outgoing calls on the
SIP trunk or when there's an incoming call on the SIP trunk. Anything
on Dahdi doesn't get included. I don't know how to tell my phones and
channels apart, I'm not trying to add the phones to the group, just
the channels. Can you paste some of your extensions.conf since you
also use Bandwidth.com?

Thanks.

On Mon, Oct 20, 2008 at 8:30 PM,  <[EMAIL PROTECTED]> wrote:
> -- Kurt Knudsen wrote :
> Hello,
>
>
>
> We have 2 SIP trunks from Bandwidth.com and if both are in use and someone
> tries to dial out, they cause another call to get one-way audio (the caller
> hears us, we cannot hear them). This happens 100% of the time and
> Bandwidth.com doesn't offer any support. I don't see any setting that tells
> Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
> currently using, or attempting to use, groups to solve this problem, but
> sometimes it works, sometimes it doesn't. It breaks when a call goes out on
> a Queue, because it seems to add each phone to the group, which breaks my
> GotoIf() statement. Here's some relevant information:
>
>
>
> Users.conf (added by Asterisk-GUI)
>
> [trunk_2]
>
> provider = Bandwidth (SIP)  ; GUI metadata
>
> context = DID_trunk_2
>
> hasexten = no
>
> hasiax = no
>
> hassip = yes
>
> host = 216.82.224.202
>
> registeriax = no
>
> registersip = no
>
> usecallerid = yes
>
> nat = no ;Testing
>
> trunkname = Bandwidth.com (Sip)  ; GUI metadata
>
> username =
>
> secret =
>
> disallow = all
>
> allow = ulaw,alaw,g726
>
>
>
> sip.conf
>
> [general]
>
> context = frombandwidth
>
> ;other variables, etc.
>
>
>
> ;Added according to Bandwidth.com's wiki entry. Changed to inband because we
> were having DTMF issues.
>
> [bandwidth.com_inbound]
>
> host=216.82.224.202
>
> port=5060
>
> type=peer
>
> disallow=all
>
> allow=ulaw
>
> dtmfmode=inband
>
> canreinvite=no
>
> reinvite=no
>
> context=frombandwidth
>
> nat=no
>
>
>
> [bandwidth.com_outbound]
>
> host=216.82.224.202
>
> port=5060
>
> type=peer
>
> disallow=all
>
> allow=ulaw
>
> dtmfmode=rfc2833
>
> nat=no
>
> fromuser=11234567890
>
>
>
> extensions.conf
>
> [globals]
>
> ;…irrelevant stuff
>
> trunk_1 = Dahdi/g1
>
> trunk_2 = SIP/trunk_2
>
> OUT_2 = SIP/bandwidth.com_outbound
>
>
>
> ;Took out the Set(GROUP()) because I moved it elsewhere to try and fix it
> added all the phones when Asterisk calls agents on a Queue.
>
> [frombandwidth]
>
> ;exten = _+1.,1,Set(GROUP()=SIPGROUP)
>
> exten = _+1.,1,NoOp(FromCount=${GROUP_COUNT(SIPGROUP)})
>
> exten = _+1.,n,Set(DID=${EXTEN:2})
>
> exten = _+1.,n,Set(CALLERID(num)=${CALLERID(num):2})
>
> exten = _+1.,n,Goto(DID_trunk_2,${DID},1)
>
>
>
> ;What we use to dialout. Try SIP trunks first, then Dahdi trunk as backup.
>
> ;This is where it breaks. I tried to make it so there can't be more than 2
> calls on SIP channels at once.
>
> ;Since it counts the phone as a channel, and adds it to the group, I had to
> use 4.
>
> [internalphones]
>
> exten = _1NXXNXX,1,Set(GROUP()=SIPGROUP)
>
> exten = _1NXXNXX,n,GotoIf($[${GROUP_COUNT(SIPGROUP)} >= 4]?100)  ;If the
> group has 2 or more calls, do not dial.
>
> exten = _1NXXNXX,n,NoOp(1NCount = ${GROUP_COUNT(SIPGROUP)})
>
> exten =
> _1NXXNXX,n,Macro(trunkdial-failover-0.3,${trunk_2}/+${EXTEN:0},${trunk_1}/${EXTEN:0},trunk_1,trunk_2)
>
> exten = _1NXXNXX,100,Playback(all-circuits-busy-now)
>
> exten = _1NXXNXX,101,congestion()
>
> exten = _1NXXNXX,102,busy()
>
>
>
> ;This is where incoming calls go to if I'm awake.
>
> [DID_trunk_2_timeinterval_Awake]
>
> exten = _NXXNXX,1,Set(GROUP()=SIPGROUP)
>
> exten = _NXXNXX,n,NoOp(Open Count=${GROUP_COUNT(SIPGROUP)})
>
> exten = _NXXNXX,n,Set(CALLERID(num)=1${CALLERID(num)})
>
> exten = _NXXNXX,n,Goto(voicemenu-custom-1|s|1)
>
>
>
> Thanks.
>
> --
> This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com
> http://www.opensubscriber.com/message/asterisk-users@lists.digium.com/10416933.html
>

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

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


Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-20 Thread Kurt Knudsen
I tried using GROUP(), here's a snippet from the first post.

;Took out the Set(GROUP()) because I moved it elsewhere to try and fix
it added all the phones when Asterisk calls agents on a Queue.
[frombandwidth]
;exten = _+1.,1,Set(GROUP()=SIPGROUP)
exten = _+1.,1,NoOp(FromCount=${GROUP_COUNT(SIPGROUP)})
exten = _+1.,n,Set(DID=${EXTEN:2})
exten = _+1.,n,Set(CALLERID(num)=${CALLERID(num):2})
exten = _+1.,n,Goto(DID_trunk_2,${DID},1)

;What we use to dialout. Try SIP trunks first, then Dahdi trunk as backup.
;This is where it breaks. I tried to make it so there can't be more
than 2 calls on SIP channels at once.
;Since it counts the phone as a channel, and adds it to the group, I
had to use 4.
[internalphones]
exten = _1NXXNXX,1,Set(GROUP()=SIPGROUP)
exten = _1NXXNXX,n,GotoIf($[${GROUP_COUNT(SIPGROUP)} >= 4]?100)
;If the group has 2 or more calls, do not dial.
exten = _1NXXNXX,n,NoOp(1NCount = ${GROUP_COUNT(SIPGROUP)})
exten = 
_1NXXNXX,n,Macro(trunkdial-failover-0.3,${trunk_2}/+${EXTEN:0},${trunk_1}/${EXTEN:0},trunk_1,trunk_2)
exten = _1NXXNXX,100,Playback(all-circuits-busy-now)
exten = _1NXXNXX,101,congestion()
exten = _1NXXNXX,102,busy()

;This is where incoming calls go to if I'm awake.
[DID_trunk_2_timeinterval_Awake]
exten = _NXXNXX,1,Set(GROUP()=SIPGROUP)
exten = _NXXNXX,n,NoOp(Open Count=${GROUP_COUNT(SIPGROUP)})
exten = _NXXNXX,n,Set(CALLERID(num)=1${CALLERID(num)})
exten = _NXXNXX,n,Goto(voicemenu-custom-1|s|1)

I'll try playing around with incoming/outgoing and see if that makes a
difference. I don't know why it counts the phone as a channel, though.

On Mon, Oct 20, 2008 at 12:14 PM, Jeremy Mann <[EMAIL PROTECTED]> wrote:
>
> Tried using GROUP()?
>
>
>
> When a call comes in or goes out:
>
>
>
> Exten => XXX,1,Set(GROUP(bdwi_out_1)=outgoing/incoming);
>
> Exten => XXX,n,GotoIf($[${GROUP_COUNT(outgoing/[EMAIL PROTECTED])}] > 1?fail)
>
> Exten => XXX,n,Dial(…)
>
> Exten => XXX(fail),1,Congestion();
>
> Exten => XXX(fail),n,Hangup();
>
>
>
> Obviously choose outgoing or incoming, if you want to track both you can just 
> use $MATH() to add them together.
>
>
>
> Or some other math logic to check the result.
>
>
>
> On incoming Set(DIALSTATUS=CHANUNAVAIL) and it'll ring busy to bandwidth(or 
> out of service, you can tweak this).
>
>
>
>
>
>
>
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Knudsen
> Sent: Monday, October 20, 2008 10:46 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent 
> one-way audio
>
>
>
> Any updates? It still seems to happen, though not as often as it used to. 
> We're using Polycom 320 phones, if that makes a difference, though we did do 
> it with X-Lite as well.
>
> On Sat, Oct 11, 2008 at 3:03 PM, Kurt Knudsen <[EMAIL PROTECTED]> wrote:
>
> Thanks, Steve,
>
> That's what I am unsure of. I don't know how to limit 1 call per trunk. If 
> that's an easy thing to setup, I'd love to see it.
>
> On Fri, Oct 10, 2008 at 10:20 PM, Steve Totaro <[EMAIL PROTECTED]> wrote:
>
> Oh, I thought you had logic to count the calls on the trunk.  You should 
> limit each trunk to one call.  This is the primary reason besides the email 
> that basically said that customer support structure has been changed and 
> anything beyond the Demarc would not be supported, I the Demarc is simply 
> their boxen, so unless it is on their side, you will not get any helpful 
> support from Bandwidth, plus they CCed over 500 people by address instead of 
> setting up a group.  
> http://www.bandwidth.com/content/support/?page=standardSupport
>
> I am with Junction and while a trunk is not "unlimited" as far as price for 
> usage, the amount of trunks is unlimited (or at least as unlimited as it can 
> be since nothing is really unlimited).  They asked that I try not to go over 
> one call per second for any real duration, and that I not hammer one LATA do 
> to limited interconnects.
>
> The other thing was Junctions was very easy to sign up with, great support, 
> and configuration was a breeze.
>
> As for Bandwidth, I think they are solid but due to recent changes and the 
> fact that you must pay per channel, as well as the setup process, I decided 
> they were not for me.
>
> I will take a second look at your sip.conf and extensions.conf later to see 
> if something jumps out at me.  I suspect since you are setting up two 
> separate trunks with Bandwidth, you need to limit each trunk to one call, 
> rather than two.
>
> Thanks,
> Steve Totaro
>
>
> On Fri, Oct 10, 2008

Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-20 Thread Kurt Knudsen
Any updates? It still seems to happen, though not as often as it used to.
We're using Polycom 320 phones, if that makes a difference, though we did do
it with X-Lite as well.

On Sat, Oct 11, 2008 at 3:03 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:

> Thanks, Steve,
>
> That's what I am unsure of. I don't know how to limit 1 call per trunk. If
> that's an easy thing to setup, I'd love to see it.
>
> On Fri, Oct 10, 2008 at 10:20 PM, Steve Totaro <
> [EMAIL PROTECTED]> wrote:
>
>> Oh, I thought you had logic to count the calls on the trunk.  You should
>> limit each trunk to one call.  This is the primary reason besides the email
>> that basically said that customer support structure has been changed and
>> anything beyond the Demarc would not be supported, I the Demarc is simply
>> their boxen, so unless it is on their side, you will not get any helpful
>> support from Bandwidth, plus they CCed over 500 people by address instead of
>> setting up a group.
>> http://www.bandwidth.com/content/support/?page=standardSupport
>>
>> I am with Junction and while a trunk is not "unlimited" as far as price
>> for usage, the amount of trunks is unlimited (or at least as unlimited as it
>> can be since nothing is really unlimited).  They asked that I try not to go
>> over one call per second for any real duration, and that I not hammer one
>> LATA do to limited interconnects.
>>
>> The other thing was Junctions was very easy to sign up with, great
>> support, and configuration was a breeze.
>>
>> As for Bandwidth, I think they are solid but due to recent changes and the
>> fact that you must pay per channel, as well as the setup process, I decided
>> they were not for me.
>>
>> I will take a second look at your sip.conf and extensions.conf later to
>> see if something jumps out at me.  I suspect since you are setting up two
>> separate trunks with Bandwidth, you need to limit each trunk to one call,
>> rather than two.
>>
>> Thanks,
>> Steve Totaro
>>
>>
>>
>>
>> On Fri, Oct 10, 2008 at 9:47 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>>
>>> externip messes up DTMF detection, and by messes up I mean it doesn't
>>> detect it at all. Setting nat=yes or nat=no didn't make a difference either.
>>>
>>> When the trunks are in use, the calls are fine, no dropped audio. It only
>>> happens when a 3rd call is made and there's no trunk available.
>>>
>>> Thanks :)
>>>
>>>
>>> On Fri, Oct 10, 2008 at 7:09 PM, Steve Totaro <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>>> You need to configure your box for nat settings, externip and other
>>>> settings in sip.conf and set nat=yes instead of nat=no.
>>>>
>>>> One way audio is almost always a NAT issue and those are two glaring
>>>> things that would cause problems.
>>>>
>>>> Thanks,
>>>> Steve Totaro
>>>>
>>>>
>>>> On Fri, Oct 10, 2008 at 6:32 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> It's behind a NAT/Firewall but SIP translation is enabled and removing
>>>>> it from behind the firewall did nothing, it still dropped calls. The calls
>>>>> connect and everything works, but it dies when all trunks are in use and
>>>>> someone else tries to call out. It seems like even though both channels 
>>>>> are
>>>>> in use, it tries to connect to the 2nd trunk and thus kills the audio.
>>>>> Nothing strange came up in Wireshark or the firewall logs.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Fri, Oct 10, 2008 at 5:40 PM, Steve Totaro <
>>>>> [EMAIL PROTECTED]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 10, 2008 at 5:17 PM, Kurt Knudsen <[EMAIL PROTECTED]
>>>>>> > wrote:
>>>>>>
>>>>>>>  Hello,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We have 2 SIP trunks from Bandwidth.com and if both are in use and
>>>>>>> someone tries to dial out, they cause another call to get one-way audio 
>>>>>>> (the
>>>>>>> caller hears us, we cannot hear them). This happens 100% of the time and
>>>>>>> Bandwidth.com doesn't offer any sup

Re: [asterisk-users] Text messaging and Asterisk

2008-10-13 Thread Kurt Knudsen
I use the 'generic' file in Postfix to map an email address that is not in
use to someone's text messaging address. It'd be [EMAIL PROTECTED]
ie: [EMAIL PROTECTED] Then, any email that gets sent to
[EMAIL PROTECTED], will get automatically sent to that person's phone.

On Mon, Oct 13, 2008 at 3:14 PM, Eric Chamberlain <[EMAIL PROTECTED]> wrote:

>
> On Oct 13, 2008, at 11:28 AM, C. Savinovich wrote:
>
> >
> >  I mean is if someone know of an sms server or service that allows
> > me to
> > send outgoing text messaging.
> >
>
> Are you sending SMS to known users or to any mobile phone user?
>
> If you are sending to a fixed user base, track down the email to SMS
> gateways for their carriers.  Then sending an SMS is no different than
> sending an e-mail.
>
> --
> Eric Chamberlain, Founder
> RF.com - http://RF.com/
>
>
>
>
>
>
>
>
> ___
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> 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 --

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

[asterisk-users] Unknown call every 30 minutes on the dot.

2008-10-13 Thread Kurt Knudsen
Here's some freaky stuff coming from Areski CDR tool:

101.  2008-10-13 03:41:23 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:20

 102.  2008-10-13 03:11:30 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 103.  2008-10-13 02:41:23 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 104.  2008-10-13 02:11:22 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 105.  2008-10-13 01:41:21 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 106.  2008-10-13 01:11:21 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 107.  2008-10-13 00:41:29 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21

 108.  2008-10-13 00:11:21 DAHDI/1... 000 "unknown" <000> BackGround
silence/5 s
ANSWERED 00:21


When Asterisk see an incoming call without a caller ID, it sets it to
"unknown" and 000. As you can see from the list above, it happens every
30 minutes almost to the second. It is still happening right now, unless
that line is in use, in which case it'll try again 30 minutes later.

I did notice this in the /var/log/asterisk/full log:

[Oct 13 03:11:30] NOTICE[4243] chan_dahdi.c: Got event 17 (Polarity
Reversal)...
[Oct 13 03:11:38] WARNING[4243] chan_dahdi.c: CallerID returned with error
on channel 'DAHDI/1-1'

Normally, it says:

[Oct 12 13:23:59] DEBUG[30124] chan_dahdi.c: Ignore switch to REVERSED
Polarity on channel 1, state 4
[Oct 12 13:23:59] DEBUG[30124] chan_dahdi.c: Ignoring Polarity switch to
IDLE on channel 1, state 4
[Oct 12 13:23:59] DEBUG[30124] chan_dahdi.c: Polarity Reversal event occured
- DEBUG 2: channel 1, state 4, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= =
-233440198

Any clues?

TDM410P with 2 FXO ports and EC module. Running Fedora Core 9 in init:3 with
USB disabled (to prevent IRQ conflicts).
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-11 Thread Kurt Knudsen
Thanks, Steve,

That's what I am unsure of. I don't know how to limit 1 call per trunk. If
that's an easy thing to setup, I'd love to see it.

On Fri, Oct 10, 2008 at 10:20 PM, Steve Totaro <
[EMAIL PROTECTED]> wrote:

> Oh, I thought you had logic to count the calls on the trunk.  You should
> limit each trunk to one call.  This is the primary reason besides the email
> that basically said that customer support structure has been changed and
> anything beyond the Demarc would not be supported, I the Demarc is simply
> their boxen, so unless it is on their side, you will not get any helpful
> support from Bandwidth, plus they CCed over 500 people by address instead of
> setting up a group.
> http://www.bandwidth.com/content/support/?page=standardSupport
>
> I am with Junction and while a trunk is not "unlimited" as far as price for
> usage, the amount of trunks is unlimited (or at least as unlimited as it can
> be since nothing is really unlimited).  They asked that I try not to go over
> one call per second for any real duration, and that I not hammer one LATA do
> to limited interconnects.
>
> The other thing was Junctions was very easy to sign up with, great support,
> and configuration was a breeze.
>
> As for Bandwidth, I think they are solid but due to recent changes and the
> fact that you must pay per channel, as well as the setup process, I decided
> they were not for me.
>
> I will take a second look at your sip.conf and extensions.conf later to see
> if something jumps out at me.  I suspect since you are setting up two
> separate trunks with Bandwidth, you need to limit each trunk to one call,
> rather than two.
>
> Thanks,
> Steve Totaro
>
>
>
>
> On Fri, Oct 10, 2008 at 9:47 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>
>> externip messes up DTMF detection, and by messes up I mean it doesn't
>> detect it at all. Setting nat=yes or nat=no didn't make a difference either.
>>
>> When the trunks are in use, the calls are fine, no dropped audio. It only
>> happens when a 3rd call is made and there's no trunk available.
>>
>> Thanks :)
>>
>>
>> On Fri, Oct 10, 2008 at 7:09 PM, Steve Totaro <
>> [EMAIL PROTECTED]> wrote:
>>
>>> You need to configure your box for nat settings, externip and other
>>> settings in sip.conf and set nat=yes instead of nat=no.
>>>
>>> One way audio is almost always a NAT issue and those are two glaring
>>> things that would cause problems.
>>>
>>> Thanks,
>>> Steve Totaro
>>>
>>>
>>> On Fri, Oct 10, 2008 at 6:32 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> It's behind a NAT/Firewall but SIP translation is enabled and removing
>>>> it from behind the firewall did nothing, it still dropped calls. The calls
>>>> connect and everything works, but it dies when all trunks are in use and
>>>> someone else tries to call out. It seems like even though both channels are
>>>> in use, it tries to connect to the 2nd trunk and thus kills the audio.
>>>> Nothing strange came up in Wireshark or the firewall logs.
>>>>
>>>> Thanks.
>>>>
>>>> On Fri, Oct 10, 2008 at 5:40 PM, Steve Totaro <
>>>> [EMAIL PROTECTED]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 10, 2008 at 5:17 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>>  Hello,
>>>>>>
>>>>>>
>>>>>>
>>>>>> We have 2 SIP trunks from Bandwidth.com and if both are in use and
>>>>>> someone tries to dial out, they cause another call to get one-way audio 
>>>>>> (the
>>>>>> caller hears us, we cannot hear them). This happens 100% of the time and
>>>>>> Bandwidth.com doesn't offer any support. I don't see any setting that 
>>>>>> tells
>>>>>> Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
>>>>>> currently using, or attempting to use, groups to solve this problem, but
>>>>>> sometimes it works, sometimes it doesn't. It breaks when a call goes out 
>>>>>> on
>>>>>> a Queue, because it seems to add each phone to the group, which breaks my
>>>>>> GotoIf() statement. Here's some relevant information:
>>>>>>
>>>>>>
>>>>>>

Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-10 Thread Kurt Knudsen
externip messes up DTMF detection, and by messes up I mean it doesn't detect
it at all. Setting nat=yes or nat=no didn't make a difference either.

When the trunks are in use, the calls are fine, no dropped audio. It only
happens when a 3rd call is made and there's no trunk available.

Thanks :)

On Fri, Oct 10, 2008 at 7:09 PM, Steve Totaro <
[EMAIL PROTECTED]> wrote:

> You need to configure your box for nat settings, externip and other
> settings in sip.conf and set nat=yes instead of nat=no.
>
> One way audio is almost always a NAT issue and those are two glaring things
> that would cause problems.
>
> Thanks,
> Steve Totaro
>
>
> On Fri, Oct 10, 2008 at 6:32 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>
>> Hi Steve,
>>
>> It's behind a NAT/Firewall but SIP translation is enabled and removing it
>> from behind the firewall did nothing, it still dropped calls. The calls
>> connect and everything works, but it dies when all trunks are in use and
>> someone else tries to call out. It seems like even though both channels are
>> in use, it tries to connect to the 2nd trunk and thus kills the audio.
>> Nothing strange came up in Wireshark or the firewall logs.
>>
>> Thanks.
>>
>> On Fri, Oct 10, 2008 at 5:40 PM, Steve Totaro <
>> [EMAIL PROTECTED]> wrote:
>>
>>>
>>>
>>> On Fri, Oct 10, 2008 at 5:17 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>>>
>>>>  Hello,
>>>>
>>>>
>>>>
>>>> We have 2 SIP trunks from Bandwidth.com and if both are in use and
>>>> someone tries to dial out, they cause another call to get one-way audio 
>>>> (the
>>>> caller hears us, we cannot hear them). This happens 100% of the time and
>>>> Bandwidth.com doesn't offer any support. I don't see any setting that tells
>>>> Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
>>>> currently using, or attempting to use, groups to solve this problem, but
>>>> sometimes it works, sometimes it doesn't. It breaks when a call goes out on
>>>> a Queue, because it seems to add each phone to the group, which breaks my
>>>> GotoIf() statement. Here's some relevant information:
>>>>
>>>>
>>>>
>>>> Users.conf (added by Asterisk-GUI)
>>>>
>>>> [trunk_2]
>>>>
>>>> provider = Bandwidth (SIP)  ; GUI metadata
>>>>
>>>> context = DID_trunk_2
>>>>
>>>> hasexten = no
>>>>
>>>> hasiax = no
>>>>
>>>> hassip = yes
>>>>
>>>> host = 216.82.224.202
>>>>
>>>> registeriax = no
>>>>
>>>> registersip = no
>>>>
>>>> usecallerid = yes
>>>>
>>>> nat = no ;Testing
>>>>
>>>> trunkname = Bandwidth.com (Sip)  ; GUI metadata
>>>>
>>>> username =
>>>>
>>>> secret =
>>>>
>>>> disallow = all
>>>>
>>>> allow = ulaw,alaw,g726
>>>>
>>>>
>>>>
>>>> sip.conf
>>>>
>>>> [general]
>>>>
>>>> context = frombandwidth
>>>>
>>>> ;other variables, etc.
>>>>
>>>>
>>>>
>>>> ;Added according to Bandwidth.com's wiki entry. Changed to inband
>>>> because we were having DTMF issues.
>>>>
>>>> [bandwidth.com_inbound]
>>>>
>>>> host=216.82.224.202
>>>>
>>>> port=5060
>>>>
>>>> type=peer
>>>>
>>>> disallow=all
>>>>
>>>> allow=ulaw
>>>>
>>>> dtmfmode=inband
>>>>
>>>> canreinvite=no
>>>>
>>>> reinvite=no
>>>>
>>>> context=frombandwidth
>>>>
>>>> nat=no
>>>>
>>>>
>>>>
>>>> [bandwidth.com_outbound]
>>>>
>>>> host=216.82.224.202
>>>>
>>>> port=5060
>>>>
>>>> type=peer
>>>>
>>>> disallow=all
>>>>
>>>> allow=ulaw
>>>>
>>>> dtmfmode=rfc2833
>>>>
>>>> nat=no
>>>>
>>>> fromuser=11234567890
>>>>
>>>>
>>>>
>>>> extensions.conf
>>

Re: [asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-10 Thread Kurt Knudsen
Hi Steve,

It's behind a NAT/Firewall but SIP translation is enabled and removing it
from behind the firewall did nothing, it still dropped calls. The calls
connect and everything works, but it dies when all trunks are in use and
someone else tries to call out. It seems like even though both channels are
in use, it tries to connect to the 2nd trunk and thus kills the audio.
Nothing strange came up in Wireshark or the firewall logs.

Thanks.

On Fri, Oct 10, 2008 at 5:40 PM, Steve Totaro <
[EMAIL PROTECTED]> wrote:

>
>
> On Fri, Oct 10, 2008 at 5:17 PM, Kurt Knudsen <[EMAIL PROTECTED]>wrote:
>
>>  Hello,
>>
>>
>>
>> We have 2 SIP trunks from Bandwidth.com and if both are in use and someone
>> tries to dial out, they cause another call to get one-way audio (the caller
>> hears us, we cannot hear them). This happens 100% of the time and
>> Bandwidth.com doesn't offer any support. I don't see any setting that tells
>> Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
>> currently using, or attempting to use, groups to solve this problem, but
>> sometimes it works, sometimes it doesn't. It breaks when a call goes out on
>> a Queue, because it seems to add each phone to the group, which breaks my
>> GotoIf() statement. Here's some relevant information:
>>
>>
>>
>> Users.conf (added by Asterisk-GUI)
>>
>> [trunk_2]
>>
>> provider = Bandwidth (SIP)  ; GUI metadata
>>
>> context = DID_trunk_2
>>
>> hasexten = no
>>
>> hasiax = no
>>
>> hassip = yes
>>
>> host = 216.82.224.202
>>
>> registeriax = no
>>
>> registersip = no
>>
>> usecallerid = yes
>>
>> nat = no ;Testing
>>
>> trunkname = Bandwidth.com (Sip)  ; GUI metadata
>>
>> username =
>>
>> secret =
>>
>> disallow = all
>>
>> allow = ulaw,alaw,g726
>>
>>
>>
>> sip.conf
>>
>> [general]
>>
>> context = frombandwidth
>>
>> ;other variables, etc.
>>
>>
>>
>> ;Added according to Bandwidth.com's wiki entry. Changed to inband because
>> we were having DTMF issues.
>>
>> [bandwidth.com_inbound]
>>
>> host=216.82.224.202
>>
>> port=5060
>>
>> type=peer
>>
>> disallow=all
>>
>> allow=ulaw
>>
>> dtmfmode=inband
>>
>> canreinvite=no
>>
>> reinvite=no
>>
>> context=frombandwidth
>>
>> nat=no
>>
>>
>>
>> [bandwidth.com_outbound]
>>
>> host=216.82.224.202
>>
>> port=5060
>>
>> type=peer
>>
>> disallow=all
>>
>> allow=ulaw
>>
>> dtmfmode=rfc2833
>>
>> nat=no
>>
>> fromuser=11234567890
>>
>>
>>
>> extensions.conf
>>
>> [globals]
>>
>> ;…irrelevant stuff
>>
>> trunk_1 = Dahdi/g1
>>
>> trunk_2 = SIP/trunk_2
>>
>> OUT_2 = SIP/bandwidth.com_outbound
>>
>>
>>
>> ;Took out the Set(GROUP()) because I moved it elsewhere to try and fix it
>> added all the phones when Asterisk calls agents on a Queue.
>>
>> [frombandwidth]
>>
>> ;exten = _+1.,1,Set(GROUP()=SIPGROUP)
>>
>> exten = _+1.,1,NoOp(FromCount=${GROUP_COUNT(SIPGROUP)})
>>
>> exten = _+1.,n,Set(DID=${EXTEN:2})
>>
>> exten = _+1.,n,Set(CALLERID(num)=${CALLERID(num):2})
>>
>> exten = _+1.,n,Goto(DID_trunk_2,${DID},1)
>>
>>
>>
>> ;What we use to dialout. Try SIP trunks first, then Dahdi trunk as backup.
>>
>> ;This is where it breaks. I tried to make it so there can't be more than 2
>> calls on SIP channels at once.
>>
>> ;Since it counts the phone as a channel, and adds it to the group, I had
>> to use 4.
>>
>> [internalphones]
>>
>> exten = _1NXXNXX,1,Set(GROUP()=SIPGROUP)
>>
>> exten = _1NXXNXX,n,GotoIf($[${GROUP_COUNT(SIPGROUP)} >= 4]?100)  ;If
>> the group has 2 or more calls, do not dial.
>>
>> exten = _1NXXNXX,n,NoOp(1NCount = ${GROUP_COUNT(SIPGROUP)})
>>
>> exten =
>> _1NXXNXX,n,Macro(trunkdial-failover-0.3,${trunk_2}/+${EXTEN:0},${trunk_1}/${EXTEN:0},trunk_1,trunk_2)
>>
>> exten = _1NXXNXX,100,Playback(all-circuits-busy-now)
>>
>> exten = _1NXXNXX,101,congestion()
>>
>> exten = _1NXXNXX,102,busy()
>>
>>
>>
>> ;This is where incoming calls go to if I'm awake.
>>
>> [DID_trunk_2_timeinterval_Awake]
>>
>> exten = _NXXNXX,1,Set(GROUP()=SIPGROUP)
>>
>> exten = _NXXNXX,n,NoOp(Open Count=${GROUP_COUNT(SIPGROUP)})
>>
>> exten = _NXXNXX,n,Set(CALLERID(num)=1${CALLERID(num)})
>>
>> exten = _NXXNXX,n,Goto(voicemenu-custom-1|s|1)
>>
>>
>>
>> Thanks.
>>   <http://lists.digium.com/mailman/listinfo/asterisk-users>
>
>
> Is your Asterisk box on a public IP or behind a NAT/Firewall?
>
> --
> Thanks,
> Steve Totaro
> +18887771888 (Toll Free)
> +12409381212 (Cell)
> +12024369784 (Skype)
>
> ___
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> 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 --

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

[asterisk-users] Configuring Bandwidth.com SIP trunks to prevent one-way audio

2008-10-10 Thread Kurt Knudsen
Hello,



We have 2 SIP trunks from Bandwidth.com and if both are in use and someone
tries to dial out, they cause another call to get one-way audio (the caller
hears us, we cannot hear them). This happens 100% of the time and
Bandwidth.com doesn't offer any support. I don't see any setting that tells
Asterisk that there are 2 channels available from Bandwidth.com's IP. I'm
currently using, or attempting to use, groups to solve this problem, but
sometimes it works, sometimes it doesn't. It breaks when a call goes out on
a Queue, because it seems to add each phone to the group, which breaks my
GotoIf() statement. Here's some relevant information:



Users.conf (added by Asterisk-GUI)

[trunk_2]

provider = Bandwidth (SIP)  ; GUI metadata

context = DID_trunk_2

hasexten = no

hasiax = no

hassip = yes

host = 216.82.224.202

registeriax = no

registersip = no

usecallerid = yes

nat = no ;Testing

trunkname = Bandwidth.com (Sip)  ; GUI metadata

username =

secret =

disallow = all

allow = ulaw,alaw,g726



sip.conf

[general]

context = frombandwidth

;other variables, etc.



;Added according to Bandwidth.com's wiki entry. Changed to inband because we
were having DTMF issues.

[bandwidth.com_inbound]

host=216.82.224.202

port=5060

type=peer

disallow=all

allow=ulaw

dtmfmode=inband

canreinvite=no

reinvite=no

context=frombandwidth

nat=no



[bandwidth.com_outbound]

host=216.82.224.202

port=5060

type=peer

disallow=all

allow=ulaw

dtmfmode=rfc2833

nat=no

fromuser=11234567890



extensions.conf

[globals]

;…irrelevant stuff

trunk_1 = Dahdi/g1

trunk_2 = SIP/trunk_2

OUT_2 = SIP/bandwidth.com_outbound



;Took out the Set(GROUP()) because I moved it elsewhere to try and fix it
added all the phones when Asterisk calls agents on a Queue.

[frombandwidth]

;exten = _+1.,1,Set(GROUP()=SIPGROUP)

exten = _+1.,1,NoOp(FromCount=${GROUP_COUNT(SIPGROUP)})

exten = _+1.,n,Set(DID=${EXTEN:2})

exten = _+1.,n,Set(CALLERID(num)=${CALLERID(num):2})

exten = _+1.,n,Goto(DID_trunk_2,${DID},1)



;What we use to dialout. Try SIP trunks first, then Dahdi trunk as backup.

;This is where it breaks. I tried to make it so there can't be more than 2
calls on SIP channels at once.

;Since it counts the phone as a channel, and adds it to the group, I had to
use 4.

[internalphones]

exten = _1NXXNXX,1,Set(GROUP()=SIPGROUP)

exten = _1NXXNXX,n,GotoIf($[${GROUP_COUNT(SIPGROUP)} >= 4]?100)  ;If the
group has 2 or more calls, do not dial.

exten = _1NXXNXX,n,NoOp(1NCount = ${GROUP_COUNT(SIPGROUP)})

exten =
_1NXXNXX,n,Macro(trunkdial-failover-0.3,${trunk_2}/+${EXTEN:0},${trunk_1}/${EXTEN:0},trunk_1,trunk_2)

exten = _1NXXNXX,100,Playback(all-circuits-busy-now)

exten = _1NXXNXX,101,congestion()

exten = _1NXXNXX,102,busy()



;This is where incoming calls go to if I'm awake.

[DID_trunk_2_timeinterval_Awake]

exten = _NXXNXX,1,Set(GROUP()=SIPGROUP)

exten = _NXXNXX,n,NoOp(Open Count=${GROUP_COUNT(SIPGROUP)})

exten = _NXXNXX,n,Set(CALLERID(num)=1${CALLERID(num)})

exten = _NXXNXX,n,Goto(voicemenu-custom-1|s|1)



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

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