[Home]

Summary:ASTERISK-07240: [patch] Parked call fails to return to extension that parked it after a timeout
Reporter:k-egg (k-egg)Labels:
Date Opened:2006-06-27 11:25:12Date Closed:2007-09-12 11:11:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) debug.parking
( 1) patch2.txt
( 2) res_features.c.patch.txt
Description:When I park a call using ASTERISK-694

the call does not come back after the timeout

== Timeout for Zap/7-1 parked on 701. Returning to park-dial,mISDN/1,1

misdn needs mISDN/port/number, but number is not given.
Comments:By: crich (crich) 2006-06-27 11:29:21

If Number is not given, how should chan_misdn know which phone it should dial ?? Also please add a trace of the situation.

By: Serge Vecher (serge-v) 2006-06-27 11:38:05

also, latest Asterisk release is 1.2.9.1

By: k-egg (k-egg) 2006-06-27 11:44:59

i added a debug session

By: k-egg (k-egg) 2006-06-27 11:48:03

@crich at least this is my question, i don't know why but NO number is given
i use ASTERISK-694, park and i dont know why this aplication does not give a numer
i have no chance to give a numer; wher should i doo
parking is a feature (or is it a bug) so i cant do anything...

By: crich (crich) 2006-06-27 12:25:38

A short look into the parking code told me that on the position where now mISDN/1 is standing, the dialed extension should be.

In your trace it looks like:

Timeout for Zap/7-1 parked on 701. Returning to park-dial,mISDN/1,1

but if the number was lets say 123 it should look like:

Timeout for Zap/7-1 parked on 701. Returning to park-dial,123,1

for some reason the Extension is overwritten..

By: Steven BerkHolz (steveb) 2006-06-27 14:49:42

This issue is also seen on T1 and PRI trunks.
The parking app stores the channel, not any CallerID, etc.
Once the parker hangs up, channel 1 on your mISDN, or T1 or PRI has no extension assigned to it.

My temp workaround was to hard code my front desk into res_features.c so that ALL parked calls will timeout to the receptionist.
This also affects parking by SIP, etc., so I would rather have one of the below methods.

I can post it if desired, but it does not solve your root issue.

What I would like to see is either:
1. Use callerID instead of parking channel to timeout to.
or
2. Some kind of code to detect the rejection (I do not think that chanisavail will work) and if rejected, timeout to a preset extension.



By: Steven BerkHolz (steveb) 2006-06-27 14:56:50

1. Example for "Use callerID instead of parking channel to timeout to."

Call comes in from legacy PBX or maybe even an outside caller (or cell) 2485551212.
The call comes in on channel Zap/15.
When the park times out, send it back to 2485551212 since Zap/15 will not succeed.
This logic should not break SIP, IAX, etc. if all extensions have callerID.

2. Example for "Some kind of code to detect the rejection (I do not think that chanisavail will work) and if rejected, timeout to a preset extension."

Call comes in from legacy PBX or maybe even an outside caller (or cell) 2485551212.
The call comes in on channel Zap/15.
When the park times out, try to send it to Zap/15.
If it is rejected, do not hang up, but send it to ext. 0 (predefined extension, mine is 5100)
This logic should not break SIP, IAX, etc. since the transfer will suceed.

By: crich (crich) 2006-06-27 15:06:12

If this issue is present on T1/E1 Trunks it looks like its an res_features issue, not a chan_misdn issue.

By: k-egg (k-egg) 2006-06-27 16:16:56

i'm not a code guru so, i dont realy know where the issu is related to. but what i know is, that parking does not work, but it should!

so anybody should look in that stupid code wher chan->name is given to chan->exten or what the hell. and why in the chan name the MSN is not stored. and on which position the damn code has to be altered.

that shouldnt be magic.  

Give it a try, somebody out there should know whats going on there.

By: k-egg (k-egg) 2006-06-27 16:20:21

i dont know whre the channels are created, but i think, chan_misdn is the point, when a new isdn Chan is created, and so i think, the issu is still on mISDN.
correct me if i'm wrong

btw, has anybody tried call parking with that other driver?

By: crich (crich) 2006-06-27 16:20:46

k-egg:

that's for sure the right way how you should push this problem. keep going on like that.

By: crich (crich) 2006-06-27 16:22:59

btw. chan_misdn does not spontaneausly create channels.

They are either initially created by an Isdn-Side event like an incoming call. Or by an Asterisk Side event like a dial (or a redial from a timed out parked call).

By: k-egg (k-egg) 2006-06-28 03:35:44

Sorry for beeing so abusive.

for me it seems solving the problem couldnt be that hard.
i'm new to asterisk, and new to the code of asterisk. i dont know which part of the code is doing these or that (internally).

but with my little understanding of the code, there is a problem with chan->name and isdn. it should not only contain the name, but also the msn of the chan it came from. but it does not. i dont know which, code snipped is responsible for that task. maybe we should move the bug somewhere else?

By: k-egg (k-egg) 2006-06-28 06:29:27

so any ideas what to do?

By: Serge Vecher (serge-v) 2006-06-28 08:55:07

k-egg: can you please describe your problem in more detail, including steps to reproduce it? Also, did you try the latest release (1.2.9.1)?

By: k-egg (k-egg) 2006-06-28 09:34:48

okay, the problem is simple.

i have an internal ISDN Card 4S0 from beronet

in features i enabled call parking, so that i can park a call using ASTERISK-694
i produce a call which is signalled at my ISDN phone.
i pick the call up, talk to (myself) and then park the call pressing ASTERISK-694
a nice girl says, that the call is parked in 701

no problems so far.
if i pick up the call at 701, no problems either.

if i "forget" the call in the parking lot, and the 45 seconds default limit for a call to stay in parking lot are reached, the call tries to come back to my isdn phone. Problems begin here!

when the parked call tries to come back he uses DIAL.
since the call dials an mISDN "device" a DIAL command must look like this
DIAL(mISDN/port/number)

But the parked call does not know from which msn he was parked. nobody said him.
(nobody == the parking application i guess)

I my opinion misdn should have given the information from what msn the call was parked to the parking application. who else could do this?


since the parked call does not know where to come back, or in other words, uses to few arguments in the dial command [DIAL (mISDN/port) ], the DIAL dies/fails.
producing that error

== Timeout for Zap/7-1 parked on 701. Returning to park-dial,mISDN/1,1

where mISDN/1 is tech/port and ",1" is not the msn, but the priority.

@vechers is the scenario understandable? not sure if i forgot anything.
no didnt use 1.2.9.1 i'm happy whith my 1.2.7.1 installation so far. dont will use iax, so no need for me to update.



By: Serge Vecher (serge-v) 2006-06-28 09:55:59

k-egg: thanks for clarification; it makes sense now. If you don't mind, I'll update the title, as I think the current one is not reflective of what's happening.

In my testing, if I park a SIP call, it will come back to the extension that parked it after a timeout. That's the behaviour you want, k-egg, but with chan_misdn, right? Perhaps the solution then is to look at how chan_sip handles this in function sip_park and see what needs to change in chan_misdn?

By: Serge Vecher (serge-v) 2006-06-28 10:00:32

I'm also changing this to 'minor' as this affects only a small portion of calls and does not impact chan_misdn performance overall.

By: k-egg (k-egg) 2006-06-28 10:17:39

i think you are used to bug reporting, so feel free to change the title and the "urgency". (but indeed it's urgent to me, and affects a whole bunch of my work at the moment)

<quote>
In my testing, if I park a SIP call, it will come back to the extension that parked it after a timeout. That's the behaviour you want, k-egg, but with chan_misdn, right?
</quote>

fullack!

i looked a little after the code for handling this. its in res_fetures i think, but i'm not that involved in the code to solve the problem.

so it wold be kind of anybody here to look at that issu.

thx



By: crich (crich) 2006-06-28 11:54:58

I have tried to make the same test here, and indeed this seems to be an issue, the following Log with Verbosity 4 shows the problem very clearly:

   -- mISDN/5-u18 answered mISDN/5-1
   -- Attempting native bridge of mISDN/5-1 and mISDN/5-u18
   -- Started music on hold, class 'default', on channel 'mISDN/5-1'
   -- Playing 'pbx-transfer' (language 'de')
   -- Stopped music on hold on mISDN/5-1
   -- Started music on hold, class 'default', on channel 'mISDN/5-1'
 == Parked mISDN/5-1 on 701. Will timeout back to extension [Intern] 15, 1 in 5 seconds
   -- Added extension '701' priority 1 to parkedcalls
   -- Playing 'digits/7' (language 'de')
   -- Playing 'digits/0' (language 'de')

*CLI>
*CLI>
   -- Playing 'digits/1' (language 'de')
 == Spawn extension (Intern, 15, 1) exited KEEPALIVE on 'mISDN/5-1'
   -- Stopped music on hold on mISDN/5-1
   -- Added extension 'mISDN/5' priority 1 to park-dial
 == Timeout for mISDN/5-1 parked on 701. Returning to park-dial,mISDN/5,1
   -- Executing Dial("mISDN/5-1", "mISDN/5||t") in new stack
Jun 28 18:29:26 WARNING[14325]: chan_misdn.c:4522 chan_misdn_log: misdn_call: No Extension given!
   -- Couldn't call 5
 == Everyone is busy/congested at this time (0:0/0/0)
Jun 28 18:29:37 WARNING[14325]: pbx.c:2415 __ast_pbx_run: Timeout, but no rule 't' in context 'park-dial'


The Interesting part is:

== Parked mISDN/5-1 on 701. Will timeout back to extension [Intern] 15, 1 in 5 seconds

res_features parks this call in the parking lot, it stores the Context, Extension and Priority in the parkin_lot entry, which is quite OK, since this priority+Extension+Context created the original call.


Now what happens after the timeout:

== Spawn extension (Intern, 15, 1) exited KEEPALIVE on 'mISDN/5-1'
   -- Stopped music on hold on mISDN/5-1
   -- Added extension 'mISDN/5' priority 1 to park-dial
 == Timeout for mISDN/5-1 parked on 701. Returning to park-dial,mISDN/5,1
   -- Executing Dial("mISDN/5-1", "mISDN/5||t") in new stack

"something" (i didn't found out yet which part of the code does it) adds an extension to the park-dial context which dials chan_misdns channel just on a Port without the original extension, this does not work on chan_misdn, but it would work on Analog Lines or Sip Phones.

The same will not work on parked calls on Zap Pri Lines!


I wonder why not the originally stored contex+extension+priority is used to generate the call? why do we create an extension to the park-dial context to make this call ?

By: k-egg (k-egg) 2006-06-28 12:00:24

okay, were on the run

look into res_features for chan->name or chan-> exten

By: crich (crich) 2006-06-28 13:05:15

The problem can easily been seen here:


ast_park_call() :
..
       if (peer)
               ast_copy_string(pu->peername, peer->name, sizeof(pu->peername));
..


in ast_park_call we consider peer == mISDN/<port> as the one, we did call in the first place who parked us! (we also save by the way the context+extension+priority)

do_park_thread():
...

if (tms > pu->parkingtime) {
                               /* Stop music on hold */
                               ast_moh_stop(pu->chan);
                               ast_indicate(pu->chan, AST_CONTROL_UNHOLD);
                               /* Get chan, exten from derived kludge */
                               if (pu->peername[0]) {
                                       peername = ast_strdupa(pu->peername);
;                                       cp = strrchr(peername, '-');
                                       if (cp)
                                               *cp = 0;
                                       con = ast_context_find(parking_con_dial);
                                       if (!con) {
                                               con = ast_context_create(NULL, parking_con_dial, registrar);
                                               if (!con) {
                                                       ast_log(LOG_ERROR, "Parking dial context '%s' does not exist and unable to create\n", parking_con_dial);
                                               }
                                       }
                                       if (con) {
                                               snprintf(returnexten, sizeof(returnexten), "%s||t", peername);
                                               ast_add_extension2(con, 1, peername, 1, NULL, NULL, "Dial", strdup(returnexten), FREE, registrar);
                                       }
                                       ast_copy_string(pu->chan->exten, peername, sizeof(pu->chan->exten));
                                       ast_copy_string(pu->chan->context, parking_con_dial, sizeof(pu->chan->context));
                                       pu->chan->priority = 1;

                               } else {
                                       /* They've been waiting too long, send them back to where they came.  Theoretically they
                                          should have their original extensions and such, but we copy to be on the safe side */
                                       ast_copy_string(pu->chan->exten, pu->exten, sizeof(pu->chan->exten));
                                       ast_copy_string(pu->chan->context, pu->context, sizeof(pu->chan->context));
                                       pu->chan->priority = pu->priority;
                               }

...


in do_park_thread we check if pu->peername is strlen >0, then we make a dial like: dial( peername ), this works indeed for sip/analog zap but not for chan_misdn or zap pri lines.

Interestingly if pu->peername would be strlen == 0 we would try to go back where we initially came from like context+extension+priority which would work for any case sip/zap/misdn.

I consider this not as a bug of chan_misdn but as a bug of res_features, so we should move it there. A fix would be very easy, but i assume there is a reason for why it is like it is, i'd like to know it.

By: k-egg (k-egg) 2006-06-28 15:04:06

so who can move this to res_features?

By: Steven BerkHolz (steveb) 2006-06-28 15:05:28

I think that this bug should be moved.

I am sure that OEJ could figure out why it works like that.

By: k-egg (k-egg) 2006-06-29 05:23:11

move anyone??

By: Serge Vecher (serge-v) 2006-06-29 08:53:49

maybe crich likes this bug to be in mISDN category ;)

By: Serge Vecher (serge-v) 2006-06-29 08:57:04

k-egg, steveb: I still need you to test this on 1.2.9.1. If you look at a change log between 1.2.7.1 and 1.2.8, there have been numerous bugs fixed there, not just that pesky IAX2 DoS stuff.

By: Steven BerkHolz (steveb) 2006-06-29 09:17:30

I have this problem on 1.2.9.1.

If the call is parked from Zap channel 47 from callerID 2485551212, the timed out call will be sent Zap channel 47.

The problem is that Zap channel 47 is a trunk to another system (not an extension), so the call is lost.

k-egg, I hope you do not think that I am stomping on your bug/enhancement.
I believe that we have the same issue and any fix will benifit both Zap and mISDN trunks.

By: crich (crich) 2006-06-29 09:24:57

I've tested that on the 1.2 branch revision: 36289

By: k-egg (k-egg) 2006-06-29 09:41:39

@vechers: have i to test anymore?, i wouldn't like to switch to 1.2.9.1 because of, hm ahmm, cause i dont't want. and i have no other machine to test on. sry for not beeng a very patient persen. i'm a very impetuous person :)



By: crich (crich) 2006-06-29 11:57:24

that patch removes the peername stuff. It should work for all the technologies with the original behaviour. Haven't tested it really though.

I would still like to know why the peername stuff is there anyway ?

By: Serge Vecher (serge-v) 2006-06-29 13:40:14

k-egg: no need to try 1.2.9.1 unless crich's patch does not apply cleanly to 1.2.7.1. If the patch does not apply, you have no choice but to update to latest svn 1.2 and test the patch.

crich: perhaps kevin would know the answer -- I would email the asterisk-dev list, this way oej also sees it. Thanks.

By: Steven BerkHolz (steveb) 2006-06-29 15:36:26

The only reference that I ever saw about it is in http://bugs.digium.com/view.php?id=4036

And it looks like it was added in http://svn.digium.com/view/asterisk/trunk/res/res_features.c?r1=4399&r2=4413
Fixed call parking, added separate paramater to allow/disallow call parking on
Zaptel interfaces (canpark=yes/no in zapata.conf), added urlbase paramater to
Monitor so that a url can optionally be included in CDR (user field), cleaned up a couple of minor things



By: k-egg (k-egg) 2006-06-30 04:07:52

Okay, after patching res_features.c
patch < res_features.c.patch.txt
i get:
patching file res_features.c
Hunk #3 succeeded at 1475 (offset -8 lines).
Hunk #4 succeeded at 1503 (offset -8 lines).

make clean &&make && make intstall && asterisk -cvvvp && trying the test scenario produces following:

 -- Zap/7-1 answered mISDN/1-u0
   -- Started music on hold, class 'default', on channel 'Zap/7-1'
   -- Playing 'pbx-transfer' (language 'de')
   -- Stopped music on hold on Zap/7-1
   -- Started music on hold, class 'default', on channel 'Zap/7-1'
 == Parked Zap/7-1 on 701. Will timeout back to extension [analog-7] s, 1 in 45 seconds
   -- Added extension '701' priority 1 to parkedcalls
   -- Playing 'digits/7' (language 'de')
   -- Playing 'digits/0' (language 'de')
   -- Playing 'digits/1' (language 'de')
   -- Stopped music on hold on Zap/7-1
 == Timeout for Zap/7-1 parked on 701. Returning to analog-7,s,1
 == Starting Zap/7-1 at analog-7,s,1 failed so falling back to exten 's'
 == Starting Zap/7-1 at analog-7,s,1 still failed so falling back to context 'default'



still on *ast* 1.2.7.1

By: Steven BerkHolz (steveb) 2006-06-30 07:47:57

I did this last night as well on 1.2.9.1.

The patch makes it go to channel/s/1.
the channel is NOT an extension, the the callback fails.

The goal is to have the callerid or MSN recorded and used for the callback.



By: k-egg (k-egg) 2006-06-30 09:07:31

So i think the Dial() command is not concattenated the right way, but this is only my 2 cents ;)

By: crich (crich) 2006-07-04 05:11:11

I've tried the second patch which works for me when using either mISDN or Zap (analog) I don't have a PRI Line to test the Zap PRI case here, but it should work as well.

By: k-egg (k-egg) 2006-07-05 10:17:43

tja, nothing at all witch patch2.txt
using asterisk 1.2.7.1



== Parked Zap/7-1 on 701. Will timeout back to extension [analog-7] s, 1 in 45 seconds
   -- Added extension '701' priority 1 to parkedcalls
   -- Playing 'digits/7' (language 'de')
   -- Playing 'digits/0' (language 'de')
   -- Playing 'digits/1' (language 'de')
 == Spawn extension (macro-stdexten, s-NoCFWD, 2) exited non-zero on 'mISDN/8-1' in macro 'stdexten'
 == Spawn extension (macro-stdexten, s-NoCFWD, 2) exited non-zero on 'mISDN/8-1'
   -- Stopped music on hold on Zap/7-1
 == Timeout for Zap/7-1 parked on 701. Returning to analog-7,s,1
 == Starting Zap/7-1 at analog-7,s,1 failed so falling back to exten 's'
 == Starting Zap/7-1 at analog-7,s,1 still failed so falling back to context 'default'
   -- Executing Macro("Zap/7-1", "invalid") in new stack
   -- Executing Answer("Zap/7-1", "") in new stack
   -- Executing Playback("Zap/7-1", "tt-monkeys") in new stack
   -- Playing 'tt-monkeys' (language 'de')
   -- Executing Hangup("Zap/7-1", "") in new stack

By: k-egg (k-egg) 2006-07-05 10:21:55

i don't get what the patches alter on the dial behavior, but okay,
you are familiar with that stuff.

crich: did you try the patch on an 1.2.9 version?
maybe somthing in trunk alterd?

By: crich (crich) 2006-07-05 10:25:37

Are you testing with an fxo analog line or with an fxs line? I've tested an Analog Phone connected to the fxs port of the tdm400 and it worked..

By: k-egg (k-egg) 2006-07-05 11:31:22

it was an internal call so, it must have been fxs, right?

By: Serge Vecher (serge-v) 2006-09-01 14:01:03

alright, I don't see a reason for this bug to be open. Please continue testing junky's solution in 6953. Thanks.

By: Clod Patry (junky) 2006-09-04 18:19:06

Since ASTERISK-6769 is a solution to control what to do after a parkedcall timeout, this bug is more appropriate for k-egg.

By: k-egg (k-egg) 2006-09-05 02:30:40

thx, for reopening ;)

By: Clod Patry (junky) 2006-09-05 05:52:00

could you attach ur dialplan and features for debbug ur problem.
Also, make sure isnt working working for 1.2.11, which is the latest stable release.

By: k-egg (k-egg) 2006-09-06 08:19:01

plz, no sentences like, "can you test, if it works on 1.2.XX" or "use latest from trunk", cause i'm allergic to them. it allways costs me half a day to compile a new version so...
Since it did not work on 1.2.7.1 nor on 1.2.9[.1] nor does it work on 1.2.10,
i dont belive it will be different in 1.2.11

so it would be kind of you junky, if you would use a pri or a mISDN card. and reconstruct that behavior,yourself.

no i will not send dialplan or features cause it depends on the code, not on configs; as you can see, when you follow the bugnotes.
callbacktoorigin is not findable in my featuresconf.


i'm a little bit tired following this bug... so don't blame me for my words.
everything is here and should be clear. THE only problem is, that the MSN is not stored anywhere... so the call cannot come back.

This is an isdn problem and isdn is a "poor cousin".

By: k-egg (k-egg) 2006-09-07 04:29:47

so as i sayed, 1.2.11 changes nothing!!

   -- Stopped music on hold on mISDN/8-u0
   -- Registered extension context 'park-dial'
   -- Added extension 'mISDN/1' priority 1 to park-dial
 == Timeout for mISDN/8-u0 parked on 701. Returning to park-dial,mISDN/1,1
   -- Executing Dial("mISDN/8-u0", "mISDN/1||t") in new stack
P[ 0] misdn_call: No Extension given!
   -- Couldn't call 1
 == Everyone is busy/congested at this time (0:0/0/0)

By: k-egg (k-egg) 2006-09-18 04:39:38

any new ideas on this?

By: jmls (jmls) 2006-11-01 12:42:09.000-0600

junky, is there anything else we can do on this one ?

By: k-egg (k-egg) 2006-12-11 04:49:24.000-0600

any new ideas?

By: Clod Patry (junky) 2006-12-11 06:22:33.000-0600

im in a real rush with my end of semester, will be in touch soon.

By: jlimb (jlimb) 2006-12-22 20:33:30.000-0600

this may or may not be related:
when I use the builtin attended transfer (atxfer in features.conf) it will not return to the person who did the attended transfer but rather tries to return to the extension they are parked on.  The parked caller hears the extension they are parked at (such as "71" or "701") when the time out expires and I believe would remain parked indefinitely.

By: k-egg (k-egg) 2007-02-26 15:03:27.000-0600

ahm ja, feedback, mine?

By: crich (crich) 2007-02-26 15:14:29.000-0600

k-egg, could you have a look at bug ASTERISK-6769, it might solve your issue, it looks like this one here is a duplicate of ASTERISK-6768 so we might close this one here.

By: k-egg (k-egg) 2007-02-26 16:21:34.000-0600

@crich, sry, no idea what to do now...

taken from ASTERISK-7240:

>(0051185)
>k-egg - reporter
>09-04-06 02:52
>
> as ASTERISK-7240 is closed for now, i want to keep in mind, that parkedcalls >still fail to return to the extension that parked it after a timeout using PRI >or mISDN
>
>
>(0051209)
>junky - manager
>09-04-06 18:20
>
> k-egg: follow ur bug at ASTERISK-7240.

By: Michiel van Baak (mvanbaak) 2007-09-12 11:11:01

No reports/tests done on 1.4 and/or trunk.
Closing.

If this is still relevant in 1.4 and/or trunk reopen.