[Home]

Summary:ASTERISK-10449: When parking lot ring back times out, error is generated, line is hung up and timeout extension isn't reached.
Reporter:Ken Williams (kenw)Labels:
Date Opened:2007-10-04 18:28:40Date Closed:2008-04-22 18:31:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) CLI-100407.txt
( 1) CLI-canreinvite-NO.txt
( 2) extensions.conf
( 3) features.conf
( 4) full100407.txt
( 5) FULL-canreinvite-NO.txt
( 6) sip.conf
Description:The situation is repeated as follows:

1. Call is placed into parking lot
2. Call timesout from parking lot and rings back extension that put it there to begin with
3. After ~50 seconds of ringing back to extension that placed the call in the parking lot, the [park-dial] 't' extension should be invoked, instead the following errors show up in the Asterisk-CLI:

[Oct  4 17:22:47] WARNING[7986]: chan_sip.c:12037 handle_response_invite: Re-invite to non-existing call leg on other UA. SIP dialog '224fe567089888351edffad76cdf16d9@10.200.26.202'. Giving up.
[Oct  4 17:38:18] WARNING[7986]: chan_sip.c:12536 handle_response: Remote host can't match request CANCEL to call '4c93b03d7f87f05950d21bd971edd97b@10.200.26.202'. Giving up.

I'm not sure if this is a parking lot or SIP issue, but beings the errors are from chan_sip.c I chose SIP Transfers.

I've attached CLI with debug & verbose set to 4 as well as sip debug enabled.  I've also attached the parts of features.conf, extensions.conf & sip.conf that apply.  Problem was noticed in 1.4.10.1, upgrade to 1.4.12 made no difference.

(1.4.12 not an option on Asterisk version btw).
Comments:By: Ken Williams (kenw) 2007-10-04 18:45:59

Couple things I should've added:

1. canreinvite doesn't matter set to yes or no
2. Whether the call originates on zap or sip, same error results, all phones are sip but we have zaptel coming in from pstn.
3. Tried quite a few things with [parkedcalls] [park-dial] and my [from-internal] contexts that I pray this isn't a configuration issue.  I've followed what other people are supposedly doing but still having the issue.

Happy to answer any other questions.
By: Joshua C. Colp (jcolp) 2007-10-05 10:09:54

While you said canreinvite=no makes no difference can you please upload a trace with it?
By: Ken Williams (kenw) 2007-10-05 15:33:28

Here ya go, hope these help.  I restarted the server after changing the CANREINVITE to no, then followed the same steps listed above.
By: Doug (doug) 2007-10-10 03:08:45

I have a similar issue when using parking with Snom (300) and park orbit. I gat an error:

[Oct 10 09:11:53] WARNING[28870]: chan_sip.c:12532 handle_response: Remote host can't match request BYE to call '73fbb5f44f3860f160abb25e3990b0c1@192.168.21.203'. Giving up.

This creats SIP channels that remain in a "unknown" state:

192.168.21.76    5006        30ba51e62f2  00152/00001  unkn  No       Tx: BYE         Request se
192.168.21.76    5006        333d561e781  00217/00001  unkn  No       Tx: BYE         Request se


Eventualy there will be many of these channels and Asterisk will stop allowing calls to the extensions, or Asterisk will crash due to to many of these channels.

We have the same issue on Ver 1.4.11 and 1.4.12

Note: This problem does not happen when using transfer to the park extension, i.e. transfer to ASTERISK-694


By: Doug (doug) 2007-10-10 04:12:19

After futher testing it seems that this problem happens only when a call has timed out from the parking app.

we have also updated firmware on Snom to 6.5.12 and have not had a problem since but we will keep monitoring as i believe this problem lies with Asterisk.
By: Doug (doug) 2007-10-10 07:10:46

Ok getting to the bottem of this seems that it has to do with parking timeout, if we set the failover time to a very high value i.e. 9999999 I have not seen a problem yet so guess this is where the "Bye" problem comes from.
By: jharragi (jharragi) 2007-10-30 15:08:37

I've been getting a related error. I am merely reporting my observations. If I get an opportunity to collect better cli output I will. Unfortunatly, this would not be a good machine to compile debug & get a core dump.

[Oct 30 13:14:50] WARNING[3917] chan_sip.c: Remote host can't match request BYE to call '1ca86cc074fbe2ba2fee44ee7f736bb6@10.0.9.7'. Giving up.

...the condition that generated this repeated message had an interesting sideffect. A user reported that her cisco 7912 couldn't make calls. I was testing it by calling my cell phone from the 7912. Before during and after ringing, choppy audio (but recognisable as a menu recording from a different asterisk box at another of my buildings) was playing on the 7912. My connection was crap but did pass some additional audio. After a few of these calls - which I teminated by hanging up the cell I noticed that occationally the 7912 stayed off the hook - so I left it that way. I went to the CLI and saw that the 7912 was now bridged to a ZAP channel. I tried a soft hangup on the zap channel and it was now working properly with no WARNING being generated. So it appears that some unholy union between channels can occur when this message is present.

Note 10.0.9.7 is the server hosting the 7912. On other occations, the channel listed in the WARNING message may relate to an ip-phone. If that is the case, rebooting the assosiated phone also causes the repeated WARNING to cease. I suppose the re-registration process clears the wierd channel on the asterisk server.

This was observed on a production box running 1.4.11 - recently upgraded from 1.2.? (with 1.2 the warning was not occuring).
By: jharragi (jharragi) 2007-11-01 10:42:48

...an additional observation...

You can find your afflicted sip peer by entering 'sip show channel (then enter the channel listed in the WARNING - or press tab to locate it)' at the cli.

 SIP User agent:         Cisco-CP7960G/8.0
 Username:               6702
 Peername:               6702
 Original uri:           sip:6702@10.0.10.248:5060                              

...restarting that peer clears the error (on this, and most occurances I've seen, there has been no noticable audio problem on the peer) - and cpu utilization on the asterisk server drops to more normal amounts.


By: mike240se (mike240se) 2007-11-03 03:37:58

I was experiencign a similiar issue with a snom 360.  My issue started after upgrading to 6.5.10 firmware.  The system would end up with many hung zap channels using up all our zap lines until we couldnt make or receive any more calls.  no errors, they just sat there.  reverting to 6.5.2 fixed the issue.  maybe this is a snom issue?
By: jharragi (jharragi) 2007-11-03 07:06:51

Its not specifically a snom issue - as I have it on Ciscos.

I read something in the release notes of 1.4.13 that sounded like this issue has been addressed. Try that. I had an opportunity to put it on yesterday - so far so good (with not much calling to test). & will know over next week if that is the case.
By: Tilghman Lesher (tilghman) 2007-12-10 10:59:39.000-0600

jharragi: was this indeed fixed by 1.4.13?
By: jharragi (jharragi) 2007-12-10 13:40:50.000-0600

Corydon76: I have not been observing this on 1.4.13
By: Tilghman Lesher (tilghman) 2007-12-10 14:35:01.000-0600

Are the SNOMs also fixed by upgrading to 1.4.13?  If this is no longer an issue, I'd love to be able to close this out as fixed.
By: Ken Williams (kenw) 2007-12-10 18:15:50.000-0600

I'll be upgrading in the next few days and reporting back.
By: David Brillert (aragon) 2007-12-11 19:31:34.000-0600

I use 1.4.13 and see these errors in the logs all day long.
Aastra 480i 1.4.2.3000 firmware
By: David Brillert (aragon) 2007-12-12 09:33:43.000-0600

I have to increase my park timeout to a very high timer as well or I see the same errors until Asterisk refuses new calls.
Asterisk 1.4.13
Aastra 480i firmware 1.4.2.3000

[Dec 11 15:06:04] WARNING[935] chan_sip.c: Remote host can't match request BYE to call '2f247c36358ca6a41356865f4431ce54@10.0.50.254'. Giving up.
[Dec 11 15:06:04] WARNING[935] chan_sip.c: Remote host can't match request BYE to call '42cff5b4184f11c54b80ff715c993b61@10.0.50.254'. Giving up.
[Dec 11 15:06:04] WARNING[935] chan_sip.c: Remote host can't match request BYE to call '42cff5b4184f11c54b80ff715c993b61@10.0.50.254'. Giving up.
[Dec 11 15:06:04] WARNING[935] chan_sip.c: Remote host can't match request BYE to call '17e382452598842678d5a1f34bfe6b9b@10.0.50.254'. G
By: Phoebe Anderson (phoebe) 2007-12-14 15:24:32.000-0600

I just had the same issue using 1.4.15:

[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '03ae47096af210be7a3d56a162e0d3a3@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '09b370535d1d886a1b5aa712495a552f@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '3cfc77e9297e3bf746347a2d2392cb02@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '02b9c108619ba24b19fe22b6525f49a1@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '7548e6b31c6e7c5915591cf4167f5cb4@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '1955e5c37091b2565d8b793b2c9917ee@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '3cfc77e9297e3bf746347a2d2392cb02@192.168.80.1'. Giving up.
[Dec 14 11:51:41] WARNING[13685] chan_sip.c: Remote host can't match request BYE to call '03ae47096af210be7a3d56a162e0d3a3@192.168.80.1'. Giving up.
[Dec 14 12:01:14] WARNING[1527] chan_sip.c: Can't send -1213238960 type frames with SIP write
By: jharragi (jharragi) 2007-12-14 17:00:38.000-0600

I should add one additional comment. About the time I upgraded to 1.4.13 I also changed to canreinvite=no for every device in my wan - which is private.
By: Ken Williams (kenw) 2007-12-21 08:39:22.000-0600

Upgraded to 1.4.16.1 couple nights ago, I still have the exact same original problem.  When a call has been placed on park rings back and then is not answered, I get the above mentioned warnings followed by a hangup.

I think the other posts in this thread with similar errors are actually completely different issues.
By: Joel Vandal (jvandal) 2008-01-02 15:02:47.000-0600

Not 100% sure if this can be related to this ticket, but have made test on DougUDI and aragon servers to check if same problems and here what I've do:

- Use ParkAndAnnounce function and set the timeout to 10 seconds (testing purpose) to reproduce the error (SIP BYE errors/maximum retries exceeded on transmission, etc))

If I watch for the ParkAndAnnounce option :

exten => 7000,1,ParkAndAnnounce(pbx-transfer:PARKED|10|Local/console@default-app-callpark|default-local,${CALLERID(num)},1)

On Asterisk CLI, I've notice this log :

== Parked SIP/6002-b7c04cc0 on 7001@parkedcalls. Will timeout back to extension [macro-default-dial] s, 6 in 10 seconds

and call is return to the SIP device, but we have specified a timeout destination/return context (default-local,${CALLERID(num)},1) so output must show something like :


== Parked SIP/6002-b7c04cc0 on 7001@parkedcalls. Will timeout back to extension [default-local], 6003, 1 in 10 seconds


I think the main issue is with the return_context, please correct me if I'm wrong or if we need to create a different ticket for this.
By: Ken Williams (kenw) 2008-01-03 10:44:03.000-0600

I've gone through the logs and code, and it appears my problem has to do with the 408 response from the phone in chan_sip.c.

As a recap, a call comes in, is put into the parking lot.  X seconds later it rings back to the phone that originally answered.  If this phone doesn't pick the call up in 60 seconds, Asterisk drops the call.  Below is the code.

       case 408: /* Request timeout */
       case 481: /* Call leg does not exist */
               /* Could be REFER caused INVITE with replaces */
               ast_log(LOG_WARNING, "Re-invite to non-existing call leg on other UA. SIP dialog '%s'. Giving up.\n", p->callid);

               xmitres = transmit_request(p, SIP_ACK, seqno, XMIT_UNRELIABLE, FALSE);
               if (p->owner)
                       ast_queue_control(p->owner, AST_CONTROL_CONGESTION);
               sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
               break;


I've tried everything in extensions as far as exten,s,1 - exten,t,1 - exten,h,1 - exten,.s, etc....literally dozens of 'capture a bad call' extensions in all different contexts, regardless it drops the line.

So is this the way a 408 response to a parking lot ring back is expected to be handled?
By: David Brillert (aragon) 2008-01-03 12:47:01.000-0600

As per jvandal's note with some additional details provided:

The problem a few of us are having is that the park timeout does not timeout to the correct context [default-local] instead of [macro-default-dial] therefore the call forward busy and call forward no answer rules are not followed (because the SIP device has no knowledge of the proper forwarding contexts).
For example an extension has parked a call and then reached it's call limit and then the park timeout returns the caller to the busy extension. Since the SIP extension cannot accept more calls the caller is disconnected and the call forward busy context is never invoked.

For us the only workaround is to set the park timeout to a ridiculous timeout value so the timer is never invoked.

The timeout context seems to be the root cause and the forwarding rules are not followed because of this.
When the caller is disconnected all kinds of evil things begin happening.
Here is a really good example from /var/log/asterisk/messages
Jan 2 15:33:01 chan_sip.c ERROR Call to peer '6003' rejected due to usage limit of 1
Jan 2 15:33:05 chan_sip.c WARNING Maximum retries exceeded on transmission 717b6b7262fd92ea68ee81d262030648@192.168.30.254 for seqno 1 (Critical Response)
Jan 2 15:33:11 pbx.c WARNING Timeout, but no rule 't' in context 'park-dial'

As per jvandal...
"If I watch for the ParkAndAnnounce option :

exten => 7000,1,ParkAndAnnounce(pbx-transfer:PARKED|10|Local/console@default-app-callpark|default-local,${CALLERID(num)},1)

On Asterisk CLI, I've notice this log :

== Parked SIP/6002-b7c04cc0 on 7001@parkedcalls. Will timeout back to extension [macro-default-dial] s, 6 in 10 seconds

and call is return to the SIP device, but we have specified a timeout destination/return context (default-local,${CALLERID(num)},1) so output must show something like :


== Parked SIP/6002-b7c04cc0 on 7001@parkedcalls. Will timeout back to extension [default-local], 6003, 1 in 10 seconds


I think the main issue is with the return_context"
By: David Brillert (aragon) 2008-01-03 12:50:20.000-0600

I would hope someone could write a patch to return the parked call to the correct context.
By: Ken Williams (kenw) 2008-01-03 13:56:04.000-0600

Actually I think you're exactly right.  Somehow I missed:

 == Parked Zap/2-1 on 201@parkedcalls. Will timeout back to extension [from-zaptel] 900, 6 in 60 seconds

It never returns to this context!
By: Ken Williams (kenw) 2008-01-03 15:54:37.000-0600

Scratch that.

I believe I misunderstood what the screen was saying.  At this point, it does return from the parking lot to the call that picked it up (in this case it happens to say [from-zaptel], 900, 6 - this is where I answered the call).

It's after it times out and rings back to me, another 60 seconds past this is when Asterisk dumps it instead of going to a timeout extension.
By: Ken Williams (kenw) 2008-01-08 11:28:36.000-0600

Okay, so here's my temporary fix, I've been battling this damn thing for to long and who knows how many extra steps I may have, but it's currently working the way we want it to so I'm happy.

First, I changed line 1686 in res_features.c from

snprintf(returnexten, sizeof(returnexten), "%s||t", peername);
to
snprintf(returnexten, sizeof(returnexten), "%s|45|t", peername);

Second, I added to my extensions.conf the following:

[park-dial]
       exten => _SIP.,2,Wait(2)
       exten => _SIP.,3,Goto(from-zaptel,900,1)

The goto is our ring group, the wait seemed necessary to allow time for the initial ring back to clear out, but may not be.  Also note I had to do _SIP.,2 because it does "-- Executing [SIP/717@park-dial:1] Dial("Zap/2-1", "SIP/717|45|t") in new stack" on it's own and I needed to pick up after this, otherwise it just hangs up the line.

Regardless, this is our temporary fix and I'm open for suggestions/comments.
By: David Brillert (aragon) 2008-01-16 11:56:20.000-0600

I'm just wondering why this bug is in feedback status?
By: David Rodman (djrodman) 2008-01-20 17:35:03.000-0600

Thanks kenw for identifying the internally-created context "park-dial" - that has enabled me to fix this for our multi-company installation.  Three notes:
1 - the dial timeout really ought to be a parameter in features.conf - it's easy enough to add another one for those so inclined.
2 - In modifying that line in res_features.c, the arguments to the Dial application should include 'k' so that in case the call is answered, it can be parked again.  Without that 'k', a call can only be parked once. So ..

  snprintf(returnexten, sizeof(returnexten), "%s|45|kt", peername);

(or replace the 45 with your parameter if you make one)

3 - Exported channel variables (i.e. those originally defined with a leading '__' are copied to the new channel - therefore they are available in the park-dial steps.  For those of us with more than one company in the dial plan, this means we can transfer back to the original context.  I have a variable __COMPANY set to the original context in which the call arrived.  All companies in my setup have a "dial 0 for operator" extension configured.  So, this is working great for me:

[park-dial]
exten => _SIP.,2,Goto(${COMPANY}|0|1)

Thanks again!  One more red block turns green!


By: David Brillert (aragon) 2008-01-22 08:58:20.000-0600

I'm happy that kenw and djrodman are happy with their fix.

However this is not an official fix and IMHO does not really fix the parking problem.
Also their fix I think is less than ideal since they must modify the Asterisk source code and this only provides limited functionality to park.

If a phone parks a call and calllimit is reached the phone is busy.
Why can the returned park call not follow the call forward busy rule applied to that extension?
Example call forward busy on ext 6000 where destination = vmail

It would be much better if the local extensions' context was followed on busy...
This would offer true granularity and correct logic to park timeouts (instead of disconnecting the caller).

For now the only workaround is to blast the park timeout to a ridiculous arbitrary number so that the timeout is never invoked.
By: David Rodman (djrodman) 2008-01-22 15:29:15.000-0600

Aragon is correct on all points but this:
- the suggested work-around does NOT require any source code changes, does NOT result in the caller being disconnected, and makes it possible to provide full functionality to Park(), including the ability to transfer the call anywhere you want to send it.  All that is required is to add steps (priorities) to the dialplan in the context to which these calls are being sent by the existing code.

The suggested source code changes are not required in order to implement this workaround.  They (a) reduce the timeout on recalled calls; and (b) correct a different bug that prevents recalled calls from being parked again.

You bet it would be better to follow the busy/no-answer logic on the called-back extension, and it would be better to have an official fix.  No question.

On the other hand, this workaround makes it possible to treat calls that were abandoned on park differently from calls that are ringing the extension for the first time.  In a customer service environment this might be seen to be an improvement.  You can say "We're sorry you have been on hold for so long" and offer options like leaving a message or trying a different extension, and so forth- options that only make sense when the call has been stuck in park for a while.  Whatever the "official" fix winds up being ought to take that flexibility into acocunt.  Perhaps something as simple as setting a channel variable would do the trick.

In any case, the value of the current suggestion is that anyone who is suffering from the problem at hand and who does not wish to modify the source code can still work around the problem in a satisfactory way.  I hope I have not suggested that this is anything more than a successful workaround and if so I apologize.


By: David Brillert (aragon) 2008-01-23 09:06:52.000-0600

djrodman

I dont think you need to offer an apology.
Since park is working for you, you may have an opportunity here to do some real good...

Why dont you propose your fix as an official patch in this bug report?
This would likely be the first step into getting an official fix to this problem.
By: David Rodman (djrodman) 2008-01-23 20:58:19.000-0600

I don't propose kenw's workaround as an official patch because it's not a patch.  There are no required changes to the source code.  All you need to do is add steps to your dial plan to do whatever you want with these calls.

But, if you're really intent on changing the source code, here's a fix for the originally-reported problem:

1.4.17

res/res_features.c line 1673 begins a process that overwrites the callback destination for a timed-out parked call.  It is described (accurately) in the code as a kludge.  I have no idea what its intended purpose was.  If you disable it, timed-out parked calls ring back to where they said they were going to ring back to.  That is, the promise made on line 394 ("Will timeout back to extension ...") is kept.

Before making this change it would probably be a good idea to find out why this was implemented in the first place.  Just cuz it's a kludge doesn't mean it has no useful purpose - quite the opposite, in normal practice.

Line 1673 of res_features.c
Change this:
if (pu->peername[0]) {
to this:
if (0) {


By: David Brillert (aragon) 2008-01-24 12:04:40.000-0600

djrodman

I really appreciate your input and I'm not a "source code guy/programmer"

Would you say there are two issues here?
1. Source code requires some change to fix (b)...?

"The suggested source code changes are not required in order to implement this workaround. They (a) reduce the timeout on recalled calls; and (b) correct a different bug that prevents recalled calls from being parked again.
Without that 'k', a call can only be parked once. So .."

2. Keeping the promise to timeout to the intended destination seems kind of important...

"res/res_features.c line 1673 begins a process that overwrites the callback destination for a timed-out parked call. It is described (accurately) in the code as a kludge. I have no idea what its intended purpose was. If you disable it, timed-out parked calls ring back to where they said they were going to ring back to. That is, the promise made on line 394 ("Will timeout back to extension ...") is kept.
Before making this change it would probably be a good idea to find out why this was implemented in the first place. Just cuz it's a kludge doesn't mean it has no useful purpose - quite the opposite, in normal practice."

Line 1673 of res_features.c
Change this:
               if (pu->peername[0]) {
to this:
               if (0) {


Bearing all this in mind...
Does this make sense to you as a proposed change?
(I have omitted the 45 second option since hard coding this value should not be in the source code.)
Does it conflict with some meaningful purpose to the "kludged" code?

line 1686 in res_features.c from

snprintf(returnexten, sizeof(returnexten), "%s||t", peername);
to
snprintf(returnexten, sizeof(returnexten), "%s||kt", peername);

and
Line 1673 of res_features.c
Change this:
               if (pu->peername[0]) {
to this:
               if (0) {
By: David Brillert (aragon) 2008-01-24 15:03:40.000-0600

using a dial plan workaround now too
It is working ok
By: David Rodman (djrodman) 2008-01-24 17:27:30.000-0600

Yep, there are the two issues Aragon summarized.
To sum up:

1. Calls timing out on park do not recall to the c-e-p they say they will.
  Solution: patch line 1673 of res_features.c as suggested
2. Recalled calls cannot be parked again
  Solution: same patch (this eliminates the whole block of code where the 'k' patch was)

As far as the dial timer, I believe (but have not tested) that this will follow the original Dial parameters because the call is actually going back to the originating c-e-p
By: David Woolley (davidw) 2008-03-12 13:53:33

This looks like it may relate to my ASTERISK-1212194.  Certainly the misleading verbose trace is the same.  At the moment I'm having difficulty believing that returning a call to SIP would ever work, although I suppose it might work if something magic was done with the session suffix from the channel name, or it was simply stripped.  In my case it is much easier to see what is going wrong, as I'm using the console channel; I don't know if there are any hacks in the SIP channel that might mitigate my issue.

Note that only ParkAndAnnounce actually goes back to where the verbose message says it will go back (ParkAndAnnounce doesn't pass a peer to the core part of the park function).  All the other variants (feature code, AMI Park, and Park application) try and return to the peer.  In the case of Park(), this is the channel name of the channel that was actually parked, at the time of the Park(), which the system expects to have been released by a transfer, of the parked call.

I have some reservations about what actually gets parked for AMI Park and ParkAndAnnounce, but that is based on code reading, and I need to verify with tests.
By: David Woolley (davidw) 2008-03-12 16:31:07

The trace indicates that the session id (SIP tag?) *is* getting stripped from channel name, although I'm not sure where.

However, the trace also indicates that the parking was done by a SIP transfer to the specific parkingext number (the channel name has a "Parking/" prefix, whereas parks by the more general mechanisms would have a "Parked/" prefix, or no prefix. Such transfers are special-cased in the SIP channel.


By: Russell Bryant (russell) 2008-04-22 13:24:00

I am going to commit a change that allows the calls after a parked call times out to time out.  If anyone has issues beyond that, please create new reports for them.  Thanks
By: Digium Subversion (svnbot) 2008-04-22 13:24:39

Repository: asterisk
Revision: 114542

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r114542 | russell | 2008-04-22 13:24:38 -0500 (Tue, 22 Apr 2008) | 3 lines

After a parked call times out, allow the call back to the parker to time out.
(closes issue ASTERISK-10449)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114542
By: Digium Subversion (svnbot) 2008-04-22 13:25:32

Repository: asterisk
Revision: 114543

_U  trunk/

------------------------------------------------------------------------
r114543 | russell | 2008-04-22 13:25:32 -0500 (Tue, 22 Apr 2008) | 10 lines

Blocked revisions 114542 via svnmerge

........
r114542 | russell | 2008-04-22 13:29:56 -0500 (Tue, 22 Apr 2008) | 3 lines

After a parked call times out, allow the call back to the parker to time out.
(closes issue ASTERISK-10449)

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114543
By: Digium Subversion (svnbot) 2008-04-22 13:25:51

Repository: asterisk
Revision: 114544

_U  branches/1.6.0/

------------------------------------------------------------------------
r114544 | russell | 2008-04-22 13:25:51 -0500 (Tue, 22 Apr 2008) | 17 lines

Blocked revisions 114543 via svnmerge

................
r114543 | russell | 2008-04-22 13:30:47 -0500 (Tue, 22 Apr 2008) | 10 lines

Blocked revisions 114542 via svnmerge

........
r114542 | russell | 2008-04-22 13:29:56 -0500 (Tue, 22 Apr 2008) | 3 lines

After a parked call times out, allow the call back to the parker to time out.
(closes issue ASTERISK-10449)

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114544
By: Digium Subversion (svnbot) 2008-04-22 18:31:20

Repository: asterisk
Revision: 114570

_U  team/seanbright/resolve-shadow-warnings/
U   team/seanbright/resolve-shadow-warnings/apps/app_queue.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_iax2.c
U   team/seanbright/resolve-shadow-warnings/include/asterisk/pbx.h
U   team/seanbright/resolve-shadow-warnings/main/channel.c
U   team/seanbright/resolve-shadow-warnings/main/pbx.c

------------------------------------------------------------------------
r114570 | seanbright | 2008-04-22 18:31:18 -0500 (Tue, 22 Apr 2008) | 113 lines

Merged revisions 114538,114540,114543,114546,114548,114551,114553,114559 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r114538 | russell | 2008-04-22 14:04:39 -0400 (Tue, 22 Apr 2008) | 17 lines

Merged revisions 114537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines

If the dial string passed to the call channel callback does not indicate an
extension, then consider the extension on the channel before falling back
to the default.

(closes issue ASTERISK-11881)
Reported by: darren1713
Patches:
     exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)

........

................
r114540 | qwell | 2008-04-22 14:14:09 -0400 (Tue, 22 Apr 2008) | 8 lines

Allow setqueuevar=yes (et al) to work, after changes to pbx_builtin_setvar()

(closes issue ASTERISK-11888)
Reported by: bcnit
Patches:
     12490-queuevars-3.diff uploaded by qwell (license 4)
Tested by: qwell

................
r114543 | russell | 2008-04-22 14:30:47 -0400 (Tue, 22 Apr 2008) | 10 lines

Blocked revisions 114542 via svnmerge

........
r114542 | russell | 2008-04-22 13:29:56 -0500 (Tue, 22 Apr 2008) | 3 lines

After a parked call times out, allow the call back to the parker to time out.
(closes issue ASTERISK-10449)

........

................
r114546 | russell | 2008-04-22 15:45:12 -0400 (Tue, 22 Apr 2008) | 9 lines

Blocked revisions 114545 via svnmerge

........
r114545 | russell | 2008-04-22 14:45:00 -0500 (Tue, 22 Apr 2008) | 2 lines

Trivial change to read the number of samples from a frame before calling ast_write()

........

................
r114548 | russell | 2008-04-22 16:25:56 -0400 (Tue, 22 Apr 2008) | 2 lines

re-add a fix that got lost with a recent change

................
r114551 | russell | 2008-04-22 17:15:41 -0400 (Tue, 22 Apr 2008) | 11 lines

Blocked revisions 114550 via svnmerge

........
r114550 | russell | 2008-04-22 16:14:55 -0500 (Tue, 22 Apr 2008) | 4 lines

I thought I was going to be able to leave 1.4 alone, but that was not the case.
I ran into some problems with G.722 in 1.4, so I have merged in all of the fixes
in this area that I have made in trunk/1.6.0, and things are happy again.

........

................
r114553 | murf | 2008-04-22 17:57:57 -0400 (Tue, 22 Apr 2008) | 14 lines


(closes issue ASTERISK-11872)
Reported by: triccyx

I had a bit a problem reproducing this in my setup (trying not to disturb my other stuff)
but finally, I got it. The problem appears to be that the extension is being added in
replace mode, which kinda assumes that the pattern trie has been formed, when in fact,
in this case, it was not. The checks being done are not nec. when the tree is not yet
formed, as changes like this will be summarized when the trie is formed in the future.

I tested the fix, and the crash no longer happens. Feel free to open the bug again if
this fix doesn't cure the problem.


................
r114559 | russell | 2008-04-22 18:17:31 -0400 (Tue, 22 Apr 2008) | 13 lines

Merged revisions 114558 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114558 | russell | 2008-04-22 17:15:36 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

........

................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=114570