[Home]

Summary:ASTERISK-01129: ParkedCalls Getting Dropped
Reporter:jayson (jayson)Labels:
Date Opened:2004-03-01 16:25:29.000-0600Date Closed:2011-06-07 14:10:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When I receive an incoming call and park it, ringback works fine.

When I dial out and later park my outging call, ringback fails.  Specifically, the call always gets hung up.  When the call is over IAX, it will display the following message (like to tried to redirect the call to the incoming extension):

Mar  1 14:30:10 WARNING[51224]: pbx.c:1781 ast_pbx_run: Channel 'IAX2[voicepulse]/1' sent into invalid extension 's' in context 'default', but no invalid handler

When it's on a Zap channel, it simply hangs up without a message.


****** ADDITIONAL INFORMATION ******

Does this relate to how Park knows which extension to use for ringback?
Comments:By: Brian West (bkw918) 2004-03-02 10:59:35.000-0600

I suspect a config error how are you trying to park the call?


# transfers or native sip transfers?
By: jayson (jayson) 2004-03-03 22:32:18.000-0600

<?xml version='1.0' encoding='improperly-escaped-stuff'?>
<version length='short'>
I think I've isolated the weirdness.

I call a line.  I then park my OUTGOING call.  Ringback never occurs and * shows the channel as being dropped into the default rule on it's default context (in my case, does nothing).

This appears to be because parking assumes that you park INCOMING calls, not OUTGOING calls.  This is regrettable because I had preferred this as a way to carry calls around the office with you (as opposed to per-person call queues with weird requeue extensions).

I think this behaviour is clearly a bug, but I'm at a loss to determine what the "right" solution is.  To be sure, I'd say this behaviour at best violates the "principle of least surprise", and, at worst, routes a call into limbo due to confusion about where it should go.  (BTW, if you haven't read ESR's The Art of Unix Programming, get it, read it, and lend it to Marko--he has other useful rules).
</version>

<version length='long>
I do the following on a Zaptel channel:

flash (get tone)
dial 100 (I've set parking.conf to do 100 as parkext and 101-199 as parking lot)
hang up

I just got some more info.  When I call the number and then it parks me (IOW, I'm an inbound call) ringback works fine.  I played on the console while waiting for dialback and got the following:

*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/29-1  (macro-stdexten s            2   )      Up Parked Call   (None)
1 active channel(s)
*CLI> show parkedcalls
Num                   Channel (Context         Extension    Pri ) Timeout
101                  Zap/29-1 (macro-stdexten  s            2   )     45s

Interestingly, in this situation it WORKED FINE!

Before I had tried parking on an outgoing call (this appears to be a not-so-often hit case, since I also am having issues controlling the MOH on inbound parked calls).

When I try parking an outbound call I get the following out of the console:

*CLI> show parkedcalls
Num                   Channel (Context         Extension    Pri ) Timeout
101                  Zap/29-1 (outgoing        s            1   )      5s
*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/29-1  (outgoing   s            1   )      Up Parked Call   (None)
1 active channel(s)

This is where the timeout occurs and it should dialback:

*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/29-1  (outgoing   s            3   )      Up (None)        (None)
1 active channel(s)
*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/29-1  (outgoing   s            3   )      Up (None)        (None)
1 active channel(s)

It appears that the parked call picks up its return path from the WRONG SIDE OF THE LINK!  That is, I park it on the source side but to tries to dialback the extension at the destination side (for inbound calls the receiving side would be correct).  Oddly, since the channel is slaved to the other (inbound call) it has no extension except for its default one (notice outgoing, s, 1).  Since this is not normally a forwarded extension, my s rule for it sets an absoluteTimeout (not sure why) and uses a NoOp.  Eventually its t rule does a SoftHangup!

This is an identical problem for MOH.  It seems Parking and MOH both assume that they should use the settings on the destination channel, not the originating one, for hold and callback.

This, IMO, is a real bug that I don't know how to fix.  

This is a real issue for me because I'm trying to sell virtually hosted PBXs and the MOH / Parking break down when you're Parking / Holding / Transferring internal (not always inbound) calls.  Not to mention it messes up the "special hold sound" for helpdesk applications.

While our controlling channels (either incoming channel or an outgoing dial) have a clear idea of what's going on, it seems that our slave channels just hold dummy control data that sometimes gets picked up.  This is probably not desired.  Is it possible to, maybe, have the data always looked up in the control channel?  

Also, right now we set the default moh on a channel in such a way as to control THAT channel.  Most often you don't care about MOH on which channel is reached but rather which channel originates the call.

Put another way, we don't need to set which moh plays when a channel is on hold, but rather which moh plays when a channel puts you on hold.

All of these are vaguely related (different apps assume things about which channel is doing stuff), but should I open a new ticket for the MOH stuff?
</version>
By: Brian West (bkw918) 2004-04-06 00:22:15

is this still an issue?
By: jayson (jayson) 2004-04-09 13:13:19

Yes, very much so.

If you have a system to test on, test parking a call.

If you recieve a call, park it, and wait for the timeout (default 45 seconds, I think), you phone will ring.

If you make a call, park it, and wait for the timeout, the call will be dropped.

Additionally, the same goes for Music On Hold (see bug ASTERISK-1130).

I can't determine a good way to make the same MOH play for my callers for both the case where I call them and they call me.  It effectively makes centrex type arrangements only workable if you dedicate outgoing lines to a certain company (so their MOH is played when they put someone on hold).

Both stem from Asterisk making an assumption for parking and MOH that the application is always dealing with an inbound call, not an outbound call.

This is a very real issue, as it torpedoed sale of an Asterisk PBX for a company that has an existing proprietary system that already does the above, but has the right programming to always ring back the person who did the parking and to play the correct MOH for the person who puts someone on hold.  Right now Asterisk punts by assuming that the person being parked and the person whose Music should be set, is always the slave channel.

I'd be very interested in talking about this, as it is a subtle but very real issue.  I'm currently trying to figure out how best to fix it.  I don't understand the parking code very well, but I've created a pair of ad-hoc apps for SetMOHMaster and SetMOHSlave.
By: Brian West (bkw918) 2004-04-09 21:43:37

I can't recreate this it has to be a config error.
By: jayson (jayson) 2004-04-11 20:25:34

This is definitely not a config error.

I can get the default config to do it.

Here's how *NOT* to test it:

1.  Receive a call (your phone rings)
2.  Park it
3.  Wait for ringback.

This is how to get it:

1.  Make a call (you dial another extension)
2.  Park it
3.  Wait for ringback.

The call should be dropped.
By: jayson (jayson) 2004-04-11 21:05:37

Also, playing devils advocate, how could I misconfigure parking to correctly park a call, wait for the timeout, then magically hang up on the parked party.

FWIW, this is a pure Zaptel system, so I'm not having some sort of ringback connectivity problem with SIP or IAX or anything.

Look res/res_parking.c.

At line 141, when we park the call, we copy the current context/exten/prio from the channel doing the parking.

At line 452, when the timeout occurs, it copies the stored context/exten/prio out of the parking lot into the channel and starts up the pbx to handle them.

If the channel doing the parking was an incoming call, then it has all of this information in chan (a struct *ast_channel passed into the function).

If the channel doing the parking was an outgoing call, then this data is unused, as it is only a slave to the incoming channel.  Look at "show channels" during a call.  Here's an example:

Here it is with the initial call completed (dialed from Zap/27 to Zap/28):

       Channel  (Context    Extension    Pri )   State Appl.         Data      
      Zap/28-1  (outgoing   s     1   )      Up Bridged Call  Zap/27-1  
      Zap/27-1  (macro-stdexten s 2   )      Up Dial      Zap/28r2|20
2 active channel(s)

After parking Zap/28, here's the channel state (on an incoming call, Zap/27 would be parked):

pbx*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data      
      Zap/28-1  (outgoing   s     1   )      Up Parked Call   (None)    
1 active channel(s)

Notice that the channel data is modified to show that it is parked.  If you note the previous example, the data that was saved from this channel is simply that channels default outgoing settings.  This is defaulted at channel init and left that way because ast_start_pbx is never called on this channel (since it is never actually dialed at all).

When the timeout occurs, the bogus data on the channel that was saved is copied back, and it is dumped into that outgoing extension (note that it uses the s rule which is not normally even configured for most people, as it is an outgoing context that has dial-tone instead of starting to handle things).

In my case, it quickly goes to this:

       Channel  (Context    Extension    Pri )   State Appl.         Data      
      Zap/28-1  (outgoing   t            2   )      Up (None)        (None)    
1 active channel(s)

Note that it is the bogus context's timeout extension (since there is nothing in the default, it just waits and then times out.

If you need to talk to me about this, call me.  E-mail me and I'll send you my phone number (didn't want to put it in public record here).

If we can solve this, it would be a very good thing.

I encountered this replacing a PBX that had phones with buttons for each incoming line.  I showed our people that you could use parking just like putting someone on hold to switch phones.

I had quite a bit of embarrassment tracking down the problems when we mysteriously started losing calls to our remote sales reps.  Our people would dial out to them, park them to change phones on their way back to shipping, then find out that they mysteriously disappeared.  I was even more surprised when I figured out it wasn't my fault.
By: Brian West (bkw918) 2004-04-12 13:15:44

Are you using macros?
if so try to not use them and park.  This could be a macro bug.  Also paste the console output when the call is dropped.

bkw
By: jayson (jayson) 2004-04-13 15:57:21

No macros.

The calls aren't getting dropped.  I thought they were, at first.  They get sent to a bogus extension (which can seem to be the same thing).  The mechanism that remembers what extension to dial-back

I've been able to get this behavior with the following:

zapata.conf:

context=a
channel => 1
context=b
channel => 2

extensions.conf:

[a]
include => parkedcalls
exten => 2,1,Dial(Zap/2)
exten => s,1,Background(tt-monkeys)

[b]
include => parkedcalls
exten => 2,1,Dial(Zap/1)
exten => s,1,Background(tt-weasels)

default parking.conf


Specifically, when Zap/2 (in context b) calls Zap/1, I get a ring.  Zap/1 answers, we chat.  Zap/2 parks the call, I get the following from show channels.

pbx*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/1-1   (a          s            1   )      Up BackGround    tt-monkeys
1 active channel(s)

After the timeout, it shows this, without having even rung me back:
pbx*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
      Zap/1-1   (a          s            1   )      Up BackGround    tt-monkeys
1 active channel(s)

This only occurs when you park a call you've originated.  There is an assumption made by the parking code that you only park a call that came in, not one going out.
By: jharragi (jharragi) 2004-04-14 09:33:31

Just a footnote that may affect your issue. Recent changes have changed the properties of rxflash and maybe flash in zapata.conf. A long while back I needed to play with these then never gave them a thought. A new cvs caused flash to drop calls. Commenting those lines fixed it.
By: Mark Spencer (markster) 2004-04-15 01:04:21

There's not a good way to know where to send a ringback on a call parked by someone who placed the call.
By: jayson (jayson) 2004-04-15 12:44:39

Why not Dial/(Channel)?

I know we don't have a full context,extension,priority to use.  Right now it looks like we store this and just restart it for ringback.  Correct me if I'm wrong but doesn't this have strange side effects (like ringing back someone who's busy could send the call into voicemail depending on your config)?

Can we fake a Dial to the channel that did the parking?

If not, can we at least document how this works so that people don't get surprised?
By: jayson (jayson) 2004-04-15 12:47:05

For that matter, if we aren't going to fix this problem, should we log a warning to the console or maybe play an error message?
By: Brian West (bkw918) 2004-04-30 00:34:22

Be on the look out for new parking goodies if I can get marks attention to give me and tony input for a few  :)  He has already said he would.  But this isn't a bug.