| 00:19.13 | *** join/#asterisk-bugs Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 00:19.14 | *** mode/#asterisk-bugs [+o Qwell] by ChanServ |
| 03:06.34 | *** join/#asterisk-bugs pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 05:53.46 | *** join/#asterisk-bugs Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 05:53.46 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 06:34.55 | *** join/#asterisk-bugs mpe (~mpe@94.127.49.1) |
| 07:23.34 | *** join/#asterisk-bugs Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 07:23.34 | *** mode/#asterisk-bugs [+o Qwell] by ChanServ |
| 09:05.52 | *** join/#asterisk-bugs pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 11:16.37 | *** join/#asterisk-bugs Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 11:16.37 | *** mode/#asterisk-bugs [+o Qwell] by ChanServ |
| 13:38.11 | *** join/#asterisk-bugs leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:38.11 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 13:42.49 | *** join/#asterisk-bugs putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:42.49 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 13:56.34 | *** join/#asterisk-bugs jpeeler (~jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:28.09 | *** join/#asterisk-bugs Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 14:28.10 | *** mode/#asterisk-bugs [+o Deeewayne] by ChanServ |
| 14:41.30 | *** join/#asterisk-bugs elliot98 (~elliot@unaffiliated/elliot98) |
| 14:41.51 | elliot98 | I just upgraded to 1.4.33.1 from 1.4.18.1 and T.38 passthrough stopped working |
| 14:42.15 | pabelanger | elliot98: possible |
| 14:42.35 | elliot98 | is this a regression? |
| 14:42.47 | pabelanger | m16705 |
| 14:42.49 | MuffinMan | [ready for review] [Asterisk] Channels/chan_sip/T.38 0016705: [patch] [regression] T.38 negotiation Broken reported by mpiazzatnetbug https://issues.asterisk.org/view.php?id=16705 |
| 14:43.05 | pabelanger | elliot98: Give that patch a try ^^ |
| 14:47.58 | pabelanger | leifmadsen: ping? |
| 14:48.05 | leifmadsen | pabelanger: pong? |
| 14:48.12 | pabelanger | m17571 |
| 14:48.14 | MuffinMan | [new] [Asterisk] Core/RTP 0017571: RFC 2833 frame out of order detection does not properly handle numeric overflow reported by mdeneen https://issues.asterisk.org/view.php?id=17571 |
| 14:48.27 | pabelanger | seems to be a hot issue |
| 14:48.37 | pabelanger | and looks to be a regression |
| 14:49.26 | leifmadsen | agreed, let me look |
| 14:49.50 | pabelanger | m17545 |
| 14:49.52 | MuffinMan | [feedback] [Asterisk] Applications/app_queue 0017545: [regression] DTMF transfers stop working for queue agents idle > 5 minutes reported by maxochoa https://issues.asterisk.org/view.php?id=17545 |
| 14:50.04 | pabelanger | leifmadsen: seems to be related / duplicate |
| 14:51.37 | elliot98 | I am getting "Train Failure" on the fax server using 1.6.0.26 |
| 14:51.57 | leifmadsen | pabelanger: ok, I will take a look at those when I get back. I'm not actually in the office today. |
| 14:52.11 | leifmadsen | pabelanger: can you email those 3 numbers to lmadsen@digium.com ? |
| 14:52.34 | pabelanger | leifmadsen: sure |
| 14:52.36 | richardf | in regards to m17571 I believe the problem is in the patch for m15811 |
| 14:52.38 | MuffinMan | [new] [Asterisk] Core/RTP 0017571: RFC 2833 frame out of order detection does not properly handle numeric overflow reported by mdeneen https://issues.asterisk.org/view.php?id=17571 |
| 14:52.45 | leifmadsen | much appreciated |
| 14:53.09 | richardf | I would think buffering the out of order dtmf packets would be better than dropping them |
| 14:53.28 | richardf | kind of like a jitter buffer for dtmf |
| 14:53.51 | pabelanger | richardf: Yes, looks like 15811 introduced the problem |
| 14:55.45 | pabelanger | elliot98: report back your results :) |
| 14:55.46 | leifmadsen | I'm told putnopvut to take a look at the issue |
| 14:56.14 | putnopvut | Yep, I'm looking at it. |
| 14:57.42 | putnopvut | richardf: buffering doesn't really make sense in this case. In this case we are dropping the frame because we weren't doing so before, and thus erroneously detecting duplicate DTMF. |
| 14:58.08 | richardf | putnopvut: Thinking about it you are right |
| 14:58.08 | putnopvut | My bad on missing the whole signedneess issue. |
| 15:00.51 | *** join/#asterisk-bugs elguero (~miguel323@12.187.84.162) |
| 15:19.01 | richardf | putnopvut: Maybe use the timestamp instead of the sequence number to check for out of order packets? |
| 15:20.44 | putnopvut | richardf: easy solution is to use subtraction instead of a direct comparison. |
| 15:20.54 | putnopvut | i.e. if (seqno - rtp->lastevent > 0) |
| 15:21.12 | putnopvut | I mean < 0 |
| 15:21.13 | putnopvut | :) |
| 15:21.24 | putnopvut | oh wait, that's dumb as hell :) |
| 15:25.33 | richardf | i guess the easy fix would be to use a window and accept seqno's outside the window |
| 15:26.16 | putnopvut | Yeah, something like that is what I'm thinking, too. I'd like to have something more deterministic if possible though. |
| 15:30.07 | richardf | How about storing timestamps of events which have already had an end recieved for them and not processing any further packets with the same timestamp. |
| 15:31.04 | putnopvut | Do all events have the same timestamp? |
| 15:31.07 | richardf | Would need to drop the entry after a change of SSRC thourgh |
| 15:31.11 | putnopvut | knows not much about RTP |
| 15:31.21 | richardf | all packets for the same event have the same timestamp |
| 15:31.31 | putnopvut | okay, that's something I would not have guessed. |
| 15:31.33 | richardf | but the ssrc still increments as usual |
| 15:31.45 | richardf | sorry s/ssrc/seqno |
| 15:33.16 | richardf | http://www.rfc-editor.org/rfc/rfc4733.txt |
| 15:33.21 | richardf | section 2.5.1.2 |
| 15:35.11 | putnopvut | Excellent. I will update the behavior. |
| 15:35.19 | putnopvut | Thanks for your help, richardf. |
| 15:35.46 | richardf | putnopvut: You are welcome. |
| 15:36.20 | putnopvut | Ah, interestingly, the cisco DTMF processing code already had a windowed approach regarding the seqno that I did not mimic in the 2833 case. |
| 15:37.22 | putnopvut | And I just read your line about having to drop the entry after a change of ssrc. |
| 15:39.34 | richardf | Would probably also need to detect timestamp rollaround as well and clear the list |
| 15:39.48 | putnopvut | This is getting complicated... |
| 15:43.24 | putnopvut | patch uploaded to 17571 |
| 15:46.30 | Entomologist | *** CLOSED (17576) [Applications/app_queue] [patch] Cannot join a queue when all members are paused and "joinempty=no". |
| 15:46.30 | Entomologist | Reported by: ramonpeek |
| 15:46.30 | Entomologist | https://issues.asterisk.org/view.php?id=17576 |
| 15:46.31 | Entomologist | ********************************************************* |
| 15:47.56 | *** join/#asterisk-bugs elliot98 (~elliot@unaffiliated/elliot98) |
| 15:48.08 | richardf | I think the window should be bigger than 5 |
| 15:48.16 | richardf | 50 is probably a safe figure |
| 15:49.29 | putnopvut | richardf: I can update it. |
| 15:50.47 | putnopvut | patch updated |
| 15:51.32 | *** join/#asterisk-bugs elguero (~miguel323@12.187.84.162) |
| 15:53.41 | richardf | putnopvut: is that patch against trunk? |
| 15:53.48 | richardf | or a branch? |
| 15:57.20 | richardf | guessing its 1.4 - I have manually applied it to my test trunk system |
| 15:57.31 | richardf | will test and report back tomorrow |
| 16:05.26 | putnopvut | against 1.4, sorry. |
| 16:05.55 | putnopvut | thanks! I probably won't follow up on it until Tuesday since I'll be traveling this weekend and am off work Monday. |
| 16:10.19 | richardf | putnopvut: Thanks for doing the patch. Have tested DTMF and works fine. Will check the ssrc rollover tomorrow. |
| 16:10.36 | putnopvut | richardf: cool beans! |
| 16:11.56 | richardf | s/ssrc/seqno :) |
| 16:12.03 | richardf | goodnight |
| 16:12.14 | richardf | here anyway |
| 16:56.43 | *** join/#asterisk-bugs elguero (~miguel323@12.187.84.162) |
| 17:09.50 | Entomologist | *** CLOSED (17564) [Resources/General] [patch] Asterisk "locks up" the system when an external process is called from the 'h' extension with a lower priority than Aste |
| 17:09.51 | Entomologist | Reported by: ramonpeek |
| 17:09.51 | Entomologist | https://issues.asterisk.org/view.php?id=17564 |
| 17:09.52 | Entomologist | ********************************************************* |
| 21:12.10 | *** join/#asterisk-bugs pabelanger-lap (~pabelange@CPE001fe2a8fd1d-CM0012254094b2.cpe.net.cable.rogers.com) |
| 21:36.44 | Entomologist | *** CLOSED (17407) [Core/General] [patch] DEADLOCK_AVOIDANCE can actually generate dealocks |
| 21:36.44 | Entomologist | Reported by: pdf |
| 21:36.45 | Entomologist | https://issues.asterisk.org/view.php?id=17407 |
| 21:36.45 | Entomologist | ********************************************************* |
| 22:41.25 | *** join/#asterisk-bugs Entomologist (~nobody@nat/digium/x-jpakxtxofwwpwune) |
| 22:41.25 | *** join/#asterisk-bugs Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 22:41.25 | *** mode/#asterisk-bugs [+o Qwell] by zelazny.freenode.net |