| 01:28.34 | *** join/#asterisk-dev n0tk (~n0tk@gateway/tor-sasl/n0tk) |
| 01:41.29 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 04:06.24 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 04:06.34 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 04:29.07 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 04:29.07 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 05:17.56 | jmls | yawns. |
| 05:17.59 | jmls | morning all |
| 06:37.29 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 07:52.02 | bulkorok | hi... is it possible to put the uniqueid in the AMI Event FaxStatus after finished fax sending?! |
| 08:17.30 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:fcaf:bff7:b9ff:ff8f) |
| 11:08.38 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 11:35.42 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 11:41.17 | *** join/#asterisk-dev irroot (~gregory@2002:294f:dde2:1:b5ce:5681:7113:dadc) |
| 11:43.10 | *** part/#asterisk-dev irroot (~gregory@2002:294f:dde2:1:b5ce:5681:7113:dadc) |
| 12:04.00 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:59.39 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 13:00.25 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-cytnqgsksxvhpqxu) |
| 13:06.50 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 13:07.20 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-etdspjtkvwntnonh) |
| 13:07.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:19.03 | *** join/#asterisk-dev peppux (~peppux@dynamic-adsl-78-12-148-130.clienti.tiscali.it) |
| 13:19.05 | peppux | hi |
| 13:23.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:23.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:25.11 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:25.11 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:41.23 | pabelanger | mjordan: I assume he wants to control access to the asterisk CLI in some way |
| 13:41.39 | mjordan | or manager users. |
| 13:41.49 | mjordan | or 'users' as defined in 'users.conf' |
| 13:41.55 | mjordan | or ... I have no idea. |
| 13:47.13 | mjordan | pabelanger: but as it is, you were right :-) |
| 13:48.05 | putnopvut | He's in here right now if you want to ask. |
| 13:48.41 | peppux | I think he wants to controls the users that connect to the cli, and the commands that their can use. |
| 13:51.35 | pabelanger | WHO'S THE BOSS! |
| 13:52.43 | peppux | o.O |
| 13:53.47 | pabelanger | Tony Danza of course |
| 13:57.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:57.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:33.30 | *** join/#asterisk-dev glongo (~peppux@dynamic-adsl-78-12-148-130.clienti.tiscali.it) |
| 14:37.11 | leifmadsen | isn't there a cli_permissions.conf file for that kind of stuff? (control of CLI commands) |
| 14:38.08 | glongo | leifmadsen: yes |
| 14:41.26 | pabelanger | leifmadsen: actually, I couldn't find it within the book |
| 14:41.32 | *** join/#asterisk-dev jmls (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 14:41.34 | pabelanger | maybe add it for 4th? |
| 14:42.09 | leifmadsen | pabelanger: we likely didn't document it :) |
| 14:42.36 | leifmadsen | The Definitive Guide is actually just short form for The Most Definitive Guide As Far As We Know |
| 14:42.42 | leifmadsen | (or whatever that working title was) |
| 14:54.03 | *** join/#asterisk-dev jmls1 (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 14:59.05 | glongo | I signed up and signed a license agreement, what can I do now? |
| 15:09.57 | leifmadsen | you can contribute patches :) |
| 15:17.20 | *** join/#asterisk-dev jmls1 (~julian@host217-36-208-155.in-addr.btopenworld.com) |
| 15:18.26 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 15:27.10 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:27.10 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:29.34 | glongo | patch about which version of asterisk? |
| 15:31.24 | russellb | yes |
| 15:32.27 | mjordan | patches for new features are written against trunk. Patches that fix bugs are written against the oldest supported branch of Asterisk that has that bug (although you're more than welcome to write patches for non-supported branches, they just won't be merged in) |
| 15:38.24 | italorossi | mjordan: I saw that ASTERISK-16115 was fixed yesterday, thanks for your attention |
| 15:39.05 | mjordan | italorossi: thank putnopvut, since he committed it :-) |
| 15:39.36 | putnopvut | It's easy when there are good patches attached and a good explanation of the patch in the comments |
| 15:39.38 | mjordan | italorossi: and thanks for cleaning up/writing/testing that patch - definitely appreciated |
| 15:40.39 | italorossi | mjordan: putnopvut: :) |
| 15:43.00 | *** part/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:56.27 | *** join/#asterisk-dev danfromuk (~IceChat77@2.27.38.64) |
| 16:00.41 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 16:05.08 | danfromuk | Hi. I'm looking at the asterisk source code for the first time to try to work out why, when a shared line appearance is placed on hold, the SIP NOTIFY state doesnt change, even though SHOW HINTS says "state: hold". |
| 16:05.41 | danfromuk | I beleieve its in app meetme, however ive never looked through it. Is anyone familiar with that source code? |
| 16:09.10 | pabelanger | Richard kicking around today? |
| 16:09.30 | pabelanger | Had a PRI questions for him about duplicate SETUP messages in Asterisk |
| 16:17.02 | WIMPy | pabelanger: In what context? |
| 16:18.24 | pabelanger | WIMPy: https://issues.asterisk.org/jira/browse/PRI-123 |
| 16:19.34 | pabelanger | Just wanted to get a better understanding of it |
| 16:21.13 | WIMPy | The descriptions are a little vague. |
| 16:22.08 | WIMPy | But I noticed a few days back when looking at an issue discussed in #asterisk that the displayed callref was not consistant. |
| 16:22.56 | WIMPy | The top bit was either present or missing. This may happen on output, but could potentially come from deeper. |
| 16:24.42 | WIMPy | But it all seems to be about duplicate callrefs, not duplicate setups. |
| 16:25.56 | b3nt_pin | I encountered some "High fence violations" when doing some testing of ICE support in Asterisk. In this particular case a pjnath generated string was being duplicated with ast_strndup(). pjX strings are not necessarily null terminated but that is actually beside the point in this case... |
| 16:26.40 | b3nt_pin | in the __ast_strndup() a bunch of "stuff" occurs to create a buffer of the appropriate length, then ultimately strcpy(ptr, s) is called... |
| 16:29.03 | b3nt_pin | this seems wrong as the buffer that was allocated is according to the size of the duplicate requested, not the size of the source string. Chances are that the memory pointed to by ptr is not big enough. |
| 16:29.49 | *** join/#asterisk-dev italorossi (~Adium@189.124.200.92) |
| 16:31.07 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 16:32.50 | Qwell | b3nt_pin: I'd say there's a pretty good chance you're right. That code has existed like that since r927. It was probably just copied and not corrected from the function above. |
| 16:35.05 | Qwell | and I can appreciate the irony of such a bug in the memory debugging code. |
| 16:37.11 | b3nt_pin | well, on the positive side it doesn't do it silently :) |
| 16:42.52 | *** join/#asterisk-dev danfromuk (~IceChat77@2.27.38.64) |
| 16:43.02 | b3nt_pin | now here is a stupid nit question related to bug reporting policy, we know what the bug is but the original cause was running Asterisk with ICE support... |
| 16:44.32 | b3nt_pin | I'm not certain as to the appropriate way to report it. My initial thought was write it as specific to the code, but the bug reporting guidelines imply that it is more appropriate to report it according to the initial conditions that caused the defect to be looked at in the first place... |
| 16:44.57 | b3nt_pin | pedantic, I know :) |
| 16:45.00 | Qwell | Well, in this case, we know what the issue actually is. |
| 16:45.03 | Qwell | probably. |
| 16:45.33 | Qwell | Lots of users don't investigate, so their opinion on what the problem is isn't quite as useful. :) |
| 16:45.33 | b3nt_pin | nods |
| 16:45.39 | b3nt_pin | ahhhhh |
| 16:46.16 | b3nt_pin | results of actual investigation == good, uninformed speculation == bad |
| 16:46.23 | Qwell | When that happens, we end up with things like https://issues.asterisk.org/jira/browse/ASTERISK-10727 |
| 16:47.04 | danfromuk | Hi. I'm looking at the chan_sip due to an issue with shared line apperance. I was wondering, when state = AST_EXTENSION_ONHOLD, is there any reason why statestring = "confirmed"? I want to get the phone's BLF to flash indicating that the call is on hold. |
| 16:49.07 | putnopvut | danfromuk: I believe the statestring is representative of the SIP dialog state. In such a case, the dialog is in the confirmed state. |
| 16:49.14 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:49.14 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:50.12 | danfromuk | Is there any problem in changing this to 'early' to cause the blf key to flash when a call is on hold? |
| 16:50.32 | danfromuk | ie, is that string used anywhere else in asterisk? |
| 16:50.51 | putnopvut | Well, it would be inaccurate :) |
| 16:51.35 | danfromuk | I realise, however the phone i'm trying to get working seems to have a bug that means it doesnt process the ON HOLD sip packet properly. |
| 16:58.17 | danfromuk | Out of interest, where can i find specifications of the sip protocol with regards to the NOTIFY packet? |
| 16:58.37 | danfromuk | done a search for sip rfc but can't seem to find the information i'm looking for |
| 17:00.44 | danfromuk | putnopvut: so when a call is placed on hold, the state is still 'confirmed'? How does an endpoint know if a call is on hold? Is it only tracked by the endpoint? |
| 17:02.09 | putnopvut | SIP dialogs don't really have the concept of "hold" since dialogs are also used for things like subscriptions. |
| 17:02.10 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 17:02.42 | putnopvut | So having a remote endpoint know if another is on hold...not really sure how you'd do that given SIP's subscribe-notify system. You'd have to find an RFC for an event package that defines that. |
| 17:02.54 | putnopvut | Perhaps some sort of rich presence extension might cover that level of detail. |
| 17:04.55 | danfromuk | It seems like the presence of sip.rendering=no means 'on-hold' and therefore asterisk is behaving correctly. |
| 17:05.13 | danfromuk | however the pansonic phone i'm testing does not change state to show the hold. |
| 17:05.15 | danfromuk | https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-May/009099.html |
| 17:05.46 | *** join/#asterisk-dev MLNoah (~MLNoah@noc.metalink.net) |
| 17:06.50 | *** join/#asterisk-dev b3nt_pin (~quassel@stjhnf0148w-142134201057.dhcp-dynamic.FibreOp.nl.bellaliant.net) |
| 17:26.31 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 18:35.33 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 18:36.04 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 19:03.04 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 19:05.20 | jmls1 | UpdateConfig manager command - is there any way of simply replacing the contents of a file with new data ? |
| 19:06.01 | jmls1 | i.e instead of specifying each cat-000000, cat-000001 etc I can just say "here's the new contents of the file. write it." |
| 19:07.19 | jmls1 | perhaps an extra option to "CreateConfig" ? |
| 19:15.53 | mjordan | jmls1: I would almost prefer a new Manager command for it. ReplaceConfig? |
| 19:17.20 | jmls1 | yup |
| 19:17.49 | jmls1 | suppose it would be easy enought |
| 19:17.53 | jmls1 | *enough |
| 19:18.07 | jmls1 | set a max limit on size of data ? |
| 19:18.35 | leifmadsen | makes sense to me |
| 19:18.50 | leifmadsen | unless there is no reason for a limit |
| 19:19.22 | jmls1 | not a C guy |
| 19:19.38 | jmls1 | can you set a limit depending on the amount of free memory ? |
| 19:19.58 | jmls1 | how many peers would it take to fill 64k ? |
| 19:20.07 | jmls1 | no, that's not a joke .. ;) |
| 19:20.37 | jmls1 | what's the size of the biggest extensions.conf you've seen ? |
| 19:21.18 | mjordan | jmls1: Large, but I'm not sure I would handle it that way. |
| 19:21.26 | jmls1 | listens |
| 19:21.34 | mjordan | jmls1: you could instead look at it as "replace the existing .conf file with this .conf file" |
| 19:22.22 | mjordan | you can build up a conf file using CreateConfig and UpdateConfig, and then, when its built, run a ReplaceConfig to copy it over |
| 19:22.50 | jmls1 | I really really don't want to have to create a cat-000000 , cat-000001 etc |
| 19:22.55 | jmls1 | what a pita |
| 19:23.05 | mjordan | I think trying to send the entire dump over will run into some issue at some point in time. You'll end up having to do something along the lines of what manager does to write data out from a CLI command, only in reverse |
| 19:23.43 | mjordan | which is to use a temporary file to buffer the data, and write it out in chunks. Instead, you'd need to read the data, write it to a temporary file, and when you've read the entire contents from the buffer, move the temporary file over to the actual config file you're replacing |
| 19:24.09 | mjordan | and yes, this would be a pita - but anytime you're trying to send an unknown amount of data, you'd run into this kind of problem |
| 19:27.23 | jmls1 | mmm. I have this extra_peers.conf file sitting on the webserver - which is currently got using curl from sip.conf (#exec curl) |
| 19:27.48 | jmls1 | what I want to do it put that file into the asterisk box so that if the webserver is down, asterisk still operates |
| 19:28.17 | Qwell | jmls1: we did something like that with the Digium PBX a long time ago. |
| 19:28.37 | Qwell | We made a script that would wget the file if it could, and cache a copy, so that if the server was down, the local copy would still be there. |
| 19:29.15 | jmls1 | interesting |
| 19:32.21 | jmls1 | wget --timeout=0.5 |
| 19:32.37 | jmls1 | that would abort if no response after .5 seconds |
| 19:32.54 | jmls1 | Qwell: thanks. that's set me on a path ;) |
| 19:36.05 | jmls1 | does each #exec in a .conf file operate sequentially ? |
| 19:36.28 | jmls1 | has been doing a lot of node.js recently. very painful, all this async stuff ... |
| 19:36.54 | jmls1 | I was thinking that the first #exec would simply download a new copy if available |
| 19:37.14 | Qwell | I don't know. Probably? |
| 19:37.47 | jmls1 | and a #include after the #exec would then use that file (or the old copy if the server was not available) |
| 19:38.32 | jmls1 | that would work |
| 19:38.55 | Qwell | iirc, we just basically tried to curl, and then did a cat on the file whether it succeeded or not |
| 19:39.08 | Qwell | well, really we used svn, but same thing |
| 19:40.02 | jmls1 | sure. if it times out then it wouldn't be overwritten |
| 19:40.06 | jmls1 | neat |
| 19:41.43 | Qwell | yeah something like that |
| 19:42.02 | Qwell | I was trying to see if we still had that around somewhere, but that server went away a long time ago |
| 19:49.49 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 20:06.02 | *** join/#asterisk-dev yosafbridge (~yosafbrid@li125-242.members.linode.com) |
| 20:29.21 | *** join/#asterisk-dev n0tk (~n0tk@gateway/tor-sasl/n0tk) |
| 20:37.37 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-trhonelaoqxybyxm) |
| 20:56.12 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 21:01.32 | *** join/#asterisk-dev leedm777 (~Adium@nat/digium/x-lbsezeyxubgmjzri) |
| 21:03.01 | *** join/#asterisk-dev dms (~dms@nat/digium/x-uvofwstgmkizoeie) |
| 21:26.52 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 21:32.49 | mjordan | putnopvut: you still around? |
| 21:33.45 | putnopvut | I am still around and alive |
| 21:35.07 | mjordan | so, we apparently used to accept and process srtp attributes with a media description of 'rtp/avp', instead of 'rtp/savp' |
| 21:35.19 | mjordan | I may have 'fixed the glitch' and thereby broken several models of phones |
| 21:35.23 | putnopvut | lol |
| 21:35.57 | putnopvut | So are you going to unfix that glitch? |
| 21:36.01 | mjordan | I'm trying to think of what's the best mechanism to handle that. I'd prefer to avoid another configuration parameter, but it feels like the only other option is to assume that the offerer intended savp if we run into a crypto attribute |
| 21:36.09 | mjordan | I'm mulling it over. I'll probably have to. |
| 21:36.11 | putnopvut | Exactly |
| 21:36.17 | mjordan | blech. |
| 21:36.17 | putnopvut | "Be liberal with what you accept..." |
| 21:36.29 | putnopvut | Essentially, they offer crypto, then they clearly meant SAVP |
| 21:36.40 | mjordan | I may put a snarky debug message in. |
| 21:36.43 | putnopvut | They're being dumb about it, but we can be accommodating. |
| 21:36.49 | putnopvut | yes, feel free to do that. |
| 21:44.55 | *** join/#asterisk-dev italorossi (~textual@189.124.200.92) |
| 21:48.42 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-etdspjtkvwntnonh) |
| 22:12.00 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 22:12.21 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 22:12.31 | *** join/#asterisk-dev flujan (~flujan@189.111.106.4) |
| 22:26.00 | *** join/#asterisk-dev spditner (~simon@206-248-134-232.dsl.teksavvy.com) |
| 22:39.08 | *** join/#asterisk-dev kpfleming (~kpfleming@unaffiliated/kpfleming) |
| 22:50.42 | *** part/#asterisk-dev flujan (~flujan@189.111.106.4) |
| 22:53.16 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 22:53.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |