asterisk users - Oct 2007 - Parking lot problems

Now on to another problem that we've had as far as I know since the
beginning of using Asterisk 9+ months ago.  I've been trying very hard
to knock this problem out but regardless of what I do, it's still there.
 
So, the problem is, when a call is in the parking lot, it then times out
after whatever time frame and dials the extension that put it on hold.
After 60 seconds of ringing back, it's supposed to go to [park-dial] t
extension as far as I can tell, which it actually does seem to do.
However, before the t extension kicks in, the line is dropped with the
following error message on the CLI:
 
[Oct  3 08:45:31] WARNING[12621]: channel.c:2616 ast_indicate_data:
Unable to handle indication 3 for 'SIP/727-095c0348'
[Oct  3 08:46:31] WARNING[11487]: chan_sip.c:12037
handle_response_invite: Re-invite to non-existing call leg on other UA.
SIP dialog '294bf6652379a770665524cc50a8cfab at xxx.xxx.xxx.xxx. Giving up.
    -- SIP/717-09570200 is circuit-busy
[Oct  3 08:46:31] NOTICE[12621]: cdr.c:434 ast_cdr_free: CDR on channel
'SIP/717-09570200' not posted
  == Everyone is busy/congested at this time (1:0/1/0)
  == Auto fallthrough, channel 'SIP/727-095c0348' status is
'CONGESTION'
[Oct  3 08:46:31] WARNING[12621]: channel.c:2616 ast_indicate_data:
Unable to handle indication 8 for 'SIP/727-095c0348'
[Oct  3 08:46:31] WARNING[11487]: chan_sip.c:12536 handle_response:
Remote host can't match request CANCEL to call
'294bf6652379a770665524cc50a8cfab at xxx.xxx.xxx.xxx'. Giving up.
 
So the line hangs up, these errors are displayed, then I see the 't'
extension kick in.  Notice this is all on the same network, SIP devices
only, no NAT or anything like that.  I was initially testing on a
ZAP/SIP configuration, had the same type of errors and thought to reduce
complexity I'd keep it all SIP.  I've tried canreinvite=yes and no on
the SIP devices, neither made a difference.
 
So, before I go the bug route I'd like someone to just verify my
configuration files make sure I'm not doing something stupid.

SIP.CONF:
[general]
callerid=Unknown Caller
disallow=all
allow=ulaw
allow=gsm

[717]
type=friend
dial=SIP/717
callerid=Ken Williams <717>
mailbox=717 at default
allowsubscribe=yes
host=dynamic
context=from-internal
 
[727]
type=friend
secret=1234
dial=SIP/727
callerid=Conference Room <727>
mailbox=727 at default <mailto:mailbox=727 at default> 
allowsubscribe=yes
host=dynamic
context=from-internal

EXTENSIONS.CONF:
[from-internal]
        include => parkedcalls
        exten => _20X,1,Goto(parkedcalls,${EXTEN},1)

[park-dial]
        exten => t,1,Goto(from-internal,900,1)

FEATURES.CONF
[general]
parkext => 200
parkpos => 201-205
context => parkedcalls
parkingtime => 30
parkhints = yes

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20071003/24caa9aa/attachment.htm

Ken Williams wrote:
> Now on to another problem that we've had as far as I know since the 
> beginning of using Asterisk 9+ months ago.  I've been trying very hard 
> to knock this problem out but regardless of what I do, it's still
there.
>  
> [from-internal]
>         include => parkedcalls
I have this.
>         exten => _20X,1,Goto(parkedcalls,${EXTEN},1)
Is this really necessary?  I only have the include.  parked calls are 
created on the fly.  Our lot is from 90-99 and we don't need an entry in 
the dial plan to handle it.
> [park-dial]
>         exten => t,1,Goto(from-internal,900,1)
I have similar to this as well.

Doug

-- 
 
Ben Franklin quote:

"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety."