| 00:01.25 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 00:02.36 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 00:09.17 | *** join/#asterisk-dev Corydon76-home (eleven@c-69-137-80-31.hsd1.tn.comcast.net) |
| 00:09.17 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 01:00.52 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 01:52.37 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:52.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:06.51 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 02:46.15 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 04:17.16 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 04:56.51 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 05:50.59 | wedhorn | snuff-work: you still around? |
| 05:53.57 | snuff-home | yer |
| 05:54.05 | snuff-home | i'm workin @ home but i'm alive :) |
| 05:54.12 | wedhorn | okay, cool |
| 05:54.29 | wedhorn | you have a play with the variable callinfo packet patch? |
| 05:55.11 | snuff-home | i did try it initally.. u've hardcoded to 12 char atm if i remember |
| 05:55.32 | snuff-home | it seemed to work fine.. |
| 05:55.35 | wedhorn | don't think so, hang on |
| 05:56.43 | wedhorn | looks like a limit of 256 for all fields combined |
| 05:57.04 | wedhorn | 12 string limit |
| 05:58.35 | wedhorn | anyway, if you're happy it works, and that it doesn't have a 12 char limit, I'll move it over to review board to get some feedback on the coding |
| 06:03.12 | snuff-home | k sounds good to me |
| 06:03.34 | wedhorn | okay |
| 06:16.05 | wedhorn | snuff-home: and I think that's if for the patches we put together |
| 06:16.24 | snuff-home | sounds bout right.. |
| 06:17.03 | snuff-home | on monday will retest pickup code / missed/place/recv / fdial.. |
| 06:17.14 | snuff-home | then prob user rollout by end of week |
| 06:22.07 | wedhorn | cool, and all without any patches required ;) |
| 06:22.27 | snuff-home | yep.. |
| 06:36.51 | *** join/#asterisk-dev podz (~podz@xdsl-250-108.nebulazone.fi) |
| 06:37.48 | podz | hi. i am testing asterisk with LDAP and the implementation is quite buggy. Any devs who want to work with me to get it right? |
| 06:38.30 | snuff-home | check the bug tracker.. someone was recently doing work on ldap.. |
| 06:38.40 | snuff-home | or the review board.. |
| 06:41.05 | podz | ok. the design itself should be rethought - it's not just "bugs" per se. |
| 06:41.29 | snuff-home | mm well i'm sure we're open to suggestions |
| 06:41.38 | snuff-home | post your thoughts on the -dev mailing list |
| 06:41.44 | snuff-home | more ppl likely to reply.. |
| 06:41.55 | podz | ok, thanks for the good suggestion. |
| 06:42.02 | snuff-home | i'm lucky that i dont have to deal with AD/LDAP most of the time ;) |
| 06:42.16 | snuff-home | *off for tea* |
| 06:42.39 | podz | well, i am designing a large-scale architecture and LDAP would be a key enabler, along with XMPP |
| 06:42.43 | podz | enjoy the tea |
| 06:43.15 | snuff-home | your talking 'config' wise making phones n ldap work better? |
| 06:43.59 | snuff-home | tries to remember if 'sourcery' branch is part of enabling others like ldap more 'access' to asterisk |
| 06:45.50 | podz | LDAP is great for accounts, extensions, even config |
| 06:46.41 | podz | but asterisk is also trying to log presence info into LDAP - against the LDAP paradigm to be constantly writing to it |
| 06:46.56 | snuff-home | check the * wiki.. i think it has 'ast 12' plans.. see if anything there |
| 06:47.02 | podz | also the search filter algorithms are buggy |
| 06:47.16 | podz | will check |
| 06:48.14 | snuff-home | gotta move now.. if u have more questions.. ask here someone may know.. but for more 'in-depth' probably best posting good size msg of what ur doing / how u might help etc to the '-dev mailing list' |
| 06:48.48 | podz | yeah, will do |
| 07:04.28 | *** part/#asterisk-dev podz (~podz@xdsl-250-108.nebulazone.fi) |
| 07:26.37 | *** join/#asterisk-dev schmidts (~schmidts@213162068056.public.t-mobile.at) |
| 07:26.39 | schmidts | good morning |
| 07:28.53 | coreyf1513 | good morning |
| 08:48.25 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 08:48.36 | bombev | good morning guys ;) |
| 08:59.18 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:8440:38c2:ac4b:a0f6) |
| 09:53.12 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:658e:4925:c7be:4574) |
| 10:21.39 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 10:32.51 | *** join/#asterisk-dev danfromuk (~IceChat77@unaffiliated/danfromuk) |
| 10:33.44 | danfromuk | Hi. I was wondering if anyone is familiar with the voicemail source code. I need to know if it currently supports setting the serveremail and emailbody on a per-context basis. |
| 10:52.39 | schmidts | danfromuk i havent dig into the sources of voicemail but i use realtime for voicemail and just set the servermail and body dirctly for each peer. but it makes sense to use it on a context base also |
| 11:00.16 | danfromuk | Perfect. I'll give that a try. I didnt have those fields in the DB. |
| 11:04.13 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 11:06.07 | danfromuk | schmidts: In body, how do you enter a line feed in the database? \n ? |
| 11:08.06 | schmidts | danfromuk \r\n imho |
| 11:47.35 | wdoekes | s/imho/iirc |
| 11:48.40 | schmidts | something like this :D thanks wdoekes |
| 11:54.52 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:17.57 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:05.43 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:05.43 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:25.05 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:25.05 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:55.19 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-taqannwemeyyswez) |
| 14:16.53 | *** join/#asterisk-dev serafie1 (~erin@76.73.167.231) |
| 14:27.26 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ejozqseuyodvkjoz) |
| 14:27.26 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:30.23 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:30.23 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.36 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 14:56.44 | nubbie | okay |
| 14:56.45 | nubbie | https://github.com/pabelanger/pjproject |
| 14:56.56 | nubbie | v1 of the import |
| 14:57.00 | nubbie | preserving svn history |
| 14:57.25 | nubbie | basically, SVN pjproject lives in upstream branches |
| 14:57.36 | nubbie | since an upstream git repo does not exist |
| 14:58.00 | nubbie | Going to ask if I can setup a mirror for them and publish it |
| 14:58.04 | nubbie | or have them to di |
| 14:58.05 | nubbie | it* |
| 14:58.21 | nubbie | then it makes our jobs easier to maintain the fork |
| 15:00.48 | putnopvut | heh, nubbie I had to look up who you were :) |
| 15:07.35 | Kobaz | do de do |
| 15:07.38 | nubbie | nice |
| 15:10.29 | Kobaz | so what would be the easiest way to add "i" handling capability to GoSub |
| 15:12.55 | mjordan | Kobaz: let me ask you this: if you go and execute an i extension when someone attempts to run a subroutine that doesn't exist, how do you execute Return? |
| 15:16.45 | Kobaz | return to the caller |
| 15:16.56 | mjordan | what do you mean? |
| 15:17.08 | mjordan | file: putnopvut: so this is interesting. A fresh checkout of pimp_my_sip on 64-bit centos can't build pjproject |
| 15:17.16 | Kobaz | like: context a { GoSub(b,1,1); } context b { i => { Return(); } } |
| 15:17.26 | file | mjordan, interesting!\ |
| 15:17.41 | Kobaz | so exten '1' doesnt exist in context b |
| 15:17.42 | mjordan | Kobaz: right, but you have to put the Return() in the i extension, which services both GoSub and normal dialplan execution problems |
| 15:17.48 | putnopvut | mjordan: what are the errors? |
| 15:17.51 | mjordan | so now you have a shared extension that is both 'normal' and a 'subroutine' |
| 15:18.05 | mjordan | http://bamboo.asterisk.org/download/ASTTEAM-PIMPMYSIP-AST18CENTOS64/build_logs/ASTTEAM-PIMPMYSIP-AST18CENTOS64-2.log |
| 15:18.12 | Kobaz | but GoSub doesn't respect the 'i' |
| 15:18.31 | mjordan | it attempts to build chan_alsa because the channels subgroup of menuselect doesn't parse |
| 15:18.50 | mjordan | Kobaz: what I'm saying is that if you make it respect 'i', you're going to run into problems |
| 15:18.53 | Kobaz | oh |
| 15:19.07 | Kobaz | but GoSub right now to an invalid exten/context just dies |
| 15:19.13 | mjordan | correct |
| 15:19.14 | file | oh it's the chan_gulp thing |
| 15:19.28 | Kobaz | and, in the documentation for GoSub, it tells you that it respects 'i' |
| 15:19.30 | Kobaz | but it doesn't |
| 15:19.57 | mjordan | it may have when the documentation was written. Or it may be a bug. Either way, my guess is that making it go to the 'i' extension is a bad idea |
| 15:20.04 | Kobaz | mm |
| 15:20.14 | coreyf1513 | Kobaz: are you trying to do something like Gosub(somegosub,${SOMEEXTEN},1) ? |
| 15:20.20 | mjordan | because dialplan writers will *have* to ensure that the 'i' extension can only be reached from a GoSub *OR* from normal dialplan execution |
| 15:20.42 | Kobaz | io |
| 15:20.51 | Kobaz | yeah i'm trying to write a protecton thing |
| 15:20.51 | Kobaz | like |
| 15:20.52 | mjordan | I'd almost rather have a separate invalid subroutine handler |
| 15:20.59 | Kobaz | GoSub(someplace,x,y) |
| 15:21.05 | Kobaz | GoSub(invalidhandler,1,1); |
| 15:21.11 | Kobaz | and if someplace doesnt exist |
| 15:21.14 | Kobaz | go to the next line |
| 15:21.25 | Kobaz | i want to return back to my caller on invalid destination |
| 15:21.44 | Kobaz | yeah, there should be special registered handlers for contexts |
| 15:21.46 | Kobaz | not special extensions |
| 15:22.07 | Kobaz | h, and i should be separately registered somewhere |
| 15:22.43 | mjordan | file: hm. res_sip doesn't have a moduleinfo section |
| 15:23.09 | mjordan | bah |
| 15:23.12 | mjordan | just further down |
| 15:23.14 | Kobaz | it looks like GoTo has some stack capability |
| 15:23.25 | mjordan | but res_sip_session does not |
| 15:30.22 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 15:34.27 | file | hum hum hum |
| 15:53.25 | mjordan | file: ooo - up to 369 tests now on trunk |
| 15:53.40 | file | unit tests? |
| 15:53.46 | mjordan | unit + integration |
| 15:53.49 | file | oic |
| 15:58.42 | file | I have left over pizza. I will soon consume it. |
| 16:06.43 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 16:06.43 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 16:35.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:35.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:55.01 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:13.09 | sruffell | Qwell: when building the RPMs for CentOS, do you use the dahdi-linux-complete tags, or just the actual DAHDI-Linux release? |
| 17:13.19 | Qwell | sruffell: just the release |
| 17:13.39 | sruffell | k, thanks |
| 17:33.13 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-qlnkjmpccenmalgt) |
| 18:01.01 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:3546:2c49:3f4f:17d3) |
| 18:42.08 | mjordan | putnopvut: and your modules.conf worked |
| 18:42.29 | putnopvut | mjordan: well good. |
| 18:42.51 | mjordan | interestingly enough, the sorcery unit tests did not pass |
| 18:43.37 | file | eep |
| 18:43.50 | file | oh |
| 18:44.01 | file | if res_sorcery_memory isn't loaded those'll go kablooey |
| 18:45.22 | file | this: http://lists.digium.com/pipermail/asterisk-commits/2013-January/058834.html makes me happy (specifically how easy it was) |
| 18:45.51 | mjordan | file: well, that can be fixed then |
| 18:50.03 | mjordan | file: you forgot to update the Makefile with res_sip_rfc3326 |
| 18:50.14 | file | I know, and I fixed it |
| 18:50.16 | mjordan | :-) |
| 18:53.38 | Qwell | Will they all be res_sip_*? |
| 18:53.43 | Qwell | wildcard it, y0 |
| 18:54.04 | file | Qwell, doooooo it |
| 18:54.07 | file | :P |
| 18:54.16 | file | for now they probably will be |
| 18:54.17 | Qwell | It's your branch! and you don't have my fixed yet. :( |
| 18:54.21 | Qwell | fixes, too |
| 18:54.25 | file | I know ;( |
| 18:54.38 | Qwell | I need to put that up for review today. |
| 18:54.52 | Qwell | not that anybody in their right mind will actually review build system changes. |
| 18:57.02 | mjordan | hm hm hm. I think we can safely not load those four tests |
| 18:57.31 | file | I agree. |
| 18:58.48 | mjordan | let's see if this works. |
| 18:59.13 | mjordan | with any luck, this means that your threadpool/sorcery unit tests will be run as you integrate it with chan_gulp/res_sip |
| 19:07.05 | mjordan | yay: http://bamboo.asterisk.org/browse/ASTTEAM-PIMPMYSIP-16/ |
| 19:07.48 | file | green means go |
| 19:07.51 | file | or green peppers |
| 19:08.02 | mjordan | or moneys |
| 19:08.11 | mjordan | but not that fake moneys |
| 19:08.13 | blitzrage | or illegal substances of a smoking method |
| 19:08.30 | blitzrage | wacky tobaccy, if you will |
| 19:11.05 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 19:11.24 | mjordan | putnopvut: you may want to put your modules.conf on the wiki page |
| 19:15.11 | putnopvut | mjordan: yeah, good idea. Problem is that it's going to change so often as new SIP modules are added, that it's going to be hard to keep updated. |
| 19:18.03 | blitzrage | add a task to update wiki periodically? |
| 19:18.07 | blitzrage | or at the end of the tasks? |
| 19:18.15 | blitzrage | throws out wild and wacky ideas |
| 19:20.47 | mjordan | putnopvut: it could just be the module load order for what *has* to be loaded before what |
| 19:20.58 | mjordan | people can update the modules.conf as needed with the 'extra' sip modules |
| 19:21.41 | mjordan | blitzrage: for the most part, we're trying to keep the wiki pages up to date as we go along - at least on a sprint basis (2 weeks) |
| 19:22.15 | mjordan | the issues filter is always accurate :-) |
| 19:25.15 | opticron | pops over here |
| 19:25.33 | mjordan | opticron: so, the event IE for blobs takes a pointer to a heap allocation? |
| 19:25.46 | opticron | a pointer and a length |
| 19:25.50 | mjordan | ah ha |
| 19:26.07 | opticron | the blob must contain no pointers so that it can be copied and freed with only an ast_free call |
| 19:26.17 | mjordan | why does it have to be an ast_free call? |
| 19:26.24 | mjordan | I'm sure it does now |
| 19:26.42 | opticron | so that it can be pushed across the network if necessary |
| 19:27.09 | mjordan | if we push it across the network, does the transport layer free the blob? |
| 19:27.36 | opticron | I'd have to look at how things are currently pushed across for res_ais |
| 19:27.44 | opticron | but that's only for device state distrobution |
| 19:27.49 | opticron | *distribution |
| 19:28.08 | opticron | string fields require a cleanup step before free |
| 19:28.13 | mjordan | yes |
| 19:28.24 | mjordan | more generically, this also prevents ao2 objects |
| 19:28.28 | opticron | correct |
| 19:28.29 | mjordan | and other things with custom destructors |
| 19:28.45 | opticron | doubly correct |
| 19:28.48 | mjordan | who owns the destruction of the object? |
| 19:28.57 | mjordan | the consumers of the event, or the event subsystem? |
| 19:29.07 | opticron | the code in main/event.c that queues it |
| 19:29.18 | opticron | subsystem |
| 19:29.39 | opticron | double-checks |
| 19:31.51 | mjordan | if the subsystem owns the destruction, then you can create a new payload type (RAW_W_DESTRUCTOR), and have a new function that adds a raw but specifies a destructor function |
| 19:32.16 | mjordan | you can store a pointer to the destructor function with the raw blob, then in ast_event_ie_val_destroy use it to destroy the memory |
| 19:32.39 | mjordan | destructor functions should probably all be void (*const )(void *) |
| 19:33.23 | mjordan | if the event consumer owns the destruction, then you kind of don't need to worry, as you'll deserialize the object and can dispose of it as you need to (since you know the object type) |
| 19:33.44 | mjordan | but it looks like when a subscription is terminated all queued events are taken care of by the event subsystem, so you'll probably need the new payload type |
| 19:33.47 | opticron | except, if you compact everything into a blob so it can traverse the network, there's no need for a destructor |
| 19:34.09 | mjordan | what do you mean by compact into a blog so it can traverse the network? |
| 19:34.10 | opticron | also, if you need a destructor, you need a copy constructor as well |
| 19:34.16 | mjordan | opticron: why? |
| 19:34.23 | opticron | ref counting and things |
| 19:34.35 | opticron | if it's going to contain pointers |
| 19:34.45 | mjordan | opticron: that's the event consumer's problem |
| 19:36.37 | opticron | ast_event_dup |
| 19:36.46 | mjordan | ah |
| 19:36.47 | mjordan | true. |
| 19:37.09 | mjordan | the flip side of this is that yes, if something attempts to send a 'raw binary' message directly from the event IEs, you're going to have pointers going out into nowhere |
| 19:37.52 | mjordan | so that would break res_ais |
| 19:38.32 | mjordan | opticron: what in an ast_channel is a string field currently that you want to preserve as a string field? |
| 19:38.53 | opticron | I was using string fields for simplicity |
| 19:39.19 | mjordan | alas, your simplicity ran into reality :-) |
| 19:39.21 | opticron | I was thinking about going back to static arrays in the struct or writing up an api to embed strings via offsets into a tailing array |
| 19:39.42 | mjordan | static arrays are probably still easier. |
| 19:39.52 | opticron | yes |
| 19:39.58 | mjordan | I have a feeling we're going to eventually need to be able to pass something along with pointers to other things. |
| 19:43.01 | mjordan | opticron: I can't actually find where something subscribes for events and sends the IEs without first interpreting them |
| 19:43.30 | opticron | copying is still a problem |
| 19:43.46 | opticron | the event system copies things into the cache |
| 19:43.57 | mjordan | that's fine. Provide a copy function |
| 19:44.17 | mjordan | that's not as hard to solve as trying to prevent something from sending raw binary data out to another system with pointers in it |
| 19:46.11 | file | imagines sorcery -> ast_variable -> json |
| 19:46.33 | opticron | yep... |
| 20:00.30 | Qwell | So, who feels like reviewing some GNU make stuff?! |
| 20:04.47 | mjordan | hides |
| 20:11.43 | seanbright | has an IAX2 question! |
| 20:11.46 | seanbright | huzzah! |
| 20:12.17 | seanbright | line 2806 of chan_iax2.c has the following code: |
| 20:12.24 | seanbright | for (i = 2; i <= IAX_MAX_CALLS; i++) { |
| 20:12.42 | seanbright | this is to create the call number pools |
| 20:13.00 | seanbright | well unless you have LOW_MEMORY defined, IAX_MAX_CALLS is 32768 |
| 20:13.26 | seanbright | which, in binary, is a 1 followed by 15 0s |
| 20:13.41 | seanbright | according to the IAX2 RFC, call numbers are 15 bit numbers |
| 20:14.29 | seanbright | so i guess my question is... shouldn't that be < IAX_MAX_CALLS instead of <=? |
| 20:16.34 | seanbright | otherwise it would get put on the wire as call id 0 |
| 20:18.57 | seanbright | err, call number 0 that is |
| 20:22.19 | seanbright | meh. i'll just put it on RB and hope for the best. |
| 20:22.32 | wedhorn | seanbright: don't know much about iax, but you are right, it should be < if the iax call numbers are limited to 16 bits |
| 20:24.10 | wedhorn | sorry, mean 15 bits |
| 20:30.20 | seanbright | right |
| 20:49.11 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 20:52.58 | mjordan | Qwell: ew |
| 20:53.15 | Qwell | hmm? |
| 20:54.13 | mjordan | that's a lot of GNU makefile changes |
| 20:54.39 | Qwell | yes, yes it is. |
| 21:33.56 | *** join/#asterisk-dev nubbie (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:33.56 | *** mode/#asterisk-dev [+o nubbie] by ChanServ |
| 22:00.49 | wedhorn | snuff-home: for info, https://issues.asterisk.org/jira/browse/ASTERISK-20988 is about your session restarts |
| 22:01.55 | snuff-home | nice |
| 22:09.14 | wedhorn | snuff-home: also, it dawned on me what the 0x8017 etc codes in the 144 and 145 packets are |
| 22:09.54 | wedhorn | they're the octal codes \200\xxx (think they put up icons at the beginning of the prompt line) |
| 22:12.27 | wedhorn | also, no idea how to test that session restart patch seeing as it's so intermittent |
| 22:13.09 | wedhorn | maybe you could add a line at the beginning of the do, if (byteread>0) ast_log("Woohoo, saved a session restart"); |
| 22:13.19 | wedhorn | at least you'd see something in the logs |
| 22:41.28 | snuff-home | k.. |
| 23:22.20 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ejozqseuyodvkjoz) |
| 23:43.18 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |