| 00:33.19 | *** join/#asterisk-dev tompaw (~tompaw@tompaw.xxx) |
| 01:18.15 | *** join/#asterisk-dev zerohalo (~zerohalo@uranium.zerohalo.net) |
| 02:38.24 | *** join/#asterisk-dev zerohalo (~zerohalo@uranium.zerohalo.net) |
| 02:45.22 | *** join/#asterisk-dev zerohalo (~zerohalo@uranium.zerohalo.net) |
| 06:56.22 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:06.43 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 08:03.14 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::10de) |
| 08:04.23 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:16.09 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:16.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:06.29 | dan_j | https://www.irccloud.com/pastebin/4E3MSUdQ/ |
| 09:07.29 | dan_j | Hi. Does anyone know if this is a known issue? 13.14 was running fine and then I added some resource lists and within 12 hours, that segfault occurred. |
| 09:56.03 | dan_j | pjsip 2.5.5 |
| 11:12.47 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 11:39.29 | *** join/#asterisk-dev tuxian_ (~tuxian@194.12.3.78) |
| 12:04.24 | *** join/#asterisk-dev tuxian_ (~tuxian@igilmour.plus.com) |
| 12:06.51 | *** join/#asterisk-dev Marquis42 (~Marquis42@d14-69-130-192.try.wideopenwest.com) |
| 12:06.51 | *** mode/#asterisk-dev [+o Marquis42] by ChanServ |
| 12:35.40 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::152e) |
| 13:16.06 | *** join/#asterisk-dev newtonr (~newtonr@173-17-133-211.client.mchsi.com) |
| 13:16.06 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 13:54.21 | seanbright | only two open reviews?! whaaaaa |
| 13:54.38 | seanbright | i guess it's quittin' time |
| 13:55.30 | file | seanbright: cray cray eh |
| 13:55.41 | seanbright | nice work |
| 13:56.04 | seanbright | tzafrir: fix this shit, we're going for a clean slate: https://gerrit.asterisk.org/#/c/5113 |
| 13:56.09 | seanbright | heh\ |
| 14:12.19 | file | be our guest, be our guest, put Gerrit to the testttttt |
| 14:19.39 | seanbright | so why is python 3 support important? |
| 14:22.32 | *** join/#asterisk-dev gedia (~gd@hq.modulus.gr) |
| 14:22.33 | seanbright | also - shouldn't the jenkins slaves have dahdi installed on them so chan_dahdi is actually built? |
| 14:23.14 | file | Python 2.7 goes EOL in like 3 years, so it's a "look into it and do it in the future" |
| 14:23.35 | tzafrir | seanbright, thanks. |
| 14:23.42 | file | and that's a super idea! some could |
| 14:23.48 | file | some are containers, though |
| 14:23.51 | tzafrir | Also: it gave me no build warning on my system. |
| 14:24.22 | tzafrir | (GCC 6.3) |
| 14:24.45 | file | it failed on... |
| 14:24.51 | file | Fedora 25 |
| 14:24.55 | seanbright | c99 allows mixed code and declarations i believe |
| 14:25.00 | seanbright | but don't quote me on that |
| 14:25.16 | gedia | file: hey! remember me? I'm the one with the weird issue of asterisk ignoring ACKs to 200 OKs it sent... I got some more verbose output about this which includes "chan_sip.c: Invalid SIP message - rejected , no callid, len 392" does this ring any bells? |
| 14:25.41 | file | gedia: not really, could be something in the chan_sip parser |
| 14:26.18 | seanbright | fucking fedora |
| 14:26.22 | gedia | call id is "Call-ID: 020AD0B6D18140000000002C@192.168.254.160" in both ACK and 200 OK... |
| 14:27.40 | seanbright | gedia: is there an open jira issue? |
| 14:28.11 | gedia | no, I wanted to gather more information first. i mean I don't know how to search jira for duplicates yet... |
| 14:29.23 | seanbright | well, create an issue with all of your debug info in it |
| 14:29.28 | seanbright | we'll find the dupe if it's there |
| 14:29.56 | gedia | will do.. thanks |
| 14:44.14 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.38.95) |
| 14:54.00 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:54.00 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:54.30 | cresl1n | gerrit gerrit gerrit |
| 14:54.46 | cresl1n | I've never seen the review list so short |
| 14:58.58 | file | cresl1n: what are you going to fill your Gerrit time with? |
| 15:01.52 | file | cresl1n: ooo bread baking |
| 15:02.02 | cresl1n | Not sure⦠I'm looking at Tzafrir's patch right now |
| 15:02.57 | dan_j | Not having a very good time with pjsip and asterisk 13. Three different crashes now. |
| 15:03.00 | dan_j | https://www.irccloud.com/pastebin/HU1NRmtD/ |
| 15:03.18 | dan_j | Thats the third one. |
| 15:05.15 | cresl1n | Looks like it's in the middle of sending a notify, right file? |
| 15:05.32 | file | yes |
| 15:06.21 | cresl1n | what version dan_j? |
| 15:06.30 | dan_j | 13.14.0 |
| 15:06.36 | cresl1n | lovely |
| 15:06.47 | file | could be the same underlying problem as https://issues.asterisk.org/jira/browse/ASTERISK-26669 and https://issues.asterisk.org/jira/browse/ASTERISK-26675 |
| 15:07.11 | dan_j | Got a different crash earlier |
| 15:08.07 | cresl1n | How do you figure it's the same as 26675? |
| 15:08.54 | cresl1n | and 26669 now that I look more at it |
| 15:09.10 | file | cresl1n: it screwed up reference counting |
| 15:09.20 | file | which could impact the transport reference count |
| 15:09.25 | cresl1n | oooh |
| 15:09.35 | file | and one of the earlier pastebins showed decrementing the transport ref |
| 15:09.41 | cresl1n | interesting |
| 15:09.52 | cresl1n | 'it screwed up' - being? |
| 15:10.00 | cresl1n | it being what in this case |
| 15:10.29 | file | of the tdata, which holds refs to other things |
| 15:11.30 | file | that's my best guess, haven't seen any other crashes specifically like that |
| 15:11.47 | cresl1n | ok |
| 15:12.33 | dan_j | I'm running an identical server but 13.14.0-rc1 with pjsip 2.4.5 that seems to be ok for now. |
| 15:12.48 | dan_j | this one is 13.14.0 with 2.5.5 |
| 15:13.15 | file | bundled, or your own? |
| 15:13.20 | file | I assume your own |
| 15:13.26 | dan_j | 2.5.5 bundled. |
| 15:13.31 | dan_j | and crashing |
| 15:13.44 | dan_j | 2.4.5 was installed before bundled was available |
| 15:13.54 | cresl1n | I wonder if he'll still see it with 2.6.0 |
| 15:14.50 | file | unknown |
| 15:15.21 | dan_j | will 13.14.0 bundled now install 2.6.0, or do I need to install it manually until the next asterisk release? |
| 15:15.56 | file | 13.14.0 did not include 2.6 |
| 15:16.43 | dan_j | Ok. Thats what I thought. I'll install it manually in 5 hours when hardly anyone uses it. |
| 15:17.45 | dan_j | thanks |
| 15:18.34 | file | and if still a problem, file ye ol' JIRA issue |
| 15:18.57 | dan_j | no idea how to describe it as it seems to be totally random |
| 15:19.32 | file | console output, full backtrace, version details, and vague description of system usage |
| 15:19.39 | file | and you'd be ahead of some of the issues reported >_> |
| 15:19.41 | *** join/#asterisk-dev stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 15:21.13 | dan_j | Noted. Will start reinstalling asterisk 11 in the meantime. Dont want to lose clients over this. |
| 15:22.26 | dan_j | Any idea how Asterisk Certified Support would assist with these crash issues? Trying to decide if it's worth it, but can't see how they could help unless they've got developers on hand to quickly debug coding issues. |
| 15:23.03 | file | nudges cresl1n |
| 15:24.19 | cresl1n | dan_j: generally speaking, L5 support involves an SLA |
| 15:24.46 | cresl1n | so instead of getting to it when we can fit it in, bugs in that category go to the top of the queue |
| 15:25.54 | dan_j | What about L3? |
| 15:26.02 | stefan27 | Is there any known problems with a call flow case as described in http://imgur.com/a/jmdjS where asterisk INVITEs a sip proxy which forwards the invite back to itself... Setting up such a call seems to work, but are there any known call control features which might break in this setup? Are the two sip channels completely unrelated under the hood despite the fact they are both having a |
| 15:26.02 | stefan27 | dialogue with the same Call-ID (but one is Dial() and other is AppDial())? |
| 15:26.17 | cresl1n | the only one that has an SLA and engineering support attached is an L5 |
| 15:26.35 | cresl1n | for better or worse |
| 15:27.36 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-osyenxaeitsvbtjv) |
| 15:27.36 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:31.01 | dan_j | Ok. Im not large enough to be able to afford L5. Will bear it in mind in the future. |
| 15:34.33 | stefan27 | so I guess in my case chan_sip has 2 different dialogues with same values of CallID and from tag and to-tag, but since asterisk is UAC for first dialog and UAS for second dialog it doesn't violate any uniqueness constraints? |
| 15:35.47 | cresl1n | stefan27: that seems like it would be troubling, but I'm not a pjsip expert |
| 15:36.10 | file | cresl1n: he is using chan_sip |
| 15:36.17 | cresl1n | onsp. |
| 15:38.08 | stefan27 | I could ask the question for chan_sip. We will migrate *some day* :) |
| 15:38.13 | stefan27 | I meant pj_sip too* |
| 15:38.30 | stefan27 | The grand refactoring in the sky |
| 15:38.54 | file | I don't know how chan_sip behaves for that these days |
| 15:38.57 | file | chan_pjsip is fine with it |
| 15:39.24 | file | if it's working though, yolo? |
| 15:39.48 | stefan27 | yolo is my company's policy; but I'm a pessimist so I try to be proactive |
| 15:40.27 | stefan27 | but if it's too difficult to predict possible problems and too time-consuming to test everything, yolo is what we have to do |
| 15:40.35 | stefan27 | It will be a rare call flow either way |
| 15:42.02 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.38.95) |
| 15:53.35 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-cvzqurqmjoklhskt) |
| 15:53.35 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:54.09 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.38.95) |
| 15:54.35 | *** join/#asterisk-dev tuxd00d (~tuxd00d@m880436d0.tmodns.net) |
| 16:25.04 | gtjoseph | putnopvut: would you ahve heartburn if i refactored sdp_repr to just sdp? |
| 16:25.44 | gtjoseph | sdp_repr just "sticks" somehow. |
| 16:26.21 | putnopvut | I'm fine with it. |
| 16:26.44 | putnopvut | Most of the time, I'm not too happy with my naming of things, and I'm fine for it to change. |
| 16:26.55 | gtjoseph | cool, thanks. one more... |
| 16:27.34 | gtjoseph | how about changing the declarations of the lines in ast_sdp from structures to strucure pointers? |
| 16:27.50 | gtjoseph | easier to generate and pass around |
| 16:28.51 | gtjoseph | and pulling ast_sdp.o_line up into a first-class structure as well. |
| 16:31.27 | gtjoseph | putnopvut: ^^ |
| 16:32.32 | putnopvut | Well, I had made them structures instead of pointers in some attempt to keep the structure as contiguous as possible. Making o_line a first class structure is fine if it's convenient. |
| 16:33.06 | gtjoseph | what was the reasoning for "contiguous"? |
| 16:33.39 | putnopvut | I have it in my mind that fewer allocations means the memory stays closer together, and that in the end can mean a more cache-friendly experience. |
| 16:34.10 | putnopvut | And in my mind, I'm not optimizing prematurely here because it's not any more of a burden to use structures over pointers to structures. |
| 16:34.48 | gtjoseph | it is when you have tgo generate them |
| 16:35.13 | gtjoseph | ast_sdp_create_a_line |
| 16:35.18 | gtjoseph | ast_sdp_create_m_line |
| 16:35.32 | gtjoseph | really need to return pointers not structures |
| 16:35.37 | putnopvut | If it'll make it easier, then go for it. |
| 16:35.42 | gtjoseph | kk, thanks |
| 16:57.15 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-cjxvcqjeoccohhzw) |
| 16:57.15 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 18:11.07 | rmudgett | file: The chan_dahdi patch cold be cherry-picked. It is really just a cleanup patch. |
| 18:11.20 | file | make it so? |
| 18:13.09 | rmudgett | sure |
| 18:14.27 | rmudgett | Just looked at what changed from v13 to master. The main differences were dealing with callid tracing. |
| 18:17.41 | rmudgett | Another was the removal of relative channel naming. |
| 18:30.39 | rmudgett | cherry-picked |
| 18:44.24 | tzafrir | It should apply cleanly (I originally wrote it for 13). However, |
| 18:45.26 | tzafrir | I now manage to crash asterisk with the same operation. This time __ast_read() gets annoyed of a null pointer |
| 18:46.23 | file | would you like us to not merge the change? |
| 18:46.42 | tzafrir | http://paste.debian.net/917679/ |
| 18:46.51 | tzafrir | Right. Not right now. |
| 19:16.25 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.17.241) |
| 19:24.57 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 19:24.57 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 20:11.08 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.17.241) |
| 20:30.16 | tzafrir | dahdi_read returns NULL in some cases. Shouldn't it return &ast_null_frame in those cases? |
| 20:30.32 | tzafrir | I suspect the crash above is cases by one of the other cases. |
| 20:30.58 | tzafrir | dahdi_read: in chan_dahdi.c |
| 20:31.33 | tzafrir | After some initial tests I can no longer easily crash it. I'll let this loop over the weekend. |
| 20:43.01 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d007d6e68c2d1d0bde7.ipv6.abo.wanadoo.fr) |
| 20:51.37 | *** join/#asterisk-dev tuxd00d (~tuxd00d@184-98-17-72.phnx.qwest.net) |
| 20:53.29 | rmudgett | A NULL return from dahdi_read mean the channel has hung up. This is true for all channel drivers. |
| 20:54.19 | rmudgett | The crash in your earlier pastebin was showing the channel tech as NULL because the channel was likely being hungup. |
| 20:54.23 | rmudgett | tzafrir: ^^^ |
| 21:05.06 | tzafrir | OK. Thanks. |
| 21:11.17 | gtjoseph | @putnopvut: did you create an ast_sdp -> text dumper already? |
| 21:15.38 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@184-98-17-72.phnx.qwest.net) |
| 21:19.13 | putnopvut | gtjoseph: no. We discussed that in a standup and the feeling was that an internal SDP to string (and vice versa) translator was not necessary towards moving forward. |
| 21:19.37 | gtjoseph | yep ok. would be handy for testing though. |
| 22:00.47 | putnopvut | I am finding RTCP behavior in Asterisk to be rather ... funky |
| 22:01.01 | putnopvut | I keep wondering what I'm doing wrong in my patch. Then I revert to unmodified and find the same behavior there. |
| 22:01.09 | putnopvut | So I just take note and move on. |
| 22:01.12 | file | *surprise* |
| 22:01.16 | putnopvut | Example |
| 22:01.29 | putnopvut | If I originate a call from Asterisk A to Asterisk B, and have Asterisk play a file back |
| 22:01.37 | putnopvut | Then both Asterisk boxes send RTCP reports to each other. |
| 22:02.06 | putnopvut | And I think by typing this I may have answered my own quesiton. |
| 22:02.12 | file | sweet |
| 22:02.20 | putnopvut | My situation I was about to outline was one where a phone calls through Asterisk A to Asterisk B |
| 22:02.25 | putnopvut | But I bet a local RTP bridge is happening there |
| 22:02.33 | putnopvut | And that's why I see no RTCP reports from Asterisk A |
| 22:03.11 | putnopvut | Because even though direct media is disabled, the codecs are common between them. I need to enable some DTMF features or something and see if I still see the same thing happening. |
| 22:03.55 | putnopvut | Yep, that did it. |
| 22:04.02 | putnopvut | Thanks for being my rubber duck, #asterisk-dev |
| 22:12.21 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@184-98-17-72.phnx.qwest.net) |
| 22:28.24 | putnopvut | Other RTCP oddities I've seen: |
| 22:28.41 | putnopvut | * When RTCP debug is enabled, then incoming RTCP reports try to print an uninitialized ast_sockaddr |
| 22:28.50 | putnopvut | * RTCP reports get sent long after the call is over. |
| 22:29.36 | file | putnopvut: fun times ahead, then |
| 22:30.05 | putnopvut | Basically all of these things have made me question today if I messed something up |
| 22:30.19 | putnopvut | And then I test on plain Asterisk and go "nope it was already like that" |
| 22:33.35 | *** join/#asterisk-dev tuxd00d_ (~tuxd00d@184-98-17-72.phnx.qwest.net) |
| 22:38.43 | gtjoseph | putnopvut: are you assuming that c lines will never have anything other than IN for the network type? |
| 22:39.46 | putnopvut | Yes |
| 22:40.12 | gtjoseph | ok same for o line then |
| 23:05.10 | putnopvut | I bet https://issues.asterisk.org/jira/browse/ASTERISK-26511 is why I was seeing RTCP traffic after the call was over. |
| 23:25.10 | *** join/#asterisk-dev tuxd00d (~tuxd00d@172.56.17.137) |
| 23:55.56 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-24-248-81-186.ph.ph.cox.net) |