Asterisk
  1. Asterisk
  2. ASTERISK-7240

[patch] Parked call fails to return to extension that parked it after a timeout

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Target Release Version/s: None
    • Component/s: Resources/res_features
    • Labels:
      None
    • Mantis ID:
      7435
    • Regression:
      No

      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.

      1. debug.parking
        41 kB
      2. patch2.txt
        0.9 kB
      3. res_features.c.patch.txt
        3 kB
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        k-egg created issue -
        Hide
        crich added a comment -

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

        Show
        crich added a comment - If Number is not given, how should chan_misdn know which phone it should dial ?? Also please add a trace of the situation.
        Hide
        Serge Vecher added a comment -

        also, latest Asterisk release is 1.2.9.1

        Show
        Serge Vecher added a comment - also, latest Asterisk release is 1.2.9.1
        Hide
        k-egg added a comment -

        i added a debug session

        Show
        k-egg added a comment - i added a debug session
        Hide
        k-egg added a comment -

        @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...

        Show
        k-egg added a comment - @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...
        Hide
        crich added a comment -

        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..

        Show
        crich added a comment - 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..
        Hide
        Steven BerkHolz added a comment -

        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.

        Show
        Steven BerkHolz added a comment - 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.
        Hide
        Steven BerkHolz added a comment -

        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.

        Show
        Steven BerkHolz added a comment - 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.
        Hide
        crich added a comment -

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

        Show
        crich added a comment - If this issue is present on T1/E1 Trunks it looks like its an res_features issue, not a chan_misdn issue.
        Hide
        k-egg added a comment -

        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.

        Show
        k-egg added a comment - 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.
        Hide
        k-egg added a comment -

        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?

        Show
        k-egg added a comment - 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?
        Hide
        crich added a comment -

        k-egg:

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

        Show
        crich added a comment - k-egg: that's for sure the right way how you should push this problem. keep going on like that.
        Hide
        crich added a comment -

        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).

        Show
        crich added a comment - 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).
        Hide
        k-egg added a comment -

        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?

        Show
        k-egg added a comment - 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?
        Hide
        k-egg added a comment -

        so any ideas what to do?

        Show
        k-egg added a comment - so any ideas what to do?
        Hide
        Serge Vecher added a comment -

        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)?

        Show
        Serge Vecher added a comment - 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)?
        Hide
        k-egg added a comment -

        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.

        Show
        k-egg added a comment - 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.
        Hide
        Serge Vecher added a comment -

        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?

        Show
        Serge Vecher added a comment - 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?
        Hide
        Serge Vecher added a comment -

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

        Show
        Serge Vecher added a comment - I'm also changing this to 'minor' as this affects only a small portion of calls and does not impact chan_misdn performance overall.
        Hide
        k-egg added a comment -

        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

        Show
        k-egg added a comment - 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
        Hide
        crich added a comment -

        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 ?

        Show
        crich added a comment - 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 ?
        Hide
        k-egg added a comment -

        okay, were on the run

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

        Show
        k-egg added a comment - okay, were on the run look into res_features for chan->name or chan-> exten
        Hide
        crich added a comment -

        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.

        Show
        crich added a comment - 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.
        Hide
        k-egg added a comment -

        so who can move this to res_features?

        Show
        k-egg added a comment - so who can move this to res_features?
        Hide
        Steven BerkHolz added a comment -

        I think that this bug should be moved.

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

        Show
        Steven BerkHolz added a comment - I think that this bug should be moved. I am sure that OEJ could figure out why it works like that.
        Hide
        k-egg added a comment -

        move anyone??

        Show
        k-egg added a comment - move anyone??
        Hide
        Serge Vecher added a comment -

        maybe crich likes this bug to be in mISDN category

        Show
        Serge Vecher added a comment - maybe crich likes this bug to be in mISDN category
        Hide
        Serge Vecher added a comment -

        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.

        Show
        Serge Vecher added a comment - 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.
        Hide
        Steven BerkHolz added a comment -

        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.

        Show
        Steven BerkHolz added a comment - 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.
        Hide
        crich added a comment -

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

        Show
        crich added a comment - I've tested that on the 1.2 branch revision: 36289
        Hide
        k-egg added a comment -

        @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

        Show
        k-egg added a comment - @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
        Hide
        crich added a comment -

        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 ?

        Show
        crich added a comment - 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 ?
        Hide
        Serge Vecher added a comment -

        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.

        Show
        Serge Vecher added a comment - 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.
        Hide
        Steven BerkHolz added a comment -

        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

        Show
        Steven BerkHolz added a comment - 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
        Hide
        k-egg added a comment -

        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

        Show
        k-egg added a comment - 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
        Hide
        Steven BerkHolz added a comment -

        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.

        Show
        Steven BerkHolz added a comment - 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.
        Hide
        k-egg added a comment -

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

        Show
        k-egg added a comment - So i think the Dial() command is not concattenated the right way, but this is only my 2 cents
        Hide
        crich added a comment -

        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.

        Show
        crich added a comment - 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.
        Hide
        k-egg added a comment -

        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

        Show
        k-egg added a comment - 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
        Hide
        k-egg added a comment -

        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?

        Show
        k-egg added a comment - 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?
        Hide
        crich added a comment -

        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..

        Show
        crich added a comment - 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..
        Hide
        k-egg added a comment -

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

        Show
        k-egg added a comment - it was an internal call so, it must have been fxs, right?
        Hide
        Serge Vecher added a comment -

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

        Show
        Serge Vecher added a comment - alright, I don't see a reason for this bug to be open. Please continue testing junky's solution in 6953. Thanks.
        Hide
        Clod Patry added a comment -

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

        Show
        Clod Patry added a comment - Since ASTERISK-6769 is a solution to control what to do after a parkedcall timeout, this bug is more appropriate for k-egg.
        Hide
        k-egg added a comment -

        thx, for reopening

        Show
        k-egg added a comment - thx, for reopening
        Hide
        Clod Patry added a comment -

        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.

        Show
        Clod Patry added a comment - 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.
        Hide
        k-egg added a comment -

        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".

        Show
        k-egg added a comment - 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".
        Hide
        k-egg added a comment -

        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)

        Show
        k-egg added a comment - 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)
        Hide
        k-egg added a comment -

        any new ideas on this?

        Show
        k-egg added a comment - any new ideas on this?
        Hide
        jmls added a comment -

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

        Show
        jmls added a comment - junky, is there anything else we can do on this one ?
        Hide
        k-egg added a comment -

        any new ideas?

        Show
        k-egg added a comment - any new ideas?
        Hide
        Clod Patry added a comment -

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

        Show
        Clod Patry added a comment - im in a real rush with my end of semester, will be in touch soon.
        Hide
        jlimb added a comment -

        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.

        Show
        jlimb added a comment - 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.
        Hide
        k-egg added a comment -

        ahm ja, feedback, mine?

        Show
        k-egg added a comment - ahm ja, feedback, mine?
        Hide
        crich added a comment -

        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.

        Show
        crich added a comment - 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.
        Hide
        k-egg added a comment -

        @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.

        Show
        k-egg added a comment - @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 .
        Hide
        Michiel van Baak added a comment -

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

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

        Show
        Michiel van Baak added a comment - No reports/tests done on 1.4 and/or trunk. Closing. If this is still relevant in 1.4 and/or trunk reopen.
        Erin Spiceland made changes -
        Field Original Value New Value
        issue.field.mantisimportkey 7435 31008
        Erin Spiceland made changes -
        Workflow jira [ 72828 ] Subtask and Courtesy Workflow [ 99527 ]

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: