[Home]

Summary:ASTERISK-03784: [Patch] [post 1.2] answer and hungup on polarity switch Fix (works in SPAIN)
Reporter:Julian J. M. (julianjm)Labels:
Date Opened:2005-03-27 10:26:04.000-0600Date Closed:2006-01-24 13:33:25.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap.c.diff.2.txt
( 1) chan_zap.c.diff.txt
( 2) asterisk-1-2-polarity-v2.diff
( 3) asterisk-1-2-polarity-v3.diff
( 4) asterisk-polarity-1-2-0-final-v1.diff
( 5) chan_zap.c-asterisk-1-2-polarity-v1.diff
Description:In spain we don't have call progress nor disconnect supervision (fxs_ks doesn't detect anything).
However, some situations are signalled with polarity switchs.
There is information from the TelCo here http://www.telefonica.es/interfaces/doc_pdf/ITE-CA-001-V04.pdf (page 23, 5.4.3).

There is a problem with the current implementation, in that it doesn't detect the remote party hungup. While in conversation, a polarity switch means that.

Also, there was a problem with p->polaritydelaytv not being updated when a call was answered, which caused that a further polarity switch would be always ignored, when checking for polarityonanswerdelay.

This patch works for me, but more feedback is needed, beacuse it could break other things.

julianjm at gmail dot com

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

This is my current zapata.conf, regarding this issue:

[channels]
signalling=fxs_ks
context=from-pstn
busydetect=no
answeronpolarityswitch=yes ;;;
hanguponpolarityswitch=yes ;;;
callprogress=no
progzone=es
channel => 4
Comments:By: nick (nick) 2005-03-27 12:16:57.000-0600

Just as a note, in English (and elsewhere in Asterisk) they're called "polarity reversals". If you could update your patch, that would keep everything consistent.

I realize this was probably just a minor translation thing, but consistency is good :)

NB

By: Julian J. M. (julianjm) 2005-03-27 12:28:01.000-0600

My patch adds an ast_log statement, which is copied and pasted from a similar one, in that case it uses "Hangup due to Reverse Polarity on channel %d..."

answeronpolarityswitch and hanguponpolarityswitch keywords in zapata.conf were already present before my patch, i didn't invent them ;)

By: Mark Spencer (markster) 2005-03-27 16:08:20.000-0600

Would it be perhaps easier to say if hanguponpolarity is set and answeronpolarity is NOT set that we should consider off-hook polarity to be reversed rather than idle?

By: Julian J. M. (julianjm) 2005-03-27 16:25:57.000-0600

Markster,
Thinking about it, I guess the problem lies in that when we receive an incoming call and answer, polarity is set to IDLE (Setting IDLE polarity due to ring. Old polarity was 0)... Then, if the calling party hangs up, it follows the "if (p->polarity == POLARITY_IDLE) {", which only handles the answer of the channel.

That's why I added hangup code there. If we can set p->polarity=POLARITY_REV when we answer a channel, my patch wouldn't be needed... Only the gettimeofday line.

What do you think?

By: egnarf (egnarf) 2005-03-28 03:53:07.000-0600

The polarity is set to idle on a ring because that was what happens here in sweden and all other places that I had specs for when I implemented it.
The procedure (here at least) is:
* Polarity reversed
* Cid is sent
* Polarity reverses back to idle
* ring signal is sent
* (when call is answered and connected) Polarity reverses
* call proceeds
* (when call ends) Polarity reverses back to idle.

