| 00:39.28 | *** join/#asterisk-dev pchero (~pchero@211.178.226.108) |
| 00:39.28 | *** mode/#asterisk-dev [+o pchero] by ChanServ |
| 01:29.57 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.102) |
| 01:29.57 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 03:42.36 | *** join/#asterisk-dev electronic_eel (~quassel@213.240.182.16) |
| 06:38.22 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 06:38.22 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:53.57 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:53.57 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 12:44.50 | jkroon | file, looks like the memory leak (? assumed) relates to batched CDRs. |
| 12:45.24 | file | ok |
| 12:51.15 | jkroon | will see if we can debug it, but we don't reckon it's required for us after fixing the raid controller that was causing backlog on non-batched cdr processing. |
| 14:39.54 | seanbright | so my understanding is that the if/when the marker bit in an RTP packet is set depends on the RTP profile |
| 14:41.08 | seanbright | and RTP/AVP says that it is always 0 unless you have silence suppression |
| 14:43.11 | seanbright | so in ASTERISK-29295 i don't see what the problem is - other than the timestamp not increasing monotonically |
| 14:43.21 | seanbright | i don't see what is the problem with the marker bit is, i should say |
| 14:45.41 | file | seanbright: the problem is getting a remote endpoint to reset its synchronization - it doesn't see the timestamp jump as causing it, so it causes the audio to go... wrong |
| 14:46.00 | file | setting the marker bit has been shown to cause some implementations to do so |
| 14:46.15 | file | I want to say Sonus switches are one of the offenders |
| 14:46.54 | seanbright | would manipulating the timestamp also work? |
| 14:47.05 | file | theoretically yes |
| 14:48.30 | file | personally I've found trying to do that kind of translating difficult, I had to do it for sequence numbers and that was hellish |
| 14:48.38 | file | and it still throws its hands up at times |
| 14:49.59 | seanbright | i mean i'm fine with whatever, but i just wanted to be clear that the bug being reported (the marker bit not being set) is not the actual bug (non-monotonically increasing timestamp) |
| 14:50.40 | file | the marker bit not being set is how that has been resolved in the past, and is what chan_sip does - there are explicit RTP APIs for doing it |
| 14:50.46 | file | not being set? being set |
| 14:51.38 | seanbright | right. but we keep the sequence number and the ssrc consistent across multiple source streams. like doing the same for timestamps would be the right thing to do. |
| 14:51.41 | file | marker bit gets set, remote side takes it that the world is not as it once was, resets things, picks up new stream |
| 14:51.51 | seanbright | anyway, just wanted to understand more |
| 14:52.23 | seanbright | from the remote side's perspective there is never a new stream to pick up |
| 14:52.56 | seanbright | but i get that it is a workaround |
| 14:57.14 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb09b0048badf4f5c3826d4d31bb.ipv6.abo.wanadoo.fr) |
| 15:31.43 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-fgxukqnxeomeacnw) |
| 15:31.43 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:40.24 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-ablyirrsbdekmeio) |
| 15:40.24 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:14.18 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 16:21.51 | *** join/#asterisk-dev rmudgett (~rmudgett@170.249.191.178) |
| 16:21.51 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 17:02.01 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.102) |
| 17:02.01 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 17:43.58 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.102) |
| 17:43.58 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 17:53.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lfbn-nan-1-1995-213.w90-105.abo.wanadoo.fr) |
| 20:34.55 | jkroon | in Gosub() code (app_stack) there is code to mask ARGn when pushing the stack, however, if func_odbc is used inside a frame where there exists ARGn variables, these are leaked into func_odbc if insufficient arguments are passed. |
| 20:35.03 | jkroon | (refer discussion in #asterisk) |
| 20:35.13 | jkroon | two strategies to "fix": |
| 20:35.40 | jkroon | 1. Utilize same masking strategy (ie, set ARG1 through ARG?? to "") |
| 20:35.54 | jkroon | 2. Expose an ARGC variable containing the count of passed arguments. |
| 20:36.09 | jkroon | which would be preferable? |
| 20:37.15 | jkroon | I suspect 1 will require iterating all variables since the frames are kept locally inside app_stack. |
| 20:38.10 | jkroon | Gosub() already exposes ARGC as well, so I'm inclined to add that anyway as well. |
| 20:42.40 | seanbright | the interest level is sufficiently low that whatever you propose & patch will ultimately be the chosen path |
| 20:48.52 | jkroon | also, would adding a config option like minargs be sensible, if set, enforce that at least that number of ARGS is passed to func_odbc. |
| 20:49.25 | jkroon | seanbright, just adding ARGC for now then, and I'll see if minargs is easy enough (think it would be a nice safety for users) |
| 21:01.47 | jkroon | seanbright, thank you, fix pushed (https://gerrit.asterisk.org/c/asterisk/+/15448). changes for minargs will conflict with that (I think), ok to tack onto same review? |
| 21:10.17 | seanbright | you're the author of the change |
| 21:10.23 | seanbright | you do you |
| 21:10.56 | jkroon | ok, was thinking there might be a preferred mechanism. |
| 21:15.04 | seanbright | shrugs |
| 21:15.06 | seanbright | YOLO |
| 21:43.41 | jkroon | seanbright, if by some fluke you perhaps have two minutes to just eyeball https://gerrit.asterisk.org/c/asterisk/+/15448 for me please? (not major, works on my test host but it's always nice to get a second opinion) |
| 22:06.54 | *** join/#asterisk-dev sduthil (~sduthil@198-48-220-170.cpe.pppoe.ca) |
| 22:20.57 | seanbright | code reviews on gerrit always get multiple opinions |
| 22:21.21 | seanbright | i don't fully understand the problem you're addressing and i don't have a lot of interest in it |
| 22:21.26 | seanbright | someone will review it though |
| 22:23.43 | jkroon | thanks for taking the time. |
| 23:20.10 | *** join/#asterisk-dev Gugge (gugge@guggemand.dk) |