| 00:11.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 00:11.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 04:03.50 | *** join/#asterisk-dev tompaw (~tompaw@tompaw.xxx) |
| 06:00.53 | *** join/#asterisk-dev oej (~oej@no-gmo001-oag01.nextgentel.net) |
| 06:00.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:04.10 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:30.36 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:42.16 | *** join/#asterisk-dev CELYA_ (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 07:44.21 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.34) |
| 07:53.47 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.34) |
| 07:57.12 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::152e) |
| 10:02.32 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 12:11.23 | *** join/#asterisk-dev oej (~oej@77.241.110.22) |
| 12:11.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:03.03 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:08.38 | *** join/#asterisk-dev gedia (~gd@hq.modulus.gr) |
| 14:18.17 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LStLambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 14:34.21 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 14:42.10 | *** join/#asterisk-dev tuxian_ (~tuxian@194.12.3.78) |
| 14:42.36 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:42.36 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:46.04 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 14:47.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-jgwqtnjeexgwlfmw) |
| 14:47.15 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:50.38 | cresl1n | gtjoseph: wrt to https://gerrit.asterisk.org/#/c/5075/2/res/res_pjsip.c |
| 14:50.44 | cresl1n | and good morning btw :-) |
| 14:50.46 | gtjoseph | yep? |
| 14:50.55 | gtjoseph | and to you! |
| 14:51.02 | cresl1n | Why is my brain not seeing why that change is necessary? |
| 14:51.13 | cresl1n | it seems pointless |
| 14:51.18 | cresl1n | is there compiler magic happening? |
| 14:52.21 | cresl1n | or did I completely miss something |
| 14:52.34 | gtjoseph | pj_pool_release is not a simple free. There's a lot of logic going on under the hood so the idea is to null "memory_pool" so other threads can't use it while pj_)pool_release si cleaning up the temp pointer. |
| 14:52.35 | file | woah it's cresl1n |
| 14:52.49 | cresl1n | hey file |
| 14:52.58 | file | hello! |
| 14:53.07 | gtjoseph | in our use case it probably doesn't matter because of where we call pj_pool_release but it's a safe change. |
| 14:53.17 | cresl1n | pulls more context into the diff view |
| 14:53.27 | cresl1n | awww crap |
| 14:53.31 | cresl1n | I thought that was a local variable |
| 14:53.38 | cresl1n | sorry gtjoseph |
| 14:53.45 | cresl1n | good call |
| 14:53.45 | gtjoseph | no worries. good question. |
| 14:53.55 | cresl1n | I was using diff view on gerrit |
| 14:54.15 | gtjoseph | yeah that gets me all the time. |
| 14:55.17 | cresl1n | ok, same stupid question in res_pjsip_history |
| 14:55.21 | cresl1n | https://gerrit.asterisk.org/#/c/5075/2/res/res_pjsip_history.c |
| 14:55.25 | cresl1n | what am I missing this time |
| 14:55.34 | cresl1n | that seems local |
| 14:55.39 | cresl1n | ish |
| 14:55.41 | cresl1n | same worry? |
| 14:55.58 | cresl1n | somebody might use the pool when they shouldn't while the destructor is running? |
| 14:56.06 | gtjoseph | yeah, entry->pool isn't local |
| 14:56.38 | gtjoseph | although again... for us it's pretty safe since nothing SHOULD be using it at this point |
| 14:56.45 | cresl1n | that's what I was thinking |
| 14:56.52 | cresl1n | yeah, meant local to the object being destroyed in this case |
| 14:56.53 | cresl1n | sorry |
| 14:56.57 | file | if something is using it when the destructor is called, then we've got bigger problems |
| 14:57.09 | cresl1n | that's kind of what I was wondering |
| 14:57.38 | gtjoseph | yep. I can take them out |
| 14:57.54 | cresl1n | no need |
| 14:58.00 | cresl1n | sometimes I just ask questions to understand :-) |
| 14:58.05 | cresl1n | that's why I did it here |
| 15:08.09 | cresl1n | I'm trying to decide if you need to do with https://gerrit.asterisk.org/#/c/5075/2/res/res_rtp_asterisk.c |
| 15:08.12 | cresl1n | but I'm not sure yet |
| 15:08.28 | gtjoseph | file: just saw your question on the registration reload patch, sorry. |
| 15:08.37 | cresl1n | I'm thinking probably not, but there are a few different places that pool could be used I think |
| 15:08.38 | file | what what? oh |
| 15:09.21 | gtjoseph | cresl1n: yep, i just did a search for where we do pj_pool_release and added the logic. |
| 15:09.27 | cresl1n | that's what I figured |
| 15:27.25 | gtjoseph | file: thinking on streams and have 2 questions... |
| 15:27.43 | gtjoseph | 1. shouldn't you be able to read from a specific stream? |
| 15:28.29 | file | that's... complicated... because you still need to read frames from everything, or stuff will get backed up |
| 15:28.40 | gtjoseph | 2. should the caller even have the choice of whether to use the original or stream functions. |
| 15:29.08 | file | yes, because anything which isn't converted to knowing about streams can't see frames from non-default streams |
| 15:29.20 | file | because it will think that they all came from the same stream |
| 15:29.41 | gtjoseph | ok so now a 3rd question... |
| 15:30.13 | gtjoseph | maybe the stream/non-stream logic should be down in the tech then |
| 15:30.26 | file | I don't understand what you mean |
| 15:31.36 | gtjoseph | well, in the case of read, since you can't really read a specific stream, why expose 2 functions, read and read_stream with the exact same prototype? |
| 15:32.00 | file | because 1 function returns frames from default streams only, and the other returns frames from all streams |
| 15:32.21 | file | legacy code will receive frames from default streams only and the existing behavior is maintained |
| 15:32.41 | file | new code that is stream aware can get frames from all streams and do with them what it wishes |
| 15:33.17 | gtjoseph | right but what i'm saying is that rather than adding code to channel.c, to handle that, let the channel tech do it since they have to support streams anyway |
| 15:33.34 | file | no they don't? |
| 15:33.52 | file | we don't have to convert channel drivers to support streams, unless we want to |
| 15:34.02 | gtjoseph | let me re-phrase... any channel driver that is stream capable. |
| 15:34.26 | gtjoseph | yeah, that's where i was going |
| 15:34.28 | file | if we can have common logic that enforces it, why push it down to the channel tech and potentially duplicate things? |
| 15:34.54 | file | we'd also still have to do default / non-default checks for the various audiohooks/framehooks/monitor stuff |
| 15:37.17 | gtjoseph | hmmm. ok so if i call ast_read on a channel with multiple streams aren't I going to cause a backup because not all streams are being read? |
| 15:37.36 | file | nope |
| 15:37.48 | file | frames from non-default streams get turned into an ast_null_frame |
| 15:38.01 | file | the frame still gets read, you just don't see it or get it |
| 15:39.20 | gtjoseph | wonders if there should be a queue for each stream |
| 15:40.10 | file | Mark brought that up too, it may end up that way - but it'll work with a single queue even now |
| 15:40.44 | file | a few things will go into streams |
| 15:40.51 | file | translation paths for sure |
| 15:43.03 | file | the thing with multiple queues is that you'd have to ensure each get serviced adequately |
| 15:44.40 | gtjoseph | true but you might also want to process audio and video separately anyway. |
| 15:51.21 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-rndorqlrwjldjmxq) |
| 15:51.21 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:21.18 | gtjoseph | @file: made 1 clarifying edit to the ast_read description |
| 16:21.24 | file | k |
| 16:30.35 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 17:00.25 | *** join/#asterisk-dev libardi (~libardi@189.61.226.79) |
| 17:17.21 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 18:16.01 | file | huh |
| 18:16.02 | file | gtjoseph: https://jenkins.asterisk.org/jenkins/job/gate-asterisk/4980/ |
| 18:16.33 | gtjoseph | hmmm. |
| 18:17.43 | gtjoseph | that's rather bizarre since it shouldn't even be calling ast_register_file_version |
| 18:17.51 | file | dun dun dunnnnn |
| 18:18.52 | gtjoseph | and how did the other gates pass? |
| 18:19.02 | gtjoseph | maybe that node is messed up |
| 18:19.44 | file | welp |
| 18:19.46 | file | happened to another |
| 18:19.47 | file | https://jenkins.asterisk.org/jenkins/job/gate-asterisk/4975/console |
| 18:20.37 | gtjoseph | different node |
| 18:20.37 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0019e8c02667b4aede.ipv6.abo.wanadoo.fr) |
| 18:20.45 | file | indeed |
| 18:20.53 | gtjoseph | OH. did the libasteriskssl patch go in? :) |
| 18:21.00 | file | entirely possible |
| 18:21.15 | file | yes |
| 18:21.36 | gtjoseph | yeah ok. i think the issue is that now that the libs ar egoing on the correct place, there are orphans in the wrong place. |
| 18:21.51 | gtjoseph | looks |
| 18:22.39 | gtjoseph | yep, that's it |
| 18:25.49 | gtjoseph | all clean |
| 18:26.02 | file | I'm more worried about users |
| 18:26.27 | gtjoseph | yep i'm sending a note to the mailiong lists |
| 18:26.45 | file | that won't be enough, not everyone reads the mailing lists |
| 18:26.57 | file | we either need to correct the problem during install or present a warning if we detect that scenario |
| 18:27.12 | file | or else we'll get JIRA tickets at the next release |
| 18:27.36 | gtjoseph | yep i'll fix it up over the weekend. |
| 18:36.56 | *** join/#asterisk-dev bof22 (~Thunderbi@ARennes-650-1-8-74.w90-32.abo.wanadoo.fr) |
| 19:56.16 | gtjoseph | @file: is it possible for a channel driver to return a frame whose type wasn't in nativeformats? |
| 19:57.17 | file | it shouldn'ttttt occur |
| 19:57.26 | gtjoseph | heh. |
| 19:57.45 | file | that interface is a bit ... undefined ... and legacy though :D |
| 19:58.15 | gtjoseph | as long as we don't attempt to use a default stream for it without checking we're ok |
| 19:58.43 | gtjoseph | since we only create defaults for those in nativeformats |
| 19:59.23 | file | it's a reasonable expectation that a default stream would occur for the same media type |
| 19:59.43 | file | if somehow we got video... without ANY video codec already negotiated... that'd be something |
| 20:01.09 | gtjoseph | ok so the inferred contract (if there can be such a thing) is that a driver will never return a frame that won't have a default stream set. |
| 20:01.28 | file | yes |
| 20:04.25 | file | if someone violates that... we'll cross that bridge then |
| 20:04.31 | file | and promptly burn it so they can't |
| 20:04.36 | gtjoseph | :) |
| 20:04.53 | file | ooh it's Friday |
| 20:06.45 | rmudgett | Is is April yet? |
| 20:07.02 | file | sure |
| 20:07.24 | file | except no, because then my taxes would be due and I'd be annoyed that physical paper hadn't arrived yet |
| 20:08.00 | cresl1n | taxes taxes taxes⦠|
| 20:08.07 | cresl1n | I've gotta finish mine this weekend |
| 20:08.16 | file | I just did my mother's taxes earlier |
| 20:08.33 | file | numbers! NUMBERS! |
| 20:10.15 | gtjoseph | In the spirit of clarity, do you wan to change "a multichannel capable channel should not" to "must not" implement read? |
| 20:10.48 | gtjoseph | or is there a check in __ast_read to prevent calling read on a multichannel driver? |
| 20:10.48 | file | yes |
| 20:10.59 | file | well, read_stream gets preference |
| 20:11.07 | gtjoseph | i'm trying to NOT look too much as the __ast_read code while writing the tests |
| 20:11.48 | file | change it to must not, but the code doesn't handle the scenario if a multichannel implements the read callback only |
| 20:11.58 | gtjoseph | what happens if a driver with MULTICHANNEL fails to implement read_stream? |
| 20:12.05 | gtjoseph | ah |
| 20:12.09 | file | and tries to use it to send back frames from multiple streams |
| 20:12.09 | gtjoseph | kinda not good |
| 20:13.31 | file | you may want to just amend into the read_stream review with the unit tests and fix the things they uncover there |
| 20:13.44 | gtjoseph | yep |
| 20:15.20 | gtjoseph | O M G!!! The binaural synthesis patch merged!!!!!!! |
| 20:15.45 | gtjoseph | Quick...someone +2 the confbridge bits!!! |
| 20:23.45 | cresl1n | runs |
| 20:24.18 | cresl1n | don't know how I missed that |
| 20:24.23 | cresl1n | I've reviewed it a million times |
| 20:24.24 | cresl1n | sorry |
| 20:24.27 | cresl1n | gerrit got too tiny |
| 20:24.57 | cresl1n | Would've done it this morning |
| 20:25.09 | cresl1n | gtjoseph: should be starting the merge dance |
| 20:25.15 | gtjoseph | :) |
| 20:25.31 | gtjoseph | has to go though the gate dance first. |
| 20:25.34 | file | gives cresl1n a potato |
| 20:25.48 | cresl1n | Not cool |
| 20:25.54 | cresl1n | NOT. COOL. |
| 20:26.38 | file | correct |
| 20:26.39 | file | it's a.. |
| 20:26.40 | file | HOT potato |
| 20:26.55 | cresl1n | bwah ha ha ha ha |
| 20:37.11 | gtjoseph | @cresl1n: since you're in a gerrit mood, how about taking a look at the outbound_registration patch? |
| 20:38.13 | cresl1n | Actually, I'm looking at Richard's right now |
| 20:38.17 | cresl1n | but I can add it to my list |
| 20:38.36 | file | gtjoseph: I responded to your response :P |
| 20:38.43 | cresl1n | how meta |
| 20:38.44 | file | doesn't like that a reload will unregister/register |
| 20:39.21 | kharwell | gtjoseph: ya I've taken a look too and I agree with Josh's comment. Prob want to at least check to see if there is a change first before unregistering and re-registering |
| 20:39.48 | gtjoseph | well, that dewfeats the purpose |
| 20:39.57 | kharwell | how so? |
| 20:40.37 | gtjoseph | i suppose I can separate reload from network change event but the point was to take any network topology changes into account |
| 20:40.50 | gtjoseph | that'd require an unregister/register |
| 20:41.14 | gtjoseph | there's no change to the registration per-se. |
| 20:41.39 | file | sure, but in the normal case where things haven't changed then the unregister/register is harmful |
| 20:41.49 | gtjoseph | on a topology change though it'g going ot be coming from a new address |
| 20:41.49 | file | a separate CLI command (we might already have one) is fine |
| 20:41.56 | kharwell | ya it just changed networks, but has to be registered on that one, but a normal reload it prob should check |
| 20:42.20 | gtjoseph | well a normal reload can just do what it already did then |
| 20:42.41 | kharwell | true |
| 20:43.43 | gtjoseph | i'll just separate the 2 then and we'll deal with a command to force refresh at a later date |
| 20:44.04 | gtjoseph | like pubsub, you can't unload outbound_registration then load it again. |
| 20:59.08 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-jgwqtnjeexgwlfmw) |
| 21:15.40 | gedia | Hello. Are you guys aware of any bugs for asterisk 11 ignoring ACKs and other responses? |
| 21:16.10 | gedia | I've been having this issue with a NEC PBX endpoint and it's driving me crazy, can't figure out what the problem is... |
| 21:46.52 | cresl1n | ignoring ACK is a loaded quesiton |
| 21:46.55 | cresl1n | *question |
| 21:47.31 | cresl1n | If it's ACKs that Asterisk actually receives (and you can confirm via asterisk level sip debug) and the ACK matches the transaction/dialog involved, that's concerning |
| 21:47.55 | cresl1n | if you captured it with wireshark somewhere else and asterisk doesn't appear to receive it, that's a different issue |
| 21:48.09 | gedia | nope it's in the logs |
| 21:48.35 | gedia | http://pastebin.com/5VbV4v6P |
| 21:50.33 | cresl1n | Oh |
| 21:50.39 | cresl1n | Asterisk never accepts the INVITE |
| 21:50.50 | gedia | you're looking at a retransmission |
| 21:50.53 | cresl1n | it sends back 401 to it twice, and the NEC never tries to authenticate with digest auth |
| 21:51.00 | gedia | check line 136 |
| 21:51.29 | cresl1n | this looks messed up |
| 21:51.41 | cresl1n | keeps looking |
| 21:51.56 | gedia | call goes through, bidirectional audio for a few seconds, then asterisk kills it after 9 retransmissions of 200 OK each and every one of which is followed by an ACK |
| 21:54.45 | gedia | I mean you're happily tallking on the phone until you get a totally uncalled for "Retransmission timeout reached on transmission" |
| 21:57.47 | gedia | sounds like a SIP ALG issue, only I've verified it to be disabled, plus I don't see any address manipulation in the actual packets exchanged... |
| 21:59.26 | gedia | plus, if some helper were to blame, the ACKs would never reach asterisk, right? |
| 22:01.43 | cresl1n | that's what I would think |
| 22:02.04 | cresl1n | But I'm more of an ISDN/SS7 expert rather than a SIP expert |
| 22:03.47 | cresl1n | Yeah, I don't see why Asterisk doesn't like the ACK from that trace |
| 22:04.04 | cresl1n | CallID, from tag and to tag look right |
| 22:04.38 | cresl1n | I think CSeq is right too |
| 22:05.03 | gedia | that's what I thought... |
| 22:05.13 | cresl1n | are any of the addresses changing unexpectedly? |
| 22:05.14 | gedia | omg, ss7? I don't envy you... |
| 22:05.27 | cresl1n | the sensored ones? |
| 22:05.52 | gedia | no, i've mass-replaced strings in this log for consistency |
| 22:06.16 | gedia | AA.AA.AA.AA is asterisk's public IP and NN.NN.NN.NN is NEC's signalling IP |
| 22:06.38 | gedia | there are two private IPs in there for NEC's signalling and DSP accordingly, pre-NAT |
| 22:06.49 | gedia | which I obviously haven't censored... |
| 22:07.54 | gedia | Am I right in thinking that this can't be a network issue? I mean if it arrives in asterisk's core, then it's SIP stack related? |
| 22:08.12 | file | hold. |
| 22:09.29 | cresl1n | what am I missing file |
| 22:09.40 | cresl1n | <â needed a good exercise to increase his SIP foo |
| 22:09.56 | cresl1n | gedia - not sure yet |
| 22:10.03 | cresl1n | if it hits asterisk, that's a good start |
| 22:10.09 | gedia | <--- is glad someone @asterisk-dev considers this a good SIP excercise |
| 22:10.59 | file | dunno! it seems fine |
| 22:11.54 | gedia | Great... |
| 22:12.15 | file | unless the retransmissions are somehow screwing up chan_sip |
| 22:12.19 | gedia | you're seeing the retransmissions too right? I mean I shouldn't switch to antipsychotics? |
| 22:12.34 | gedia | and also the ACKs...? |
| 22:12.49 | cresl1n | file: that's what I was starting to wonder |
| 22:18.10 | gedia | right, I'm gonna go guys, it's already past midnight in my timezone... thanks for checking this out! |
| 22:18.14 | cresl1n | good luck |
| 22:18.19 | gedia | thanks :-) |
| 22:18.21 | cresl1n | sorry about not having a better answer |
| 22:18.27 | cresl1n | maybe try chan_pjsip instead? |
| 22:18.28 | cresl1n | :-) |
| 22:18.37 | cresl1n | It'll probably work better |
| 22:18.51 | gedia | I'd love to but there are 1500 other users using that machine right now, so it's not a very good idea :-) |
| 22:19.11 | gedia | at some point we'll take the jump though, that's for sure... |
| 22:19.25 | gedia | gnite@channel |
| 22:19.34 | cresl1n | well, chan_sip isn't really supported anymore, so you might be on your own with bugs |
| 22:19.36 | cresl1n | best of luck |
| 22:58.50 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:58.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:09.34 | *** join/#asterisk-dev dan_j (sid21651@gateway/web/irccloud.com/x-lhuwiahfldgdkfqe) |