Since the polarity detector didn't always detect a reversal before a ring (I think that is fixed now though) I made the code reset it if a ring is detected.
Unfortunately I've gone voip since then so I cant test it.
However, if you make it an option (ie. resetpolarityonring = no, where yes is how it's done now) it shouldn't break anything.

By: Julian J. M. (julianjm) 2005-03-28 04:32:32.000-0600

Having this in extensions.conf...
[incoming]
exten => s,1,Wait(20)
exten => s,2,Answer

Here is the wctdm syslog for an incoming call:
Mar 28 11:12:18 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:18 SKYWALKER kernel: 783015309 Polarity reversed (-1 -> 1)
Mar 28 11:12:18 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:21 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:23 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:25 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:27 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:29 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:31 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:33 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:34 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:37 SKYWALKER kernel: RING on 1/4!
Mar 28 11:12:38 SKYWALKER kernel: NO RING on 1/4!
Mar 28 11:12:45 SKYWALKER kernel: Setting FXS hook state to 2 (00)
Mar 28 11:12:47 SKYWALKER kernel: Setting FXS hook state to 1 (00)
Mar 28 11:12:50 SKYWALKER kernel: Setting FXS hook state to 2 (00)
Mar 28 11:12:51 SKYWALKER kernel: Setting FXS hook state to 1 (00)
Mar 28 11:12:52 SKYWALKER kernel: 783048873 Polarity reversed (1 -> -1)
Mar 28 11:12:52 SKYWALKER kernel: Setting FXS hook state to 3 (00)
Mar 28 11:12:52 SKYWALKER kernel: Setting FXS hook state to 0 (00)

You see, on the first ring polarity is reversed...

Here is the asterisk log:
Mar 28 11:12:18 VERBOSE[2212]:     -- Starting simple switch on 'Zap/4-1'
Mar 28 11:12:19 VERBOSE[2212]:     -- Executing Executing Wait("Zap/4-1", "20") in new stack
Mar 28 11:12:23 DEBUG[2212]: Exception on 22, channel 4
Mar 28 11:12:23 DEBUG[2212]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 28 11:12:23 DEBUG[2212]: Setting IDLE polarity due to ring. Old polarity was
0
Mar 28 11:12:27 DEBUG[2212]: Exception on 22, channel 4
Mar 28 11:12:27 DEBUG[2212]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 28 11:12:27 DEBUG[2212]: Setting IDLE polarity due to ring. Old polarity was
0
Mar 28 11:12:31 DEBUG[2212]: Exception on 22, channel 4
Mar 28 11:12:31 DEBUG[2212]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 28 11:12:31 DEBUG[2212]: Setting IDLE polarity due to ring. Old polarity was
0
Mar 28 11:12:34 DEBUG[2212]: Exception on 22, channel 4
Mar 28 11:12:34 DEBUG[2212]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 28 11:12:34 DEBUG[2212]: Setting IDLE polarity due to ring. Old polarity was
0
Mar 28 11:12:38 DEBUG[2212]: Exception on 22, channel 4
Mar 28 11:12:38 DEBUG[2212]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 28 11:12:38 DEBUG[2212]: Setting IDLE polarity due to ring. Old polarity was
0
Mar 28 11:12:40 VERBOSE[2212]:     -- Executing Answer("Zap/4-1", "") in new stack
Mar 28 11:12:40 DEBUG[2212]: Took Zap/4-1 off hook
[....] ** The calling party hung up
Mar 28 11:12:52 DEBUG[2212]: Got event Polarity Reversal(17) on channel 4 (index
0)
Mar 28 11:12:52 DEBUG[2212]: Hangup due to Reverse Polarity on channel 4 (julian
jm)


With this information, in Spain, it should be safe to set polarity=POLARITY_REV on answer, and to disable setting IDLE polarity on each ring.

I'm not an asterisk expert, so what do you think is the best way to acomplish this, because not all Telcos work the same way...

resetpolarityonring=no  could be an option, but should it set polarity=POLARITY_REV on answer, or should we use another keyword for that?

Julian.

By: egnarf (egnarf) 2005-03-28 04:57:45.000-0600

Do you have callerid?
And if so, could you send the same logs but also with callerid reception?

If I read your logs correctly your line behaves as follows:
1. Polarity switches to reversed.
2. Ring is signalled.
3. Call is answered
4. Call is terminated
5. Polarity switches back to idle.

In that case, as you say above, NOT resetting the polarity when we detect a ring is enough. So a 'resetpolarityonring = no' should be enough to solve it for spain and all others with similar behavior.
In sweden not resetting the polarity on ring doesn't do any harm if the polarity-detector correctly identifies the switch before the ring.
I put it there because it didn't always do so, and as a 'just in case' option so we don't get out of sync.

Maybe the best thing would be to remove it, and possibly add a 'resetpolarityonring = yes' to re-enable it if it is needed somewhere.
As I said I can't test this anymore since I am all VOIP now.
Mark, what's your take on all this?

By: Julian J. M. (julianjm) 2005-03-28 09:19:35.000-0600

Hi egnarf,

Your approach (not setting IDLE on RING), would work *if* that first polarity switch was handled by chan_zap, but it isn't... wctdm detects the polarity switch, but somehow that doesn't generate a ZT_EVENT_POLARITY event, so p->polarity stays IDLE.
I'll try adding some ast_log's and see what happens with that event when the channel isn't yet answered...

By: Julian J. M. (julianjm) 2005-03-28 11:42:04.000-0600

Ok, just added a new (cleaner) patch.

Here's how it works.

Incoming call
=============
After reading callerid (when cid_start=ring, and not polarity), we set polarity=POLARITY_REV. Before it still was IDLE, although wctdm detects this first switch.
Next time we get a polarity reversal, being in state UP or _RING_, we hangup the channel.

Outgoing call
=============
After dialing, a polarity reversal tells us the called party has answered. We get the current time in polaritydelaytv, for later checking for a hungup situation, when another polarity reversal kicks in.

BTW, setting POLARITY_REV after callerid detection is an attemp to not break other things, and it's done only with cid_start=ring because it's the only case I can test here.

edited on: 03-28-05 11:43

By: egnarf (egnarf) 2005-03-29 03:03:16.000-0600

cid_start=ring could be causing chan_zap not to detect the first reversal.
Before the channel is created, events like ring, polarity reversal, etc are checked in another place in the code.
cid_start=polarity detects the initial reversal and creates the channel, so without it the initial reversal would be ignored.

Did you test with cid_start=polarity before, or just with cid_start=ring?

By: Julian J. M. (julianjm) 2005-03-29 12:47:39.000-0600

Testing with cid_start=polarity works ok (doesn't need setting polarity to REV).

Mar 29 19:44:18 VERBOSE[24882]:     -- Starting simple switch on 'Zap/4-1'
Mar 29 19:44:19 VERBOSE[24882]:     -- Executing Wait("Zap/4-1", "20") in new stack
Mar 29 19:44:22 DEBUG[24882]: Exception on 17, channel 4
Mar 29 19:44:22 DEBUG[24882]: Got event Ring/Answered(2) on channel 4 (index 0)
Mar 29 19:44:25 DEBUG[24882]: Exception on 17, channel 4
Mar 29 19:44:25 DEBUG[24882]: Got event Polarity Reversal(17) on channel 4 (index 0)
Mar 29 19:44:25 DEBUG[24882]: Hangup due to Reverse Polarity on channel 4

Before this patch, if I used cid_start=ring, that hangup due to reverse polarity would be ignored (because polarity was IDLE).

I don't know if anybody has tested this patch, but given the recurrent questions in -users about hangup detection, it should have been :-?

By: Michael Jerris (mikej) 2005-05-02 15:52:49

1 month update request.  Is this working without issues?  Files to cleanup.  Any additional testers?  Does the patch still apply to head?

By: Michael Jerris (mikej) 2005-06-15 22:40:06

Reminder-  If we do not have comment on this with status by this weekend, this bug will be closed out due to lack of response from the poster.

By: Michael Jerris (mikej) 2005-06-27 22:41:01

Closed due to no response.  If you would like to persue this bug, please re-open with the appropriate updates.  Thanks.

By: Julian J. M. (julianjm) 2005-10-04 02:48:05

This bug was previously closed because of lack of feedback... Now, given the acceptance of the polarity patch for asterisk 1-0 (http://www.maxosystem.net/asterisk/asterisk-stable-polarity.html), i'm reopening this issue hoping to get more feedback and have it included in CVS.

By: Juan Carlos Valero (eb3dgz) 2005-10-04 03:20:46

This patch work right on my Asterisk-1.2-Beta1, with TDM400B. Previously does not work the hangup detection.

By: Elio Rojano (hell) 2005-10-04 06:02:50

I wish this patch was included into the new versions. We always advice it to avoid get full harddisk when external caller hangup after using voicemail. :)

By: Serge Vecher (serge-v) 2005-10-04 08:32:05

julianjm, can you please clean the patch up according to CODING-GUIDELINES (no c++-style comments)?

By: Julian J. M. (julianjm) 2005-10-04 17:47:20

Just uploaded the patch with the required modifications:

asterisk-1-2-polarity-v2.diff

By: Jose Maria TJ (josemax) 2005-10-07 04:48:58

we have in production the previous (over 1.0.9) working fine for 4 months. The line is always release when the other side hangs the phone. NEVER has failed. Asterisk without this patch is UNUSABLE in Spain with TDM400's. Please include in release.

By: Chris Earle (fizik) 2005-10-11 12:28:13

Could not get the asterisk-stable-polarity-v5 to work on a 1.09 server in Brazil -- was not detecting polarity change/disconnect on hangup from a PSTN call out

(Busydetect solution was found through bugfix ASTERISK-4708
and is working so far)



By: Julian J. M. (julianjm) 2005-10-11 15:07:09

Asterisk cannot do black magic... Have you made sure your TelCo does indeed send polarity reversals?

You can do that loading wcfxs with debug=1, and watching /var/log/messages during a call.

Julian J. M.

By: Juan Carlos Valero (eb3dgz) 2005-11-12 14:42:15.000-0600

In Asterisk 1.2 rc1 does not appear this patch. It is necesary for Spain. Any plans to release this patch. Intensive use in Asterisk 1.2 beta 1 without trouble.

By: Julian J. M. (julianjm) 2005-11-14 09:39:19.000-0600

Attached patch for asterisk 1.2 RC2 (asterisk-1-2-polarity-v3.diff)

By: Juan Carlos Valero (eb3dgz) 2005-11-14 10:23:52.000-0600

Patch for 1.2 rc2 tested OK. It's running on my Asterisk PBX server now, and detecting succesfully hangups in Spain.

By: Julian J. M. (julianjm) 2005-11-27 06:18:59.000-0600

Ok... next try...

Changes were applied to asterisk 1.2.0 regarding polarity detection. This breaks previous patches attached to this bug.

The current code in 1.2.0 doesn't work in Spain in its current form, so i've just made some minor changes to the 1.2.0 codebase, hoping it'll be included in future releases.

Please provide feedback if it does or doesn't work.

New option for zapata.conf
resetpolarityonring=(true|false)  ; default false. This is needed IIRC in Sweeden. It breaks things in Spain.

Latest patch:  asterisk-polarity-1-2-0-final-v1.diff

By: Faris Raouf (faris1) 2005-11-27 13:53:35.000-0600

Just a quick note to say that 1.2 Stable definitely is broken when it comes to polarity reversal detection due to the problem with p->polaritydelaytv -- it is giving negative values, and so when compared to the polarity delay variable, the match is always false.

e.g. (debug mode on for messages)

chan_zap.c: Got event Polarity Reversal(17) on channel 3 (index 0)
chan_zap.c: Ignore switch to REVERSED Polarity on channel 3, state 4
chan_zap.c: Polarity Reversal event occured - DEBUG 1: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -752866861
chan_zap.c: Polarity Reversal detected but NOT hanging up (too close to answer event) on channel 3, state 4
chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -752866861

Julian, does your patch fix this p->polaritydelaytv issue or are you working around it?

I can see that my patch (which fixed the problem where reverals were always ignored after answer and was working fine 1.x CVS HEAD) code is still in 1.2 Stable but because of the problem with p->polaritydelaytv it is effectively useless.

By: Julian J. M. (julianjm) 2005-11-27 14:08:17.000-0600

Hi faris1,

Yes, it fixes the issue with p->polaritydelaytv. It wasn't updated when we marked the channel as UP when we received the initial polarity switch.

Anyway, I don't think this fix is enough for make it work in Spain. In Spain we must not set polarity=IDLE when we receive a RING. I've worked around that with a ni keywork for zapata.conf. (resetpolarityonring=(true/false)

If the patch you're referencing is the one that removed the "else"... once the issue with polaritydelaytv is fixed, we will be relying on it to avoid an instant hangup after answer. Because the second "if" will eval true. I didn't like it very much, and that's why I added a flag to avoid entering when we've already handled the polarity switch in the first "if" block.

What do you think about it?

Julian J. M.

By: Faris Raouf (faris1) 2005-11-27 14:28:24.000-0600

I'm in the UK. Just to complicate things, we get an instantaneous polarity reversal (i.e. normal, reverse, back to normal all in an instant) with each incoming ring (with CID sent on first ring at least, and possibly on all rings, during the reversals). Then we get another instantaneous polarity reversal on hangup, followed by a continuous tone.

Anyway, I've just applied the patch and unfortunately I'm still getting negative values in polaritydelaytv for some reason.

I've tried resetpolarityonring=true (and false) with no difference.

Incidentally, i've tried cidstart=ring as well as = polarity -- no difference.
usecallerid=yes
cidsignalling=v23
cidstart=ring
;cidstart=polarity
sendcalleridafter=1


I'm extrmely confused. I'm just going to make absolutely sure the patch applied.....

By: Julian J. M. (julianjm) 2005-11-27 14:38:38.000-0600

Hi faris1,

Do you know any URL with this information, specially if it's published by your Company.

Regarding p->polaritydelaytv... I think it's updated on all code paths that deal with answering a channel... And in my tests, I always got a positive value in the DEBUG1 and DEBUG2 lines.

Can you attach your /var/log/messages and /var/log/asterisk/full important lines, for an incoming call and then for an outgoing call? Comment them in the places where the other party answered and hung up.

Julian J. M.

By: Faris Raouf (faris1) 2005-11-27 14:46:02.000-0600

I don't know where BT pushlish these things I'm afraid.

I will attempt to post logs after I remove all the useless/confidential stuff. I don't think I'll be able to do so for a while though.

(edited to remove silly error I had made regarding & before p->)



By: Faris Raouf (faris1) 2005-11-27 15:03:14.000-0600

Somebody pipe up if I'm being a moron, but on recompiling, I happened to notice this:

chan_zap.c:4221: warning: int format, timeval arg (arg 13)
chan_zap.c:4221: warning: int format, timeval arg (arg 14)
chan_zap.c:4235: warning: int format, timeval arg (arg 13)
chan_zap.c:4235: warning: int format, timeval arg (arg 14)

I wonder if this is the root of the negative values? I'm afraid I'm not really in to C, so all this is mostly over my head.

By: Julian J. M. (julianjm) 2005-11-27 15:10:29.000-0600

I guess it depends on the gcc version used:

Try changing every gettimeofday line with:

gettimeofday(&(p->polaritydelaytv), NULL);

That should do it, i.e., it's passing a pointer to that structure. I haven't really coded in C for years though ;)

Julian J. M.

By: Faris Raouf (faris1) 2005-11-27 15:22:07.000-0600

I think my comment above is nothing to do with anything.

However, I added some code to add the "naked" ast_tvnow() and p->polaritydelaytv to the debug output (as asttv= and tod= in the output below) as found this (both are the result of the remote caller hanging up when calling in to Asterisk):

chan_zap.c: Polarity Reversal event occured - DEBUG 1: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -745864799, asttv= 1133125501, tod= 345217
chan_zap.c: Polarity Reversal detected but NOT hanging up (too close to answer event) on channel 3, state 4
chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -745864799, asttv= 1133125501, tod= 345272

Retrying about 10 minutes later, we get:

zap.c: Polarity Reversal event occured - DEBUG 1: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -745215220, asttv= 1133126150, tod= 924938
chan_zap.c: Polarity Reversal detected but NOT hanging up (too close to answer event) on channel 3, state 4
chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 3, state 4, pol= 1, aonp= 1, honp= 1, pdelay= 600, tv= -745215220, asttv= 1133126150, tod= 924993

This explains the nagative values, does it not?

What sort of values do you get for these two?

I'm afraid I have no idea where to go from here....

By: Julian J. M. (julianjm) 2005-11-27 15:34:07.000-0600

Nov 27 19:12:16 DEBUG[31847] chan_zap.c: Polarity Reversal event occured - DEBUG
2: channel 4, state 6, pol= 0, aonp= 1, honp= 1, pdelay= 600, tv= 27466

Nov 27 20:09:59 DEBUG[32560] chan_zap.c: Polarity Reversal event occured - DEBUG
2: channel 4, state 6, pol= 0, aonp= 1, honp= 1, pdelay= 600, tv= 451996

I really don't know what those numbers mean... If it's time from Epoch... it's too low... I have set the box date correctly:

$ date
Sun Nov 27 21:33:17 WET 2005

By: Faris Raouf (faris1) 2005-11-27 15:43:22.000-0600

Unfortunately adding the brackets didn't help.

Could you possibly modify the two debug lines (DEBUG 1 and DEBUG 2) as follows if you can be bothered please?

ast_log(LOG_DEBUG, "Polarity Reversal event occured - DEBUG xxx: channel %d, state %d, pol= %d, aonp= %d, honp= %d, pdelay= %d, tv= %d, asttv= %d, tod= %d\n", p->channel, ast->_state, p->polarity, p->answeronpolarityswitch, p->hanguponpolarityswitch, p->polarityonanswerdelay, ast_tvdiff_ms(ast_tvnow(), p->polaritydelaytv),ast_tvnow(),p->polaritydelaytv );

Just to see what comes out ot the naked ast_tvnow() and p->polaritydelaytv

Something VERY odd going on here. It was fine with 1.0 CVS head.

I'm using gcc-3.2.2-5

By: Julian J. M. (julianjm) 2005-11-27 15:54:52.000-0600

Hmm, what you're getting as tv, is really a pointer to a timeval struct.

struct timeval {
  time_t         tv_sec;        /* seconds */
  suseconds_t    tv_usec;  /* microseconds */
};

time_t is usually a long value.

So, you should really print p->polaritydelaytv->tv_sec, and p->polaritydelaytv->tv_usec.

Julian.

By: Faris Raouf (faris1) 2005-11-28 11:25:08.000-0600

Thanks Julian. Unfortunately I could not get it to compile with that.

I've reverted to my original debugging info.

The problem definitely revolves around ast_tv_diffms() giving negative values. I can see the code is working fine, but because the numbers coming out of that function are nonsensical negative, it all falls down.

My knowledge of C is very sadly lacking so I'm stuck at this point.

Mark -- any you listening in -- any ideas?

Faris.

By: Josef Seger (doda) 2005-12-29 18:26:32.000-0600

I have been running this patch in sweden for a couple of days. This patch fixes the polarity switch function. Without the patch Asterisk will hung upp the call at the same moment as somebody answers the call.

Thank you!

By: Matthew Fredrickson (mattf) 2006-01-17 16:14:44.000-0600

doda: can you check the patch in 6229 to see if it fixes your problem as well?

By: Josef Seger (doda) 2006-01-18 14:41:30.000-0600

I will test the patch in 6229 during the weekend. I'll be back with comments.

By: Josef Seger (doda) 2006-01-24 08:35:29.000-0600

I have tested the patch in 6229 since Sunday. It seems to work without issues.

By: Josef Seger (doda) 2006-01-24 13:17:24.000-0600

I have tested the patch in 6229 since Sunday. It seems to work without issues.

By: Matthew Fredrickson (mattf) 2006-01-24 13:31:58.000-0600

Ok, cool.  I'm closing this then.  I committed the fix for 6229 already.

By: Matthew Fredrickson (mattf) 2006-01-24 13:33:13.000-0600

fixed w/ patch in 6229