Skip to main content

Incoming calls does not work

Posted by vipcarrier on Sat, 06/06/2009

Incoming calls does not work

sent into invalid extension 's' in context 'from-outside-redir', but no invalid handler

please help


Submitted by vipcarrier on Sat, 06/06/2009 Permalink

[Jun 6 21:51:33] WARNING[28303]: pbx.c:2470 __ast_pbx_run: Channel 'SIP/20X.XX. 55.130-08e3a260' sent into invalid extension 's' in context 'from-outside-redir' , but no invalid handler

Submitted by eeman on Sun, 06/07/2009 Permalink

WHY is your sip channel an IP address?.. this is wrong. did you name it an IP address? edit sip.conf

[general]

allowguest=no

and tell me if your calls stop processing.

you also need to capture the sip dialog on the incomming call and post the details of the INVITE message. make sure you replace < > otherwise most of the data wont display.

Submitted by ringo on Tue, 09/15/2009 Permalink

We have a single Tenant configured with T! that comes from a Nortel Option 11C,

When I make calls to the Nortel ext everything it's OK, but when I try to call to my Asterisk box I get this messages:

sent into invalid extension '3001' in context 'from-outside-redir', but no invalid handler

This is my configuration

span=1,1,0,d4,ami

# termtype: te

#bchan=1-23

#dchan=24

e&m=1-24

echocanceller=mg2,1-24

chan_dahdi

[channels]

language=es

rxwink=300

usecallerid=no

hidecallerid=no

echocancel=yes

echocancelwhenbridged=yes

echotraining=no

relaxdtmf=yes

jbenable = yes

jbmaxsize = 200

jbresyncthreshold = 1000

jbimpl = fixed

jblog = no

context=from-outside

signalling=e&m

group=1

txgain=0.0

rxgain=0.0

usecallerid=no

echocancel=yes

echocancelwhenbridged=yes

echotraining=no

callerid=asreceived

busydetect=no

callprogress=no

busycount=4

channel=>1-24

Any help I will appreciated

Submitted by eeman on Tue, 09/15/2009 Permalink

your error does not indicate there is a problem with your dahdi settings. Call goes right through from-outside and right on to from-outside-redir

A) the lame provider is sending you 4 digits

1) thats pretty friggen gay for 2009

2) that means your inbound routes have to only be 4 digit, which breaks other things like knowing if its an internal call versus external call etc.

3) E&M wink is 1970s technology with longer setup times and limited call progress, why not a PRI?

4) you're limited on the DID's you can even port to this circuit, (none can have the same last 4 as another TN)

B) your choice is:

1) live with crappy 4 digit DNIS on a 1970's circuit and re-do all your inbound routes, and subsequently

2) convert to 10 digit DNIS and PRI signalling (most preferred)

3) alter chan_dahdi.conf to send to another context, and that context does a GoTo() that fixes the 4 digits back into 10 digits (this is not intelligent fixing, its a static NPANXX which means ALL of your TNs MUST have the exact same NPANXX)

Submitted by ringo on Wed, 09/16/2009 Permalink

Well Erik, now this is my configuration,

span=1,1,1,esf,b8zs

# termtype: te

bchan=1-23

dchan=24

echocanceller=mg2,1-24

chan_dahdi

[channels]

switchtype=national

language=es

rxwink=300

usecallerid=no

hidecallerid=no

echocancel=yes

echocancelwhenbridged=yes

echotraining=no

relaxdtmf=yes

jbenable = yes

jbmaxsize = 200

jbresyncthreshold = 1000

jbimpl = fixed

jblog = no

context=from-outside

signalling=pri_cpe

group=1

txgain=0.0

rxgain=0.0

usecallerid=no

echocancel=yes

echocancelwhenbridged=yes

echotraining=no

callerid=asreceived

busydetect=no

callprogress=no

busycount=4

channel=>1-23

but the message is the same:

-- Accepting call from '2138' to '3001' on channel 0/23, span 1

-- Executing [3001@from-outside:1] Wait("DAHDI/23-1", "1") in new stack

-- Executing [3001@from-outside:2] Set("DAHDI/23-1", "__INCOMINGCLI=") in new stack

-- Executing [3001@from-outside:3] Goto("DAHDI/23-1", "from-outside-redir,3001,1") in new stack

-- Goto (from-outside-redir,3001,1)

[Sep 16 19:09:22] WARNING[3866]: pbx.c:3769 __ast_pbx_run: Channel 'DAHDI/23-1' sent into invalid extension '3001' in context 'from-outside-redir', but no invalid handler

-- Hungup 'DAHDI/23-1'

What am I doing wrong, or what is the Nortel guy missing or doing wrong?

Please help!!

Submitted by eeman on Wed, 09/16/2009 Permalink

its spelling it out for you in black and white... the # being transmitted to you is 3001 not 10 digit DNIS but 3001 ... i bet dollars to donuts that there is no 3001 in your inbound routes. Therefore its sent to an invalid extension. Tell your service provider to outpulse 10 digit DNIS and knock that 4 digit crap off. Also why are they sending you 4 digit callerid? Are they the poster child for bad telecom habits? The latter problem wont prevent you from working, you can insult them for 4 digit callerid later :)

Submitted by ringo on Thu, 09/17/2009 Permalink

Sorry Erik this connection is a PRI from a Nortel 11C, I always be receiving 4 digits, I will never be receiving from PSTN for now. '3001' is one of my ext, in the Nortel side he has a route 3XXX, so my exts go from 3001 to 3099.

When I use signalling=fxs_ls everything goes ok, but Asterisk never knows when the other side hang up, in that moment I was using a channel bank T1, so reading your options I asked him to change for a PRI T1. I have a very hurry about this because the time is over, and I do not know if they can wait another day for me.

Thank you!

Submitted by eeman on Thu, 09/17/2009 Permalink

keep it as PRI, change your context from 'from-outside' to 'from-inside' if you are wanting to call extensions directly and treat it as a inter-connected pbx. PRI will give you the best signalling for call status.

Submitted by ringo on Wed, 09/30/2009 Permalink

Thanks very much Erik, the problem was related with the context. I changed it to from-inside and it is fixed. Now i'm having a new issue, i can't dial 10 digits numbers, i receive a congestion tone and message in asterisk CLI. Nortel is the one connected to pstn and the idea is to reach PSTN form asterisk throuhg nortel.

This is the error message:

Requested transfer capability: 0x00 - SPEECH

-- Called g1/98096852314

-- Channel 0/1, span 1 got hangup, cause 42

-- DAHDI/1-1 is circuit-busy

-- Hungup 'DAHDI/1-1'

== Everyone is busy/congested at this time (1:0/1/0)

-- Executing [dial-DAHDI@macro-tl-dialout-base:8] Goto("SIP/3084-09f8ddb8", "dial-CONGESTION|1") in new stack

-- Goto (macro-tl-dialout-base,dial-CONGESTION,1)

-- Executing [dial-CONGESTION@macro-tl-dialout-base:1] Goto("SIP/3084-09f8ddb8", "next|1") in new stack

-- Goto (macro-tl-dialout-base,next,1)

-- Executing [next@macro-tl-dialout-base:1] Set("SIP/3084-09f8ddb8", "i=6") in new stack

-- Executing [next@macro-tl-dialout-base:2] Goto("SIP/3084-09f8ddb8", "onetrunk|1") in new stack

-- Goto (macro-tl-dialout-base,onetrunk,1)

-- Executing [onetrunk@macro-tl-dialout-base:1] Set("SIP/3084-09f8ddb8", "FULLNAME=") in new stack

-- Executing [onetrunk@macro-tl-dialout-base:2] Set("SIP/3084-09f8ddb8", "TRUNK=") in new stack

-- Executing [onetrunk@macro-tl-dialout-base:3] GotoIf("SIP/3084-09f8ddb8", "1?failed|1") in new stack

-- Goto (macro-tl-dialout-base,failed,1)

-- Executing [failed@macro-tl-dialout-base:1] PlayTones("SIP/3084-09f8ddb8", "congestion") in new stack

-- Executing [failed@macro-tl-dialout-base:2] Congestion("SIP/3084-09f8ddb8", "10") in new stack

== Spawn extension (macro-tl-dialout-base, failed, 2) exited non-zero on 'SIP/3084-09f8ddb8' in macro 'tl-dialout-base'

== Spawn extension (macro-tl-dialout-1-trunk, s, 3) exited non-zero on 'SIP/3084-09f8ddb8' in macro 'tl-dialout-1-trunk'

== Spawn extension (from-inside-redir, 98096852314, 1) exited non-zero on 'SIP/3084-09f8ddb8'

-- Executing [h@from-inside-redir:1] Hangup("SIP/3084-09f8ddb8", "") in new stack

== Spawn extension (from-inside-redir, h, 1) exited non-zero on 'SIP/3084-09f8ddb8'

thirdlane*CLI>

Submitted by eeman on Wed, 09/30/2009 Permalink

I am counting 11 digits

98096852314

I hate that 'dial 9 to get out' shit. that's legacy from the 80's. You might as well wear spandex, leg warmers, and a turned up collar :) are you sure you have to send the 9 to the nortel?

cause 42 = switching equipment congestion

btw if your nortel is sending to you in ascending order you should send to it in decending order. G1 starts at 23 and goes downward, g1 starts at 1 and goes upward.

Submitted by ringo on Wed, 09/30/2009 Permalink

I tryed both way G1 and g1 and is the same. Also tryed sending eleven digits with 9 and ten digits without the 9 and failed both way. Basically i have two outbound routes: one is for 4 digits dialing (internal extensions) and the other for 10 digits (PSTN dialing). Each route is exactly the same configuration, except the pattern of course ( _XXXX and _9NXXNXXXXXX ) and both use the same trunk. Th 4 digit works and the 10 digits don't.

Look at the following message extract:

-- Executing [onetrunk@macro-tl-dialout-base:17] Goto("SIP/3084-09229bc0", "di al-DAHDI|1") in new stack

-- Goto (macro-tl-dialout-base,dial-DAHDI,1)

-- Executing [dial-DAHDI@macro-tl-dialout-base:1] GotoIf("SIP/3084-09229bc0", "1?NoOpt") in new stack

-- Goto (macro-tl-dialout-base,dial-DAHDI,4)

-- Executing [dial-DAHDI@macro-tl-dialout-base:4] GotoIf("SIP/3084-09229bc0", "1?noarg") in new stack

-- Goto (macro-tl-dialout-base,dial-DAHDI,7)

-- Executing [dial-DAHDI@macro-tl-dialout-base:7] Dial("SIP/3084-09229bc0", "D AHDI/g1/98095684123") in new stack

[Sep 28 11:31:26] WARNING[3555]: channel.c:3186 ast_request: No channel type regis tered for 'DAHDI'

[Sep 28 11:31:26] WARNING[3555]: app_dial.c:1237 dial_exec_full: Unable to create channel of type 'DAHDI' (cause 66 - Channel not implemented)

== Everyone is busy/congested at this time (1:0/0/1)

-- Executing [dial-DAHDI@macro-tl-dialout-base:8] Goto("SIP/3084-09229bc0", "d ial-CHANUNAVAIL|1") in new stack

-- Goto (macro-tl-dialout-base,dial-CHANUNAVAIL,1)

-- Executing [dial-CHANUNAVAIL@macro-tl-dialout-base:1] Goto("SIP/3084-0 0", "next|1") in new stack

-- Goto (macro-tl-dialout-base,next,1)

-- Executing [next@macro-tl-dialout-base:1] Set("SIP/3084-09229bc0", "i= new stack

-- Executing [next@macro-tl-dialout-base:2] Goto("SIP/3084-09229bc0", "o k|1") in new stack