| 00:19.57 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:19.57 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 01:43.56 | *** join/#asterisk-dev kg6hum (~kg6hum@protovision.org) |
| 01:57.39 | kg6hum | I was considering updating the Project MF patches to work with current versions of Asterisk. Would there be any interest in adding those features to the official releases? |
| 06:10.53 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:10.53 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:01.34 | *** join/#asterisk-dev CELYA_ (~Thunderbi@185.122.102.37) |
| 07:32.25 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 07:40.37 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.57) |
| 10:13.23 | *** join/#asterisk-dev pchero (~pchero@176-23-78-252-cable.dk.customer.tdc.net) |
| 12:15.42 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:384f:ec65:f553:cf6f) |
| 13:50.13 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-xffixzejnzuuyrgw) |
| 13:50.13 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:03.06 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dirnfywwvdkrdftx) |
| 14:03.06 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:10.03 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 14:48.29 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-amwypiahdlcglkig) |
| 14:48.29 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:53.06 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:53.06 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:28.03 | cresl1n | rmudgett: ping |
| 15:28.17 | rmudgett | ? |
| 15:28.38 | cresl1n | for your CHECK_BLOCKING work.... |
| 15:28.43 | cresl1n | what's your ultimate goal? |
| 15:29.08 | cresl1n | Is it to remove the macro? |
| 15:29.44 | file | bford: did you check the sequence numbers and timestamps on the outgoing traffic to the browser? |
| 15:29.45 | rmudgett | Fix any places where there are two threads handling a channel's media at the same time. The CHECK_BLOCKING macro is a good place where that situation is detectable. |
| 15:29.54 | cresl1n | So.... |
| 15:30.05 | cresl1n | keep the macro and fix any problems that are uncovered by it? |
| 15:30.14 | rmudgett | There used to be a DO_CRASH in that macro which was removed about six years ago. |
| 15:30.18 | cresl1n | yeah.... |
| 15:30.29 | rmudgett | I'm putting it back in as an assert. |
| 15:30.48 | bford | i looked at the sequence numbers, particularly at the adjustment code, and it looked valid to me |
| 15:30.56 | rmudgett | This is how I've found three ways that we had two threads attempting to handle media at the same time. |
| 15:30.59 | cresl1n | rmudgett: so keep the macro and fix any problems uncovered by it? |
| 15:31.07 | rmudgett | yep |
| 15:31.08 | file | bford: what's the gap in media like? |
| 15:31.08 | cresl1n | ok |
| 15:31.49 | cresl1n | rmudgett: second question - are there places that we need to add more instances of CHECK_BLOCKING() for proving some things are safe? |
| 15:31.59 | bford | it hits the dropped packet and looks like it has about a quarter of a second or so where it is waiting on the NACK to start processing frames again |
| 15:32.22 | file | bford: for testing can you reduce that and see? |
| 15:32.38 | bford | yeah, give me just a sec to change |
| 15:32.39 | rmudgett | The CHECK_BLOCKING macro is a hint to the ast_queue_frame and masquerade code to wake up the media handling thread that something changed. |
| 15:32.45 | cresl1n | yeah |
| 15:33.01 | cresl1n | and the hangup code, IIRC? |
| 15:33.33 | rmudgett | yep but hat is just a check to see if something is wrong. |
| 15:33.36 | cresl1n | yeah |
| 15:37.19 | bford | file: i bumped down to buffer size 10, 6, 4, none of them improved |
| 15:37.27 | file | interesting |
| 15:38.01 | file | and your browser side logging showed an SRTP problem? |
| 15:38.20 | file | and it goes through SRTP encryption fine on our side? |
| 15:39.24 | bford | encryption for certain RTP packets, couldn't tell if it was the same ones or not since encryption, but it does look like it goes through fine, it isn't complaining about being able to unprotect |
| 15:39.49 | file | the browser isn't complaining? |
| 15:40.28 | bford | asterisk isn't, ill have to switch over to firefox real quick so i can bring up the debug for chromium again for exact messages |
| 15:48.33 | coreyfarrell | rmudgett: FYI I tried adding assert to CHECK_BLOCKING it caused testsuite failures. https://gerrit.asterisk.org/#/c/8075/1 |
| 15:52.10 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.166) |
| 15:54.33 | rmudgett | coreyfarrell: The failures were because AMI PlayDTMF does a safe sleep to process media when that thread is not the one supposed to be handling the media. ARI has a similar scenario when it plays DTMF but ARI uses a different function to play the DTMF. The third scenario I've seen is ARI/AMI executing a dialplan function like SHELL or CURL which puts the channel into autoservice when the thread isn't handling the media. |
| 15:54.55 | bford | file: with firefox i do see replay check failures with SRTP protect |
| 15:55.01 | file | very interesting |
| 15:55.03 | rmudgett | CHECK_BLOCKING is the wrong name for what it does it is more like SET_BLOCKING |
| 15:57.49 | rmudgett | It is really SET_BLOCKING and there is no need to return a value. |
| 16:00.58 | file | hrm de dum |
| 16:03.42 | file | bford: it's very much acting like the packet contents aren't... quite right... odd |
| 16:04.14 | bford | of the resent packets? |
| 16:04.29 | file | yeah |
| 16:04.42 | bford | hmm... |
| 16:06.00 | file | ponders |
| 16:07.47 | rmudgett | watches |
| 16:12.05 | bford | file: i've been looking through a bunch of logging and while it's kind of hard to keep track of where everything is, i do see same packet sent out twice (assuming it's for the NACK) and timestamp is the same as when it got sent out first time since frdup, could it be having issues with that? |
| 16:12.21 | file | you need to be specific in what direction |
| 16:12.45 | file | I don't think the incoming retransmitted packet is the problem, it seems to be the same as the original |
| 16:13.40 | bford | side A is sending packets, gets a NACK for one that side B missed, side A sends it back out and it has same timestamp as when it sent it out initially because it's just a duped frame |
| 16:13.55 | file | yes |
| 16:14.28 | bford | yes that's an issue? |
| 16:14.44 | file | no, I was just acknowledging your statement |
| 16:14.50 | bford | ok, just wondering |
| 16:18.42 | file | ponders further |
| 16:20.53 | file | bford: I changed your test code so it only drops 1 packet and then carries on, it reduces the amount of stuff to look through |
| 16:21.45 | bford | all good, it IS test code :p |
| 16:24.29 | file | it's acting as if the video payload is corrupted |
| 16:25.50 | file | [1:116:0619/131809.281926:WARNING:generic_decoder.cc(239)] Failed to decode frame with timestamp 345336990, error code: -1 |
| 16:27.09 | bford | via chromium, right? |
| 16:27.12 | file | yes |
| 16:28.24 | bford | so it sounds like it's something going on with the resent packet, and maybe something needs to be adjusted and not sent as is |
| 16:28.38 | file | bford: there is a test you could do - don't buffer the packets that came after the missed one... |
| 16:28.46 | file | let the browser reorder them, and see what happens |
| 16:29.11 | bford | ok ill take a look |
| 16:33.09 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 16:33.52 | bford | file: getting rid of buffer functionality yields same result |
| 16:34.05 | file | very interesting |
| 16:34.52 | file | bford: can you add code to check the payload contents between the original packet and the retransmitted packet? |
| 16:35.02 | file | (after SRTP unprotect) |
| 16:35.24 | bford | yep, give me just a sec, checking something else with removal of buffer |
| 16:38.26 | bford | ok that didn't work either |
| 16:38.26 | bford | so, add code to check after protect on send, after unprotect on recv? |
| 16:38.44 | file | no |
| 16:39.00 | file | when you drop the packet in your test code, store the payload of it |
| 16:39.09 | bford | ok |
| 16:39.10 | file | when you receive that retransmitted packet, compare the payload to the stored |
| 16:39.15 | file | so you can confirm the contents are the same |
| 16:51.51 | file | bford: I think it's your test |
| 16:51.53 | file | er |
| 16:51.54 | file | test code |
| 16:52.14 | bford | hm? |
| 16:52.27 | file | I'll explain in a sec |
| 16:54.43 | file | bford: I think sending the packet through SRTP unprotect twice breaks the internal state |
| 16:54.56 | file | if I drop the packet straight off the wire, then your thing works fine |
| 16:56.04 | bford | ahh, ok, so it kind of goes back to the replay attack, and since we already saw the packet with how i was dropping, it flips out |
| 16:56.35 | file | packet gets dropped, subsequent packets get buffered, NACK happens, retransmitted packet comes in, buffer empties, RTP goes out |
| 16:56.37 | file | video doesn't freeze |
| 16:56.58 | file | and you can tell if the packet is video or not by doing a "len > 2" |
| 16:57.00 | file | er |
| 16:57.02 | file | "len > 200" |
| 16:59.05 | bford | noted. ok, i think last thing to do then is account for seqno cycle so the missing vector doesn't explode |
| 16:59.34 | file | do the above and make sure I'm not crazy :D |
| 17:02.11 | rmudgett | It is impossible to prove a negative. |
| 17:03.13 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d001c10a536480750f8.ipv6.abo.wanadoo.fr) |
| 23:03.46 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dirnfywwvdkrdftx) |
| 23:36.35 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:36.35 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |