| 00:05.34 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ttvkeumvnxtsegfk) |
| 00:13.29 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 00:37.31 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 00:56.48 | *** join/#asterisk-dev timclassic (~tim@cpe-74-72-108-134.nyc.res.rr.com) |
| 00:57.45 | timclassic | Do I need to do anything special to get an anonymous SIP call's incoming caller ID to show properly on the called endpoint? All I see is user@IP currently. Again, this is with pjsip. |
| 00:58.34 | timclassic | Perhaps it's just my client, but I'm not even sure which directives matter currently. |
| 00:59.48 | WIMPy | That's a question for #asterisk |
| 01:05.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.6) |
| 01:06.51 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 01:06.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:25.46 | timclassic | WIMPy: Even for pjsip-based configuration? |
| 01:30.52 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:36.37 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 02:52.45 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 03:06.57 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.217) |
| 03:10.25 | snuff-work | timclassic: you need to ensure your trusting the callerid.. otherwise it probably will display something like that |
| 03:16.57 | timclassic | snuff-work: Thanks. I'll have to figure out the options for setting that. |
| 03:17.14 | timclassic | wonders what pjsip's equivalent of ${SIPDOMAIN} is... |
| 03:50.18 | timclassic | Argh, I need to get my hands on the SIP domain of a dialed extension in the dialplan when using pjsip. Anyone here have any knowledge? Source code and web reading have revealed little so far. |
| 03:53.46 | timclassic | Perhaps this is not implemented yet. |
| 03:54.14 | file | it's not exposed to the dialplan, no, but the functionality required to implement it exists |
| 03:54.21 | file | I'm going to bed but... you could write a SIP session supplement that is executed before the PBX starts... it could extract the domain and place it into a dialplan variable |
| 03:56.49 | timclassic | Hmm okay |
| 03:57.01 | timclassic | My goal is to allow dialing of arbitrary SIP addresses from a registered endpoint |
| 03:57.09 | timclassic | And I think this is the last piece of the puzzle |
| 03:57.51 | timclassic | file: Thanks for your help today. |
| 03:59.52 | coreyf1513 | does anyone have any tips on troubleshooting leaked ast_frame's? |
| 04:07.04 | igcewieling | timclassic: I assume this would not work? exten => _[0-9a-zA-Z].,1, Dial(SIP/${EXTEN}) |
| 04:07.27 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.60) |
| 04:07.51 | igcewieling | you might want to run ${EXTEN} through FILTER() though |
| 04:16.47 | timclassic | igcewieling: Correct, there is no @domain in ${EXTEN} |
| 04:16.53 | timclassic | That's the first thing I tried. |
| 04:17.55 | timclassic | igcewieling: I used the example in "Dialing SIP URIs from Asterisk" from http://ofps.oreilly.com/titles/9781449332426/asterisk-ICR.html |
| 04:20.54 | igcewieling | timclassic: You can add an @ to the pattern, I meant to do that |
| 04:23.36 | timclassic | So _[0-9a-zA-Z].@. ? |
| 04:23.46 | timclassic | Or inside the braces? |
| 04:24.02 | igcewieling | <PROTECTED> |
| 04:24.04 | timclassic | I just don't think that the full SIP address is even avialable for matching |
| 04:24.15 | igcewieling | actually also |
| 04:24.21 | igcewieling | <PROTECTED> |
| 04:27.06 | timclassic | Doesn't eventying in the square brackets just represent the first character, and the `.' applies to the rest of the string? |
| 04:29.35 | timclassic | igcewieling: Yeah, no such luck. Take 500@example.com, for example. I believe that, by the time it hits the dialplan, only the "500" is available for matching. |
| 04:29.44 | timclassic | I hope I'm wrong, however. |
| 04:30.01 | timclassic | Though I can make it work if I have access to the SIP domain via a variable. |
| 04:31.30 | timclassic | Though I'm curious--why doesn't Asterisk use the full user@domain.com when matching against the dialplan? |
| 04:34.30 | timclassic | Oh well, I'm off to bed. Thanks for the help all. |
| 05:29.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.225) |
| 06:23.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.240) |
| 07:07.01 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:79c8:9f0c:6ed2:f687) |
| 07:07.56 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:18.14 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:18.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:18.12 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 08:18.25 | skirmisha | guys |
| 08:18.49 | skirmisha | i have an issue with sip registrations, probably code must be changed, but would like to hear your opinion |
| 08:19.26 | skirmisha | the issue is when we have multiply registration coming from same ip and same port, but with diff usernames. Asterisk match wrong extension i presume it checks ip and port first |
| 08:23.49 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 08:32.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@79.104.4.67) |
| 08:53.45 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 08:55.07 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 08:55.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:56.27 | oej | Hello folks! |
| 09:33.09 | *** join/#asterisk-dev wedhorn (~wedhorn@27-33-41-99.static.tpgi.com.au) |
| 10:05.55 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:05.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:48.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@217.118.84.185) |
| 11:30.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.70) |
| 11:34.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.70) |
| 11:46.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.106) |
| 12:01.49 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-txtqpraiwbnudwfr) |
| 12:01.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:11.58 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.57) |
| 12:21.06 | oej | Afternoon sirs |
| 12:40.35 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:40.43 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:55.59 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-uyhdejssceavhsip) |
| 12:56.19 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:01.40 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 13:22.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@83.220.238.123) |
| 13:33.53 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:46.02 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:46.03 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:48.58 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-shisalxxiotraeje) |
| 13:48.58 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:08.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:08.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:18.24 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-wzogymtsislocele) |
| 14:39.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@nat.canmos.ru) |
| 15:36.22 | *** join/#asterisk-dev italorossi (~italoross@177.207.45.97.dynamic.adsl.gvt.net.br) |
| 16:33.57 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-wzsarkhtufhbdahw) |
| 17:01.10 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 17:16.04 | Kobaz | what would be the docs xpath for a xpointer to a function |
| 17:17.39 | opticron | looks |
| 17:17.53 | Kobaz | would it be /docs/function ? |
| 17:18.00 | Kobaz | not sure what the overall structure looks like |
| 17:18.39 | opticron | /docs/function[@name='whatever'], I think |
| 17:18.52 | Kobaz | cool |
| 17:18.59 | Kobaz | <xi:include xpointer="xpointer(/docs/function[@name='GROUP']/syntax/parameter[@name='group'])" /> |
| 17:19.04 | opticron | assume its a query from the base of core-en_US.xml |
| 17:19.18 | Kobaz | k, makes sense |
| 17:19.32 | opticron | that looks like a sane xpath specifier |
| 17:24.50 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 17:30.40 | Kobaz | mm trying to come up with some wording for GROUP() behavior if there's no category specified |
| 17:31.08 | Kobaz | if there's no category, if you do GROUP()=a or GROUP()=a@ the category is '' |
| 17:31.18 | Kobaz | those are both acceptable |
| 17:32.27 | Kobaz | and GROUP()=@ and GROUP()= are also acceptable |
| 17:33.45 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-qqfbgfsmqzkdbejj) |
| 17:33.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:45.32 | *** join/#asterisk-dev timclassic (~user@34-227-13-72.static.cosmoweb.net) |
| 17:58.35 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:15.22 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 18:15.22 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 18:23.02 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 18:49.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.22) |
| 18:50.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.22) |
| 19:07.31 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:23.59 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.22) |
| 19:46.49 | Kobaz | what's the max string length return from a function |
| 19:49.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.22) |
| 19:50.07 | Kobaz | hmm looks like 4096 |
| 19:56.16 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:56.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:27.03 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 20:39.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.22) |
| 20:42.24 | Kobaz | okay so |
| 20:42.30 | Kobaz | data question |
| 20:42.45 | Kobaz | i have some search/list functions for func_groupcount |
| 20:43.22 | Kobaz | max function return string is 4096 characters... which you can very easily overrun that if you have a really big amount of traffic (or just use lots of groups) |
| 20:44.04 | Kobaz | so i have like GROUP_CHANNEL_LIST_START(regex) and then GROUP_CHANNEL_LIST_NEXT() |
| 20:44.16 | Kobaz | to get around the buffer limits |
| 20:44.57 | Kobaz | but, i'm thinking it's probably just better to return a comma delimited list and make the return string for function calls into something dynamicly sized |
| 20:45.29 | Kobaz | so... for version 12, obviously you cant go and change all that.. but you could leave it as return comma delimited list, and then in version 13 fix the buffer limit |
| 20:45.37 | Kobaz | or is it better to leave it as START/NEXT |
| 20:48.18 | Kobaz | and then in the future put in GROUP_CHANNEL_LIST() which will then return the full list |
| 20:56.36 | Corydon76-work | Kobaz: what max are you talking about? |
| 20:57.21 | Kobaz | calling functions |
| 20:57.24 | Kobaz | the return buffer |
| 20:57.32 | Kobaz | lemme find it again |
| 20:57.35 | Corydon76-work | Which ones, specifically? |
| 20:57.40 | Kobaz | custom functions |
| 20:58.00 | Kobaz | <PROTECTED> |
| 20:58.07 | Kobaz | VAR_BUF_SIZE is 4096 |
| 20:58.16 | Corydon76-work | There's an alternate API for dialplan functions which using ast_str... |
| 20:58.34 | Corydon76-work | The API you're looking at is still supported, but it's not used in the core |
| 20:58.34 | Kobaz | that arg is passed as 'len' to the custom func |
| 20:58.39 | Kobaz | oh |
| 20:58.53 | Kobaz | is there anything special i need to use? |
| 20:59.01 | Kobaz | to not be affected by the 4096 limit |
| 20:59.02 | mjordan | ast_str |
| 20:59.16 | Corydon76-work | See ast_func_read2() |
| 20:59.35 | Kobaz | yeah, i saw func_read2 |
| 20:59.40 | Kobaz | not sure how exactly it's used |
| 20:59.41 | Corydon76-work | Pass maxlen as 0, if you don't want any limit |
| 20:59.55 | Corydon76-work | It's used exactly the same way |
| 21:00.12 | Kobaz | but.. |
| 21:00.26 | Corydon76-work | Some dialplan functions still use the old method of constrained buffers, but the API prefers using the unconstrained versions, when supported |
| 21:00.28 | Kobaz | from pbx_substitute_variables_helper_full it passes VAR_BUF_SIZE to read2 also |
| 21:01.00 | Corydon76-work | See ast_str_substitute_variables_full() |
| 21:01.17 | Corydon76-work | You'll find that that's the function that is called from the dialplan logic |
| 21:01.32 | Kobaz | yeah oh okay |
| 21:01.35 | Kobaz | passed with a len of 0 |
| 21:01.39 | Corydon76-work | As I said, the old API is still supported, because there's a lot of external code that uses it |
| 21:01.46 | Kobaz | yeah |
| 21:01.47 | Kobaz | k |
| 21:01.49 | Corydon76-work | But there's a new API that is better |
| 21:01.54 | Kobaz | okay so... |
| 21:02.03 | Kobaz | back to higher level |
| 21:02.19 | Kobaz | ast_custom_function_register |
| 21:02.27 | Kobaz | will that by default use the read2 ? |
| 21:02.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:02.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:02.46 | Corydon76-work | The registration of the functions allows BOTH functions to be registered |
| 21:02.55 | Kobaz | k |
| 21:03.31 | Kobaz | <PROTECTED> |
| 21:03.33 | Kobaz | bingo |
| 21:03.42 | Kobaz | from struct ast_custom_function { |
| 21:03.46 | Kobaz | that's what i was looking for |
| 21:03.50 | Kobaz | how to get it to use read2 |
| 21:04.03 | Corydon76-work | The code that is actually called will depend upon which API function is called, because we have to consider which is more convenient for that particular method |
| 21:04.16 | Kobaz | if i only register read2... |
| 21:04.48 | Corydon76-work | If you only register read2, then it will get called from either place, but obviously, it will be truncated if you call the function with fixed buffers |
| 21:04.57 | Kobaz | okay |
| 21:05.07 | Kobaz | but from dialplan it'll use read2 |
| 21:05.12 | Corydon76-work | Correct |
| 21:05.20 | Kobaz | and elsewhere if someone is calling _read( then it'll use the truncate |
| 21:05.22 | Kobaz | k, cool |
| 21:05.40 | Kobaz | awesome |
| 21:05.44 | Kobaz | just saved me bunches of work |
| 21:06.07 | Corydon76-work | If you notice, there's also a maximum length passed in the structure, when it was not easy to convert the function to use arbitrary length buffers |
| 21:06.29 | Corydon76-work | That makes it easy for the ast_str buffer to be appropriately sized so as not to truncate the output |
| 21:06.31 | Kobaz | ah i see |
| 21:06.43 | Kobaz | so i can make it rather large to be safe |
| 21:07.15 | Corydon76-work | Well, and for things where the only output is an integer, ast_str doesn't have to create a huge buffer in order to get that result |
| 21:07.20 | Kobaz | with the current limit of 4096, and say an average channel name length of 20, you can fit 200ish channels comma delimited |
| 21:08.01 | Kobaz | but if you doubled that, or mabe it 10k, then it would be big enough for most use cases assuming someone has old code using _read() |
| 21:08.35 | Corydon76-work | You also have to consider that when you increase those buffers, which are held in stack space, you decrease the depth of the possible call stack |
| 21:08.42 | Kobaz | true |
| 21:08.51 | Kobaz | people should just use read2 anyway |
| 21:08.59 | coreyf1513 | i think pbx_substitute_variables is used by dialplan execution, which is limited to 4096 even with read2 |
| 21:09.01 | Corydon76-work | That was much more important when people still used Macro |
| 21:09.27 | Corydon76-work | coreyf1513: It was substituted out in 1.6.2, I think |
| 21:09.50 | Kobaz | because silent truncatation of a channel list would be bad |
| 21:12.54 | Corydon76-work | coreyf1513: crud, you're right. We probably should fix that |
| 21:13.34 | coreyf1513 | Corydon76-work: ok yeah I was looking at it again but I thought pbx_extension_helper would be the normal way it would run |
| 21:14.25 | Kobaz | so who wants to put in the issue |
| 21:15.34 | Corydon76-work | I thought I fixed that, but perhaps it got reverted. I need to annotate in order to see if it was reverted for some reason |
| 21:18.04 | Corydon76-work | Kobaz: what version do you need this change in? |
| 21:18.09 | Kobaz | 12 |
| 21:18.55 | Corydon76-work | Oh, that's a pretty simple change, then |
| 21:18.58 | Kobaz | returning a comma delimited list of channel names and/or group names from regex searches |
| 21:19.10 | Kobaz | and it will definitely get truncated on people |
| 21:19.17 | Kobaz | hosted systems with 400 channels, etc |
| 21:22.19 | Corydon76-work | mjordan: what do you think about this change in 12? It's not really a bug, just a limitation. |
| 21:22.36 | mjordan | I'm fine with it if it gets done before Thursday |
| 21:22.37 | mjordan | :-) |
| 21:22.41 | Kobaz | cool |
| 21:23.04 | Corydon76-work | Does it need to go into 1.8? |
| 21:23.23 | Kobaz | is it documented anywhere that there's a 4096 limitation for 1.8 ? |
| 21:23.51 | Corydon76-work | I have no idea |
| 21:24.07 | Kobaz | i would say it's a bug fix for 1.8 unless there's specifically stated limits. If someone is getting a big return value, and it's using a read2() there's no reason it should be truncated |
| 21:24.13 | Corydon76-work | I'm pretty sure we talk about it in the starfish book |
| 21:24.50 | Corydon76-work | Official documentation can be more murky |
| 21:25.11 | Corydon76-work | But it's honestly a call that only the release manager can make |
| 21:27.09 | Corydon76-work | The Asterisk admin guide version 1.8 does not specify such a limit |
| 21:29.03 | mjordan | I'd prefer not to make the change for 1.8 unless there's an actual need for it. |
| 21:29.31 | mjordan | i.e., here's my real world use case that I can't work around using the functions that exist in 1.8 |
| 21:30.03 | Corydon76-work | You could easily say that AEL is intended to support arbitrary length variables, and it does not. |
| 21:30.41 | Corydon76-work | Not the most helpful case, but AEL does sometimes do strange things to make the language work more naturally |
| 21:30.55 | Kobaz | mjordan: calling ${CHANNELS(.*)} with > 200 channels |
| 21:30.57 | Kobaz | although |
| 21:31.00 | Kobaz | it's using read() |
| 21:31.05 | Kobaz | so it would get truncated anyway |
| 21:31.17 | mjordan | Kobaz: that's not a use case. |
| 21:31.37 | Kobaz | it's not? |
| 21:31.42 | mjordan | no. |
| 21:31.53 | Kobaz | that's a real-world use-case... i can see that happening |
| 21:32.07 | mjordan | If I squint hard, okay |
| 21:32.17 | mjordan | at the same time, I'd say that iterating over 200+ channels while executing on a PBX thread is dumb |
| 21:32.21 | Corydon76-work | He means an actual case where you've tried to do something reasonable and the limit made you have to do it in a really unnatural way |
| 21:32.22 | Kobaz | true |
| 21:32.26 | mjordan | if you're trying to do that much channel management, do it through AMI |
| 21:32.33 | mjordan | Corydon76-work: exactly |
| 21:32.36 | Kobaz | but still, it shouldn't break |
| 21:32.42 | mjordan | it doesn't "break". It has a limitation. |
| 21:32.49 | mjordan | Improving it is good. Hence, 12. |
| 21:32.56 | Kobaz | an undefined limitation |
| 21:32.56 | Kobaz | yeah |
| 21:33.09 | Kobaz | i would actually be interested myself in going through and converting everything to read2 |
| 21:33.09 | mjordan | no, it's defined. It's defined as 4096. If you want to update documentation, that's great |
| 21:33.09 | Corydon76-work | mjordan: actually, it does break, because the configuration loader doesn't have that limitation |
| 21:33.32 | Kobaz | well okay, s/undefined/undocumented publicly/ |
| 21:33.40 | Corydon76-work | Supposing you had a really long set of channels defined in a Dial, it could truncate in the middle of a channel specification |
| 21:33.43 | mjordan | I have a hard time making this change without a bug report in JIRA for it |
| 21:33.58 | Kobaz | i'll put one in |
| 21:34.04 | mjordan | If this was a problem that justified making this change, then someone would have reported it by now. And have a good example as to why it was necessary |
| 21:34.21 | mjordan | I'm against this change unless you guys can find a real world dialplan that needs it. |
| 21:34.40 | Kobaz | yeah, i agree it's apparently not a catastrophic failure type issue |
| 21:34.43 | mjordan | screwing around with pbx.c has unintended consequences, and I don't want to pick up the pieces in a release branch. |
| 21:34.46 | Kobaz | but would be really ncie to address |
| 21:35.11 | mjordan | If you want to write some unit tests or test suite tests to along with such a change in 1.8, that'd be great |
| 21:35.21 | mjordan | that would at least allow us to vet the change more completely. |
| 21:35.28 | Kobaz | yeah it would |
| 21:35.29 | Corydon76-work | mjordan: https://issues.asterisk.org/jira/browse/ASTERISK-18396 |
| 21:35.50 | mjordan | Corydon76-work: fair enough. |
| 21:35.53 | mjordan | (pbx_realtime) |
| 21:36.18 | mjordan | {quote} |
| 21:36.18 | mjordan | If the same code is used in the extensions.conf this issue does not occur. |
| 21:36.18 | mjordan | {quote} |
| 21:36.29 | mjordan | Is this the same problem? |
| 21:36.33 | Corydon76-work | Oh, you're right. Let me find another one |
| 21:38.18 | Corydon76-work | Kobaz: go ahead and create an issue. Make it good. |
| 21:38.22 | Kobaz | k k |
| 21:38.40 | Kobaz | speaking of lengths |
| 21:38.50 | Kobaz | so if my read2 callback is passed a len > 0 |
| 21:39.08 | Corydon76-work | mjordan: the funny thing about ASTERISK-18396 is that it's languished in the tracker for 2 years with a patch |
| 21:39.12 | Kobaz | would it be acceptable to treat it as a failure if len < what's needed for the output ? |
| 21:39.31 | mjordan | Corydon76-work: if only the person who attached the patch had commit access... :-D |
| 21:39.44 | Corydon76-work | mjordan: Uh, well, I do |
| 21:40.11 | mjordan | works on transmitting sarcasm through IRC |
| 21:40.13 | mjordan | :-) |
| 21:40.23 | Kobaz | otherwise the caller wont know the output is truncated |
| 21:40.36 | file | stares at the wall |
| 21:41.01 | mjordan | things regarding pbx_realtime are generally not addressed by folks around here |
| 21:41.14 | Kobaz | glares at pbx_realtime |
| 21:44.40 | Corydon76-work | On a completely different topic, anybody know of a use of the '+=' config magic in a location other than func_odbc.conf? |
| 21:45.04 | Corydon76-work | as in, has somebody used it in a practical way? |
| 21:46.03 | coreyf1513 | svn blame main/pbx.c says the limit of 4096 was set in sept 2005. I'm a fan of calling this a limitation of 1.8/11 and not updating. |
| 21:46.14 | Kobaz | oh wow |
| 21:46.29 | Kobaz | that has been a while... with no massive outcry |
| 21:47.37 | file | perspective, it's a good thing to have |
| 21:47.52 | Kobaz | i +1 for fixing it in 12 though |
| 21:48.01 | Corydon76-work | coreyf1513: which constant are you looking at? |
| 21:49.22 | coreyf1513 | Corydon76-work: 6663 kpfleming #define VAR_BUF_SIZE 4096 |
| 21:49.38 | mjordan | heh |
| 21:50.02 | Corydon76-work | coreyf1513: the previous code had hardcoded 4096. That patch was simply moving the value into a define |
| 21:51.42 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 21:54.03 | Corydon76-work | Previous patch to that line had increased the limits from 256 to 4096. |
| 21:54.19 | Kobaz | i remember hitting the 256 limit often |
| 21:54.59 | Corydon76-work | I don't remember hitting it often, but I certainly do remember hitting it. I may even have been the impetus for Mark to change that limit to 4096. |
| 21:59.32 | coreyf1513 | I wasn't even a linux user when that change was made, and had never heard of asterisk :) |
| 21:59.54 | Kobaz | heh |
| 22:01.12 | Corydon76-work | I was an early adopter. At the time I was running FreeBSD on my desktop, and Asterisk was the impetus to have a running Linux machine in my house. |
| 22:02.55 | Corydon76-work | Back in those days, we emailed all of our patches to Mark, then bugged him incessantly until he committed them |
| 22:03.04 | Kobaz | hah sounds fun |
| 22:03.23 | Corydon76-work | Not quite. |
| 22:03.54 | Corydon76-work | Second committer was Jeremy McNamara, but he had made a promise to only commit things related to chan_h323 |
| 22:05.32 | Corydon76-work | Let's just say that Mark was married to his company in those days, and it was very difficult to find time to get him to commit code. |
| 22:06.15 | Corydon76-work | or even to review the code |
| 22:19.44 | Kobaz | almost done |
| 22:19.49 | Kobaz | well, done with phase 1 |
| 22:40.06 | Kobaz | http://www.netfunny.com/rhf/jokes/92q3/coredb.html |
| 23:11.26 | Kobaz | woah |
| 23:11.54 | Kobaz | i found an interesting problem in GROUP_COUNT |
| 23:12.28 | Kobaz | Set(GROUP()=foo); Set(GROUP()=foo@bar); Set(GROUP()=foo@baz); NoOp(foo: ${GROUP_COUNT(foo)}); GROUP_COUNT = 3 |
| 23:12.49 | Kobaz | GROUP_COUNT() Counts the number of channels in the specified group. |
| 23:12.56 | Kobaz | seems to be that should = 1 |
| 23:20.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.171) |
| 23:24.37 | coreyf1513 | Kobaz: it looks like '@' is a delimiter for all the GROUP functions |
| 23:25.01 | Kobaz | yeah it is |
| 23:25.14 | Kobaz | but that shouldn't affect the group count |
| 23:25.25 | Kobaz | er, channel count, rather |
| 23:25.43 | Kobaz | the docs say it's counting the number of channels, not the number of groups |
| 23:25.55 | coreyf1513 | read the code.. |
| 23:26.08 | Kobaz | the code does what the output says it does |
| 23:26.22 | Kobaz | counts all occurrences of channels in groups |
| 23:27.09 | Kobaz | the linked list traversal just blindly ++'s when it finds a channel |
| 23:27.25 | Kobaz | each group entry is a linked list item which has a char group, char category |
| 23:27.48 | Kobaz | so. on the side of erring on backwards compatibility, the documentation should be updated |
| 23:28.15 | Kobaz | but i don't think that was the intention of the original author |
| 23:28.24 | Kobaz | at least.. that wouldn't be my intention of writing a function like that |
| 23:29.45 | coreyf1513 | the @ symbol separates group from category.. from what I can tell Set(GROUP(foo)=baz) produces the same result as Set(GROUP()=foo@baz) |
| 23:29.57 | Kobaz | true |
| 23:30.57 | Kobaz | the issue i'm talking about is multiply counting a single channel |
| 23:31.20 | Kobaz | multipley |
| 23:31.23 | Kobaz | if that's a word |
| 23:31.32 | Kobaz | not multiplication |
| 23:32.07 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:32.07 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:33.09 | Kobaz | if you do foo foo@bar foo@baz your channel is in three groups |
| 23:33.11 | Kobaz | but you have one channel |
| 23:33.23 | Kobaz | so GROUP_COUNT(foo) should return 1 |
| 23:39.59 | coreyf1513 | what happens if you read GROUP_COUNT(foo@baz)? |
| 23:40.06 | Kobaz | =1 |
| 23:40.18 | Kobaz | er wait |
| 23:40.21 | Kobaz | that was a different test |
| 23:40.28 | Kobaz | the original stuff i had... it's also =3 |
| 23:41.18 | Kobaz | which means the group_count logic is wrong. it's not checking category properly |
| 23:41.40 | coreyf1513 | sorry you said GROUP_COUNT(foo@baz) =1 or 3? |
| 23:41.46 | Kobaz | =3 |
| 23:42.11 | Kobaz | GROUP_MATCH_COUNT=1 |
| 23:42.15 | Kobaz | that's what i had the 1 from |