| 01:22.01 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:36.42 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:22.02 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@71-80-124-168.dhcp.wlmn.ct.charter.com) |
| 02:29.34 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-iskbxfingmrzfmue) |
| 05:25.50 | *** join/#asterisk-dev KristianMedK (5ee76001@gateway/web/freenode/ip.94.231.96.1) |
| 05:25.59 | KristianMedK | jsmith about the asterisk302, i realise it's old, but the issue mentioned about the leastrecent is still there. I realise there would've been a lot of changes to queues and agents but they don't seem to have been about that particular issue. unless i've missed them somewhere |
| 06:18.49 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f42b:76c7:792b:f76) |
| 06:47.12 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:11.26 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:11.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:14.52 | KristianMedK | Is it possible to write a module that overrides functions from an existing module? |
| 07:15.57 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 07:34.14 | oej | No, what's the problem you are trying to solve? |
| 07:47.14 | KristianMedK | i'm looking to add my own queue strategy, and is looking for the best /easy to maintain way to do it |
| 07:48.01 | KristianMedK | It seems i have to do it by editing the app_queue.c directly, and then readd my change when i update asterisk, but if i could isolate my changes i'd prefere that |
| 07:57.10 | oej | Adding a new strategy doesn't mean overriding existing functions, right? |
| 07:57.27 | oej | If you want to you can rename app_queue app_kristianqueue.c |
| 07:57.40 | oej | and register all functions as "kristianqueue" etc |
| 07:57.46 | oej | That way you have a totally separate module |
| 08:01.30 | KristianMedK | but i'm going to need all the existing functionality from app_queue regarding calling agents, calculating metric and more ? |
| 08:56.40 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:56.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:02.33 | *** join/#asterisk-dev danjenkins (~dan@199.72.68.202) |
| 10:02.24 | *** join/#asterisk-dev ayrjola (~ayrjola@89.18.237.137) |
| 11:50.55 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:50.55 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:55.32 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:55.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:48.13 | oej | Question: Patches added to reviewboard - are they automatically disclaimed? |
| 12:50.19 | oej | There's one patch for SIPconnect 1.1 where the user on reviewboard has a licens on file if I understand correctly, but the patch was uploaded directly to reviewboard and not Jira |
| 13:03.11 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 13:11.56 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:11.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:16.23 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-iisdhzkoeyqomczn) |
| 13:33.23 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-yurjyapwkihhlecs) |
| 13:33.23 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:38.39 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:49.31 | oej | Hi Otherwiseguy!!! |
| 14:06.52 | *** join/#asterisk-dev danjenkins (~dan@nat/digium/x-bluisacqfuhcmnuv) |
| 14:15.30 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-bvltirvqqhqncgjn) |
| 14:17.52 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 14:19.15 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-totjyxpletmscajl) |
| 14:35.57 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-uhzqotfbzszhqcnx) |
| 14:35.57 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:43.04 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-rhpeptjzmgsqocyt) |
| 14:48.48 | opticron | so...rewriting contacts for TCP transports with pjsip |
| 14:49.27 | file | is a thing |
| 14:49.37 | opticron | I'm looking at another bug where the contact gets rewritten with the correct information, but that information becomes invalid when the connection is torn down/times out |
| 14:49.58 | opticron | and when that happens, pjsip needs to initiate a new TCP connection |
| 14:50.43 | opticron | all it has is the old connection's remote port which is not valid for receiving connections |
| 14:51.09 | oej | WHich is why SIP Outbound was standardised |
| 14:51.30 | opticron | goes to read up a bit |
| 14:51.43 | file | yeah, if you are reusing their connection and it goes away - all bets are off either way |
| 14:52.09 | opticron | in this case, it's torn down after about 30s |
| 14:52.13 | oej | Only if they are behind nat... |
| 14:52.23 | file | oej, even if not behind NAT some will outright lie |
| 14:53.11 | oej | That's a bug |
| 14:54.01 | file | opticron, who is tearing it down? |
| 14:54.23 | file | and what is the environment? |
| 14:54.48 | opticron | not sure yet, is there a good way to determine that from the logs? asterisk to asterisk, both pjsip, 13 branch on very recent code |
| 14:55.23 | file | I don't know off the top of my head but a packet capture would be useful |
| 14:56.12 | oej | We are working on this stuff in kamailio so we can manage the TCP connections in a better way. |
| 14:57.05 | mjordan | oej: what issues are you facing in Kamailio? |
| 15:01.09 | opticron | file, the side that initiated the call is tearing it down |
| 15:03.16 | file | https://trac.pjsip.org/repos/ticket/1465 |
| 15:06.32 | file | if rewrite_contact is not set, does it work? |
| 15:07.33 | oej | mjordan: We need to unregister when a TCP connection from behind a NAT closes. We can't possibly open a connection back. |
| 15:07.42 | oej | And we do have SIP Outbound server support |
| 15:11.40 | oej | So a bit more connection control. Equally we need to be able to control TLS connections better. |
| 15:40.33 | file | opticron, what happens if you don't set rewrite_contact? |
| 15:48.36 | opticron | without contact rewriting, the BYE goes over UDP |
| 15:52.25 | file | right right |
| 16:08.26 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:08.26 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:30.08 | mjordan | file: so, in bridging world, we no longer get lied to during smart bridging, which means that the native RTP bridge should always be presented with the correct two channels, right? |
| 16:30.17 | file | yes |
| 16:30.50 | mjordan | k. My patch on r3997 should be much smaller |
| 16:30.59 | mjordan | unless I keep the renaming |
| 16:31.02 | oej | file: I do like your optimistic oppurtunistic srtp patch! |
| 16:31.08 | oej | It's going in the right direction! |
| 16:32.04 | file | it's a thing! |
| 16:32.08 | mjordan | oej: lingon is the branch with the lifetime/MKI support, right? |
| 16:32.30 | oej | Well, not MKI, but negotiating away MKI |
| 16:32.52 | oej | I think it's doing the right thing, and it's been certified... |
| 16:33.06 | mjordan | part of the Lync work? |
| 16:33.14 | mjordan | right, and IIRC, the lifetime is just verified that isn't so small that we would ever care about it |
| 16:33.21 | oej | Just to be sure I have a indication of having a clue, I added a lot of examples to the source code. Yes, lync |
| 16:33.26 | mjordan | k |
| 16:33.44 | oej | I consider it a bug fix. |
| 16:33.59 | mjordan | if you don't mind, I might take a look at that, as that was another thing that would make interoperability easier |
| 16:34.04 | mjordan | oej: I agree :-D |
| 16:34.20 | oej | I do not mind. I mind you eating good stuff without sending a copy to file though. |
| 16:34.26 | mjordan | heh |
| 16:34.39 | mjordan | I'd fax him some carrots, but T.38 is a bit of a mess |
| 16:34.40 | oej | I got the recipe! |
| 16:34.59 | oej | Yes, there's a high risk of carrot loss and some bad latency so they arrive in dry bits |
| 16:35.03 | mjordan | they're quite good! Trick is to let the ginger ale reduce |
| 16:35.14 | mjordan | oej: carrier pigeon, but they might eat it en route |
| 16:35.33 | file | is huddled up trying to get warm |
| 16:36.03 | mjordan | goes to eat lunch |
| 16:36.08 | file | it's the season for wearing gloves inside |
| 16:36.29 | oej | Inside what? Your mind? |
| 16:36.41 | oej | Time for dinner, not lunch. |
| 16:37.15 | file | inside... REALITY |
| 16:37.28 | oej | Oh that. |
| 16:37.34 | file | I had a dream that the universe was disappearing last night. It was strange. In the end we figured out how to save it using USB flash drives. |
| 16:38.18 | oej | Oh no, someone removed a USB flash drive in an unsafe way. The horror of it all. |
| 17:13.05 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 17:38.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 17:38.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 17:47.15 | mjordan | rmudgett: I'm looking at review 4066 |
| 17:47.47 | mjordan | rmudgett: when would you have a dial masquerade datastore being set up on a channel (say, Alice), but also have a datastore set up on the peer (say, Bob)? |
| 17:49.35 | rmudgett | mjordan: The datastore is set on alice and bob for the dial |
| 17:51.01 | rmudgett | if alice is the caller then the common datastore data indicates that alice is the caller. The common data also has a list of peers (bobs) that are called. |
| 17:52.32 | rmudgett | The datastore on alice points to the common datastore data ao2 object. The datastore on bob points to the common datastore data ao2 object also. |
| 17:55.27 | mjordan | hm. |
| 17:55.52 | mjordan | I think I'm trying to understand the "Something is wrong" portion of the code in set_dial_masquerade |
| 17:56.10 | mjordan | how does a peer already get the dial masquerade information? |
| 17:59.46 | rmudgett | mjordan: That part is trying to fix a left over dial datastore that wasn't properly removed from a previous dial. |
| 18:01.58 | rmudgett | The set_dial_masquerade is adding the dial datastores to alice and bob. If there are multiple bobs then alice already has the datastore and the new bob is added to the list. |
| 18:02.01 | mjordan | when would that occur normally? Or is this merely defensive? |
| 18:02.53 | rmudgett | However, if the new bob has a left over dial datastore then the code is trying to clean up from the previous dial. The cleanup attempt is defensive code. |
| 18:03.01 | mjordan | k. |
| 18:03.48 | mjordan | it's confusing, but I don't think I have any suggestion on how to make it better either |
| 18:03.56 | mjordan | masquerades == confusing |
| 18:05.51 | rmudgett | The dial datastores are manipulated at a layer below where code can guarantee the datastores are going to be handled correctly. Otherwise, the code would need to be done in about three places. |
| 18:06.31 | rmudgett | app_dial, dial.c, and another place in channel.c |
| 18:06.41 | rmudgett | also app_queue |
| 18:32.49 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 18:32.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:58.12 | mjordan | rmudgett: yup. It's definitely the right place to handle it |
| 19:01.59 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 19:40.58 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 20:27.37 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 20:45.49 | rmudgett | gtjoseph: ping |
| 20:52.15 | rmudgett | You need to use an accessor function for ast_phoneprov_std_variable_lookup[]. Loadable modules don't deal with linking to global data very well. You get a load error from res_pjsip_phoneprov_provider about that symbol. |
| 21:09.27 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:43.24 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 21:55.50 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-yurjyapwkihhlecs) |
| 22:09.13 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 22:09.13 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 22:15.16 | gtjoseph | rmudgett: pong... What's up? |
| 22:24.34 | rmudgett | gtjoseph: You need to use an accessor function for ast_phoneprov_std_variable_lookup[]. Loadable modules don't deal with linking to global data very well. You get a load error from res_pjsip_phoneprov_provider about that symbol. |
| 22:24.56 | gtjoseph | yeah I just saw your note above but it only happens if res_phoneprov doesn't load. |
| 22:25.11 | gtjoseph | unless you;'re seeing something diferent |
| 22:27.17 | rmudgett | Are you specifying which modules to load in modules.conf or just letting autoload take care of loading modules? |
| 22:27.24 | gtjoseph | autoload |
| 22:28.00 | gtjoseph | and if res_phoneprov doesn't load, the accessor function is going to fail as well. |
| 22:28.20 | rmudgett | I'm using autoload and seeing that message. The message shows up because it tried to load res_pjsip_phoneprov_provider before res_phoneprov |
| 22:28.39 | gtjoseph | non-determinstic load order |
| 22:28.41 | gtjoseph | :) |
| 22:28.55 | gtjoseph | i think res_phoneprov has global symbols set though |
| 22:28.58 | rmudgett | True but the warning doesn't happen if it is a function and not a data link. |
| 22:29.00 | gtjoseph | checking |
| 22:29.08 | gtjoseph | really?? |
| 22:29.59 | rmudgett | It doesn't find the function symbol and quits earlier than if it were only a data link. |
| 22:31.09 | rmudgett | It's a weirdness with the system loader function. |
| 22:32.13 | gtjoseph | hmmm. Ok, I can create the accessor easily enough. I just never saw the problem. |
| 22:32.25 | rmudgett | We have seen something like this when a function is only referenced by a module as a pointer to be passed as a function parameter. |
| 22:32.38 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:32.41 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:33.16 | rmudgett | The solution in that case was to create a local function that called the intended function. |
| 22:33.33 | rmudgett | foo(extern_func) |
| 22:33.56 | rmudgett | local_func(){extern_func();} |
| 22:34.03 | rmudgett | foo(local_func) |
| 22:34.33 | gtjoseph | Yeah, I think i ran across something like that in thepjsip guts. |
| 22:35.18 | rmudgett | Another thing I saw was that res_phoneprov AST_MODULE_INFO should be more like res_hep.c's. |
| 22:35.39 | rmudgett | It should specify the load_pri value. |
| 22:36.23 | gtjoseph | GLOBAL_SYMBOLS completely ignores priority though. |
| 22:36.49 | rmudgett | AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_GLOBAL_SYMBOLS | AST_MODFLAG_LOAD_ORDER, "HEPv3 API", |
| 22:37.27 | gtjoseph | Yeah, I see it but I thought the loader ignored the priority if GLOBAL_SYMBOLS was specified. |
| 22:38.08 | rmudgett | AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_DEFAULT | AST_MODFLAG_GLOBAL_SYMBOLS, "HTTP Phone Provisioning", |
| 22:38.08 | rmudgett | The AST_MODFLAG_DEFAULT doesn't add anything either. |
| 22:38.39 | gtjoseph | That part pre-dates me. :) |
| 22:46.27 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-totjyxpletmscajl) |
| 22:51.23 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |