[App_rpt-users] Reverse autopatch immediately hanging up
Josh Freeman
cpe.jfreeman at gmail.com
Wed Oct 12 01:52:25 UTC 2011
I feel kind of stupid, but I've solved my problem and discovered
something interesting.
App_rpt accepts connections directly from Zap and SIP channels (without
the use of Local) just fine when it's invoked with the R option, as
Rpt(${NODE},R<announce-string>)
I discovered this by accidentally dialing the test extension I'd set up
for checking direct IAX from my Zap phone. Wow, it worked! I got to
thinking about what I had done differently, and it occurred to me that
I'd probably gotten the warning I mentioned when I was still invoking
app_rpt as
Rpt(${NODE},X)
So, I tried doing that again, and sure enough - no Zap or SIP
connections. Anyway, I wanted to clear the air on here and not leave it
appearing as though Zap and SIP connections wouldn't work for
reverse-autopatch. They do, if you do it right.
Josh
Josh Freeman wrote:
> OK. Well, darn. =)
>
> Originally, I had tried to connect directly from the Zap channel, and
> it failed with the message
> Warning: We only accept links via IAX2, Echolink, TheLinkBox or Local!!
> I guess that's what got me thinking Local channels would be the way to
> bridge over from Zap or SIP.
>
> Thanks again for your help!
>
> Josh
>
> On 10/10/2011 8:45 PM, Jim Duuuude wrote:
>> dont use it at all... app_rpt cant deal with it.
>>
>> ------------------------------------------------------------------------
>> Date: Mon, 10 Oct 2011 19:53:14 -0500
>> From: cpe.jfreeman at gmail.com
>> To: telesistant at hotmail.com
>> Subject: Re: [App_rpt-users] Reverse autopatch immediately hanging up
>>
>> OK, I tried that... it looks like the reverse autopatch *does* work
>> correctly when dialed into via pure IAX. Unfortunately, only being
>> able to use native IAX clients doesn't meet the requirements for what
>> I'm trying to do. I'll study up some more on how Local channels work,
>> maybe I'm not using that mechanism correctly.
>>
>> Thanks,
>> Josh
>>
>> On 10/10/2011 6:21 PM, Jim Duuuude wrote:
>>
>> okay, try calling it directly from your IAX client, rather then
>> through a Local channel
>>
>> ------------------------------------------------------------------------
>> Date: Mon, 10 Oct 2011 18:05:16 -0500
>> From: cpe.jfreeman at gmail.com <mailto:cpe.jfreeman at gmail.com>
>> To: APP_RPT-USERS at OHNOSEC.ORG <mailto:APP_RPT-USERS at OHNOSEC.ORG>
>> Subject: Re: [App_rpt-users] Reverse autopatch immediately hanging up
>>
>> Jim,
>>
>> That would be correct, if I had left the [radio] context as it
>> was in the bundled Allstar dialplan, where this line
>>
>> exten=_07XX,1,Goto(parkedcalls|${EXTEN:1}|1)
>>
>> makes it necessary to dial the leading "0." I created a different
>> radio context, and simply added
>>
>> include => parkedcalls
>>
>> so that the pickup code *is* actually just '701'.
>>
>> Because I don't understand everything about this system, though,
>> I tried reverting that part of my dialplan back to the Allstar
>> configuration, just to see if that made a difference. It didn't -
>> the autopatch still gets hung up within a second or two of
>> connection. Dialing through the Local channel is the thing I'm
>> doing that's significantly different than anything in the Allstar
>> dialplan, so I'm guessing that's where the problem is - but I'm
>> not smart enough to find it yet.
>>
>> Thanks,
>> Josh
>>
>> On 10/10/2011 1:33 PM, Jim Duuuude wrote:
>>
>> Thats because youre missing a 'digits/0' between the incall
>> and the PARKED, such as:
>>
>> Rpt(${EXTEN:1}|Rrpt/node:NODE:rpt/in-call:digits/0:PARKED|120)
>>
>> The code to pick that up should be '0701' *not* 701
>>
>> JIM WB6NIL
>>
>> ------------------------------------------------------------------------
>> Date: Mon, 10 Oct 2011 11:06:52 -0500
>> From: cpe.jfreeman at gmail.com <mailto:cpe.jfreeman at gmail.com>
>> To: APP_RPT-USERS at OHNOSEC.ORG <mailto:APP_RPT-USERS at OHNOSEC.ORG>
>> Subject: [App_rpt-users] Reverse autopatch immediately hanging up
>>
>> Hello,
>>
>> I'm trying to set up a system that has a reverse autopatch as
>> one of its features. The problem I'm having is that when a
>> radio user dials the code to pick up an incoming call, the
>> call gets disconnected almost immediately upon connecting.
>> I'm certain the problem is that I've not set things up
>> properly, but I'm still inexperienced enough that I could
>> really use some help troubleshooting.
>>
>> My Asterisk system is running from a recent ACID image
>> (downloaded maybe three weeks ago). The machine also has a
>> TDM400P card with an FXS module connected to an analog
>> telephone I'm using to originate incoming test calls to the
>> repeater system.
>>
>> The relevant parts of my dialplan are as follows:
>>
>> In context *phones_local*:
>>
>> exten => 272727,1,Dial(Local/CQCQCQ at repeater)
>> (Apparently, I can't directly connect to app_rpt from a Zap
>> channel, so I dial through a Local channel instead.)
>>
>> Then, in context *repeater*:
>>
>> exten => CQCQCQ,1,Rpt(5674,Rrpt/in-call:PARKED,120)
>> (This is an isolated system, so the node number is simply my
>> name on a telephone keypad.)
>>
>> What happens is this: I dial 272727 from the analog
>> telephone, and I hear the announcement over the radio just
>> fine. I send *6701 from the radio, and hear "Connecting" from
>> the repeater along with echoing audio from the analog phone
>> (because it's right there next to the radio). Then, I
>> immediately hear "Call terminated" and the autopatch drops.
>> The analog phone doesn't get hung up, though.
>>
>> Here's what I see on the Asterisk console. For this trace, I
>> was actually dialing in from an IAX softphone rather than the
>> Zap channel, but the behavior is exactly the same.
>>
>> -- Executing [272727 at phones_local:1] Dial("IAX2/josh-12630",
>> "Local/CQCQCQ at repeater") in new stack
>> -- Called CQCQCQ at repeater
>> -- Executing [CQCQCQ at repeater:1]
>> Rpt("Local/CQCQCQ at repeater-781b,2",
>> "5674|Rrpt/in-call:PARKED|120") in new stack
>> -- Return Context: (repeater,CQCQCQ,2) ID: 0
>> -- Warning: Return Context Invalid, call will return to
>> default|s
>> -- Music class default requested but no musiconhold loaded.
>> == Parked Local/CQCQCQ at repeater-781b,2 on 701 at parkedcalls.
>> Will timeout back to extension [repeater] CQCQCQ, 2 in 45
>> seconds
>> -- Added extension '701' priority 1 to parkedcalls
>> -- Music class default requested but no musiconhold loaded.
>> -- Music class default requested but no musiconhold loaded.
>> -- Local/CQCQCQ at repeater-781b,1 answered IAX2/josh-12630
>> -- Call Parking Called, lot: 701, timeout: 0, context: (null)
>> -- Music class default requested but no musiconhold loaded.
>> -- <Zap/pseudo-1800116975> Playing 'rpt/in-call' (language
>> 'en')
>> -- <Zap/pseudo-1800116975> Playing 'digits/7' (language 'en')
>> -- <Zap/pseudo-1800116975> Playing 'digits/0' (language 'en')
>> -- <Zap/pseudo-1800116975> Playing 'digits/1' (language 'en')
>> -- Hungup 'Zap/pseudo-1800116975'
>> -- Hungup 'Zap/pseudo-1018949410'
>> [Oct 9 19:44:18] NOTICE[2594]: chan_usbradio.c:3010
>> usbradio_read: Got DTMF char * duration 340 ms
>> [Oct 9 19:44:19] NOTICE[2594]: chan_usbradio.c:3010
>> usbradio_read: Got DTMF char 6 duration 235 ms
>> [Oct 9 19:44:20] NOTICE[2594]: chan_usbradio.c:3010
>> usbradio_read: Got DTMF char 7 duration 255 ms
>> [Oct 9 19:44:20] NOTICE[2594]: chan_usbradio.c:3010
>> usbradio_read: Got DTMF char 0 duration 212 ms
>> -- Hungup 'Zap/pseudo-1705936882'
>> [Oct 9 19:44:21] NOTICE[2594]: chan_usbradio.c:3010
>> usbradio_read: Got DTMF char 1 duration 235 ms
>> -- Executing [701 at phones_radio:1]
>> ParkedCall("Zap/pseudo-523589909", "701") in new stack
>> -- Channel Zap/pseudo-523589909 connected to parked call 701
>> == Spawn extension (phones_radio, 701, 1) exited non-zero on
>> 'Local/CQCQCQ at repeater-781b,1<ZOMBIE>'
>> -- Hungup 'Zap/pseudo-1742992459'
>> -- Hungup 'Zap/pseudo-1417902655'
>> -- <Zap/pseudo-1427730098> Playing 'rpt/callproceeding'
>> (language 'en')
>> -- Hungup 'Zap/pseudo-1427730098'
>> -- <Zap/pseudo-1938338821> Playing 'rpt/callterminated'
>> (language 'en')
>> -- Hungup 'Zap/pseudo-1938338821'
>> -- Hungup 'Zap/pseudo-1525511763'
>>
>> I see some things about invalid return context and zombie
>> channels, but I'm not sure what that means. Any idea what it
>> is I'm missing?
>>
>> Thanks,
>> Josh
>>
>>
>> _______________________________________________ App_rpt-users
>> mailing list App_rpt-users at ohnosec.org
>> <mailto:App_rpt-users at ohnosec.org>
>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>>
>>
>>
>> _______________________________________________ App_rpt-users
>> mailing list App_rpt-users at ohnosec.org
>> <mailto:App_rpt-users at ohnosec.org>
>> http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.keekles.org/pipermail/app_rpt-users/attachments/20111011/91d2d364/attachment.html>
More information about the App_rpt-users
mailing list