| 00:23.08 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 00:23.11 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-yqjyucuwdcraftfh) |
| 00:35.10 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 00:35.10 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 00:43.23 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-agienxorfljflaey) |
| 00:43.41 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 00:53.46 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 01:00.41 | *** join/#asterisk-dev frawd (~francois@210.Red-88-24-190.staticIP.rima-tde.net) |
| 01:35.46 | *** join/#asterisk-dev frawd (~francois@210.Red-88-24-190.staticIP.rima-tde.net) |
| 01:42.49 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 03:17.31 | *** join/#asterisk-dev philipp64 (~chatzilla@mail.redfish-solutions.com) |
| 03:52.55 | *** join/#asterisk-dev brookshear (~brookshea@adsl-76-202-188-178.dsl.wacotx.sbcglobal.net) |
| 03:59.16 | *** part/#asterisk-dev brookshear (~brookshea@adsl-76-202-188-178.dsl.wacotx.sbcglobal.net) |
| 04:25.05 | *** join/#asterisk-dev moy_ (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 05:13.13 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 06:14.09 | *** join/#asterisk-dev mpe (~mpe@gate.ipvision.dk) |
| 06:25.37 | *** join/#asterisk-dev diegomad (~mad@190.147.221.78) |
| 06:34.26 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-36-108-119.ptld.qwest.net) |
| 07:02.44 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 07:02.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:09.09 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:27.50 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:41.31 | *** join/#asterisk-dev schmidts (d5ebd4c1@gateway/web/freenode/ip.213.235.212.193) |
| 07:41.34 | schmidts | hello |
| 08:31.06 | *** join/#asterisk-dev Dovid (Dovid@213.8.118.62) |
| 08:50.25 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-150-41.cinci.res.rr.com) |
| 09:05.19 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:05.19 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:12.53 | oej | Hello folks |
| 09:13.07 | schmidts | hello |
| 09:44.23 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 10:12.47 | Dovid | hi ole |
| 11:24.21 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:24.21 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:31.05 | *** join/#asterisk-dev ccesario (~ccesario@187.75.139.188) |
| 11:31.21 | jsmith | Morning oej.... morning all |
| 11:31.32 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:33.48 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 11:39.30 | schmidts | maybe today someone could help me with my locking problem? |
| 11:42.24 | jsmith | schmidts: Your best bet is to ask in #asterisk, unless your question specifically concerns the C code of Asterisk. |
| 11:42.38 | jsmith | schmidts: Feel free to give me a short description of your problem, and I'll try to guide you to the proper channel |
| 11:43.02 | schmidts | thank you jsmith its concerning directly the c code |
| 11:43.19 | jsmith | Then you're in the right place :-) |
| 11:43.53 | jsmith | It's a bit early for some of the developers to be paying attention, but I'm sure some of there are here lurking already :-) |
| 11:44.04 | schmidts | i have tried to upgrade my hosted pbx from 1.2.40 to 1.6.2.10 and had problems that when most of the 3300 peers get registered and subscribe their hints (also > 3000) they start to get unreachable |
| 11:44.21 | schmidts | its afternoon at my place, i start loosing attention :D |
| 11:45.01 | schmidts | and i ´ve seen some locking in the ao2_callback of dialog needdestroy function |
| 11:45.46 | schmidts | after some further investigation i´ve seen that in the sip do_monitor loop this callback is launched in every loop which will (in my opinion) to slow down sip handling |
| 11:47.05 | schmidts | i´ve allready written a patch to only do this callback only once in 10 seconds, but iam not sure if this would cause some troubles in sip handling |
| 11:47.33 | kpfleming | it should not be a big problem, it would mean that dialog structures would live for a little while longer than they should |
| 11:48.24 | kpfleming | i'm surprised you were able to successfully handle 3300 peers with more than 3000 subscriptions on 1.2.40 |
| 11:48.55 | schmidts | i was even more suprised as i doesnt work in 1.6.2 ;) |
| 11:50.22 | schmidts | most time not all peers are registered at once but normally there are more than 2200 |
| 11:50.44 | kpfleming | that is quite a lot of sip registrations for one asterisk system to handle, with any version |
| 11:51.15 | kpfleming | when you double the number of dialogs but adding that many subscriptions, it gets even worse |
| 11:51.24 | kpfleming | s/but/by/ |
| 11:51.35 | schmidts | i know and we have also tried to use a proxy in front but the blf handling still doesnt work as expecated |
| 11:52.30 | schmidts | i know, thats why i´ve started my investigation to tune the sip processing |
| 11:53.02 | kpfleming | you'll probably better off to investigate using OpenAIS to distribute the presence state across multiple asterisk systems, and then use 3 or 4 asterisk systems |
| 11:54.17 | schmidts | so you dont think asterisk could handle this amount on a single process/server at once? |
| 11:54.34 | jsmith | It's certainly a lot of messages to handle |
| 11:55.13 | schmidts | i know |
| 11:55.15 | kpfleming | i would not expect asterisk to be able to handle 6K+ open dialogs at once, no |
| 11:55.47 | kpfleming | with half of the dialogs being registrations, it's possible that the code could be improved somewhat |
| 11:55.54 | kpfleming | registrations are easier to handle than calls |
| 11:56.20 | schmidts | 207 active SIP channels -- Remote UNIX connection Verbosity is at least 3 |
| 11:56.21 | schmidts | <PROTECTED> |
| 11:56.28 | schmidts | thats live with 1.2.40 ;) |
| 11:57.10 | kpfleming | well, that's nice to hear, but it's definitely beyond what would be expected to work :-) |
| 11:57.40 | schmidts | ok so thats the problem, it works now, but if we want to upgrade i wouldnt work anymore :( |
| 12:03.25 | schmidts | the problem i have seen on my debugging is the timing between scheduled events and polling for incoming packets meanwhile |
| 12:04.44 | schmidts | is there a way to split up reading and execute scheduled events even if the both use the same UDP file descriptor or wouldnt this work? |
| 12:10.02 | kpfleming | no, unfortunately |
| 12:10.22 | kpfleming | you can't have two threads processing potential actions on the same dialogs |
| 12:10.35 | kpfleming | at some point chan_sip will become multithreaded, but it's going to be a tough job |
| 12:11.13 | kpfleming | it is possible (although it hasn't been heavily tested) that if you have your SIP clients connect via TCP instead of UDP that the situation will get better, because TCP sockets are handled by multiple threads |
| 12:11.43 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 12:18.33 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 12:19.58 | schmidts | are you sure about the threads? in ast_io_wait the function which is called in do_monitor all file descriptors are polled and i thought this is also for the tcp sockets |
| 12:21.10 | schmidts | http://www.asterisk.org/doxygen/asterisk1.6.2/io_8c.html#6f1abe730a5606b88c8f415f53b784bc |
| 12:22.22 | kpfleming | maybe so... it's not something i've paid a lot of attention to lately |
| 12:23.18 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:23.18 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:24.15 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 12:24.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 12:24.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:25.36 | schmidts | i wish i could say this about my last month ;) |
| 12:38.43 | schmidts | is there a tool where i can send subscribes to asterisk? |
| 12:38.53 | schmidts | i dont think asterisk itself could do this? |
| 12:46.13 | kpfleming | sipp |
| 12:46.52 | schmidts | ok i will try, i have only used sipp to generate calls |
| 12:47.02 | russellb | it's just like that, but different |
| 12:47.12 | schmidts | :D |
| 12:48.56 | schmidts | i am not sure but could also astdb itself could be a problem? |
| 12:49.23 | schmidts | i´ve seen on a slower system like the production astdb->sync took up to 40ms |
| 12:50.06 | schmidts | s/the/my |
| 12:50.50 | kpfleming | there is a tool in one of our repositories called sniff2sipp which can take a packet capture of a SIP transaction and turn it into a sipp scenario file; this could be very useful for you to use sipp to generate SUBSCRIBE dialogs. |
| 12:51.12 | schmidts | thats cool thank you |
| 12:51.22 | russellb | http://svn.digium.com/svn/snipp2sipp/trunk |
| 12:51.26 | russellb | if i were to guess off of the top of my head |
| 12:52.14 | kpfleming | sniff2sipp |
| 12:52.28 | russellb | yes. |
| 12:52.30 | russellb | i fail |
| 12:52.39 | russellb | again |
| 12:52.51 | schmidts | :D thx got it |
| 12:53.13 | kpfleming | russellb: it's earlyish |
| 12:53.17 | russellb | true statement |
| 12:53.29 | Marquis42 | I knew there was a reason I lurked here all the time. You learn of awesome thing like that sniff2sipp tool. :) |
| 12:54.02 | russellb | yay |
| 12:56.47 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:56.48 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 13:20.59 | kpfleming | russellb: you should twilson to write an asterisk.org blog post about that tool |
| 13:21.14 | russellb | agreed. |
| 13:21.46 | russellb | and by that I mean I'll tell leifmadsen to ask twilson to do it |
| 13:21.50 | russellb | leifmadsen: :-p |
| 13:21.53 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:22.04 | leifmadsen | russellb: I can totally ask someone to do some work |
| 13:22.36 | russellb | leifmadsen: well, I sort of meant, work with him to get an example together, and you turn it into a howto blog post |
| 13:23.04 | russellb | leifmadsen: you're the blog content man, make it happen! |
| 13:23.06 | leifmadsen | that sounds like significantly more work than telling twilson to do something :D |
| 13:23.10 | russellb | yes. |
| 13:23.16 | russellb | annnnd go |
| 13:23.17 | leifmadsen | I will still accept your challenge. |
| 13:23.23 | russellb | xlnt |
| 13:26.39 | schmidts | what you think will be the maximum of peers that can register to asterisk 1.6.2.11 ? |
| 13:26.49 | schmidts | or does it depend on the amount of subscribes too? |
| 13:27.04 | russellb | subscriptions will affect it for sure |
| 13:27.57 | schmidts | ok, iam now running a test from server A (slow and old) registering 20k peers on server B (quad core hp dl 380) |
| 13:28.15 | schmidts | maybe i could see something, but until now it just runs fine |
| 13:28.56 | schmidts | the only thing i see sometimes is a lock in astdb_put |
| 13:30.08 | pabelanger | It seems like a cool tool for creating testsuite tests. Never knew about it. |
| 13:33.02 | schmidts | ok got it |
| 13:33.17 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 13:33.25 | schmidts | after 8300 peers registered i have done a sip show peers, and now every peer which was reachable got unreachable |
| 13:38.04 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 13:45.08 | *** join/#asterisk-dev Corydon76-dig (purple@c-69-137-80-31.hsd1.tn.comcast.net) |
| 13:45.08 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 13:47.03 | *** join/#asterisk-dev Sipster_ (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 13:50.12 | schmidts | i am now trying my patches on the faster machine and it looks nice :D |
| 13:51.14 | schmidts | before my patches the same machine has always around this value: |
| 13:51.17 | schmidts | 325 active SIP dialogs |
| 13:51.42 | schmidts | after: |
| 13:51.42 | schmidts | 667 active SIP dialogs |
| 13:57.19 | schmidts | by now: 984 active SIP dialogs |
| 14:01.40 | russellb | cool :-) |
| 14:02.08 | schmidts | 20015 sip peers [Monitored: 10032 online, 9968 offline Unmonitored: 15 online, 0 offline] |
| 14:02.12 | schmidts | still registering ;) |
| 14:02.35 | schmidts | and the very best of this ;) |
| 14:02.36 | russellb | so your changes are rate-limiting the dialog destruction loop? |
| 14:02.46 | schmidts | load average: 0,03, 0,05, 0,14 |
| 14:02.49 | russellb | or something else too? |
| 14:02.50 | russellb | wow |
| 14:03.26 | schmidts | several things, one patch is allready planen for 1.6.2.12 thats how the scheduler calculate the time |
| 14:03.55 | russellb | ah yes, I think I merged that one :-) |
| 14:04.17 | russellb | I'm very interested in what you're doing ... it would be really great to get all of your patches in for 1.8 |
| 14:04.34 | schmidts | next is to calculate the real time how long the ast_io_wait function needs to run, and summary this value up until i reach 10 seconds, than only fire once the ao_2calback for the dialog_needdestroy |
| 14:05.35 | schmidts | i am still not sure about this, cause the summary of open dialogs increase with this |
| 14:05.47 | schmidts | and the last thing i found using much of time compares and output is that in astdb_put the astdb->sync call tooks really tooo much time, if the astdb is large and its called every time a peer register |
| 14:06.18 | russellb | yeah, i'm not sure what to do about that ... it's done to prevent data loss |
| 14:06.26 | russellb | ensure that every change is pushed out to disk |
| 14:06.58 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 14:06.58 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 14:06.58 | russellb | i suppose it could be inefficiency of db1 |
| 14:07.02 | schmidts | i know but even on this new fast machine it tooks up to 3 ms with more than 5000 entries in astdb |
| 14:07.08 | russellb | :-/ |
| 14:07.19 | schmidts | on a slower one i have seen values of 40 to 50ms |
| 14:07.22 | russellb | i know sqlite does the same thing, i wonder how its performace compares |
| 14:07.42 | russellb | (not that swapping them out is trivial) |
| 14:07.50 | schmidts | and thats why the timing of polling and sending scheduled events just got out of sync |
| 14:10.17 | Corydon76-dig | schmidts: what's the disk backing up your /var/lib/asterisk partition? |
| 14:10.25 | *** join/#asterisk-dev espiceland (~erin@nat/digium/x-dypofsdgwndiqtvb) |
| 14:10.33 | Corydon76-dig | Please don't say RAID 5 |
| 14:11.41 | russellb | yeah, disk type / RAID / etc will certainly affect the fsync() performance |
| 14:12.11 | schmidts | i have to ask our sysadmins i am not sure |
| 14:12.27 | Corydon76-dig | RAID 5 will give you utterly awful write performance |
| 14:13.04 | schmidts | is there a way to see this with an debian system? |
| 14:13.53 | russellb | open the case, ... |
| 14:13.54 | russellb | jk. |
| 14:14.06 | schmidts | :D |
| 14:14.13 | russellb | i'm sure there is, but my sysadmin foo is weak. |
| 14:14.20 | tzafrir_laptop | sqlite3 does. But not db1, right? |
| 14:14.33 | russellb | does what, fsync() ? |
| 14:14.42 | tzafrir_laptop | yes |
| 14:15.32 | tzafrir_laptop | anyway, isn't fsync less of a problem with later kernels? |
| 14:15.36 | Corydon76-dig | tzafrir_laptop: my understanding was that sqlite used db1 as a backend, so it's the same thing |
| 14:17.08 | malcolmd | well, you can always cat /proc/mdstat to see if there's any software RAID involved. for hardware RAID, you're probably going to have to look at the dmesg output to see what kind of disk controllers are installed, no? |
| 14:17.20 | *** join/#asterisk-dev chazzam-work (~chazz@nat/digium/x-yoiuoiawyrvesnfj) |
| 14:17.41 | russellb | i guess i don't know for sure re: db1 and fsync(), but schmidts analysis seemed to indicate that it was doing it |
| 14:18.09 | schmidts | array-info -d says its a Raid 1 |
| 14:18.56 | schmidts | 20015 sip peers [Monitored: 20000 online, 0 offline Unmonitored: 15 online, 0 offline] |
| 14:21.06 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:21.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:21.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:21.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:21.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:21.35 | schmidts | http://pastebin.com/49ASzTFn |
| 14:24.26 | schmidts | so i think asterisk.1.6.2 could handle 3300 peers even with 3000 subscriptions |
| 14:26.30 | pabelanger | Q: In a SIP trace, between the 100 Trying and 183 Session Progress message is it valid to change the Dst port from one value to another? (IE: Dst port: 58481 to 5060)? Never noticed that before |
| 14:28.15 | pabelanger | Here is the example I was referring too: http://www.msfsupply.be/asteriskmute.pcap |
| 14:32.17 | schmidts | looks like a stupid sip ALG problem |
| 14:32.50 | schmidts | maybe the router doesnt recognize 100 as an important sip package and send it to the original port, and 183 it turns it to port 5060 |
| 14:34.42 | pabelanger | Ya, not sure. Just found it strange the ITSP would change the Dst port, mid-call, between 100 and 183. |
| 14:53.36 | mpe | leifmadsen: 0017835 has been updatet |
| 14:53.57 | leifmadsen | mpe: What is, "A true statement" ? |
| 14:54.05 | leifmadsen | oh... HAS been updated |
| 14:54.10 | leifmadsen | I read that as "has not been updated" :) |
| 14:54.15 | leifmadsen | M17835 |
| 14:54.17 | MuffinMan | [feedback] [Asterisk] Core/Configuration 0017835: [patch] say.conf dont have the same amount of rule's as say.c reported by RoadKill https://issues.asterisk.org/view.php?id=17835 |
| 14:54.24 | mpe | yes |
| 14:55.36 | mpe | what is the normal procedure for feedback as they tend to stay at that level forever |
| 14:57.13 | russellb | once feedback has been provided, one of the bug marshals should see it and change its status |
| 14:57.23 | russellb | if feedback does not get provided, it will get cosed out |
| 14:57.49 | russellb | since there are so many issues on there, it does take some time to see the updates and get things moving again |
| 14:58.03 | leifmadsen | it's all a manual process :) |
| 14:58.15 | leifmadsen | I get about 500+ emails a week from mantis |
| 14:58.28 | mpe | hmm that sound like fun |
| 14:58.31 | leifmadsen | sometimes takes a bit for me to catch up |
| 15:00.09 | mpe | if you have a support contract can you then refere to a nomal bug and get it speedet up |
| 15:00.41 | mpe | if I have the same problem as an existing bug |
| 15:06.26 | schmidts | https://issues.asterisk.org/view.php?id=17912 |
| 15:06.41 | schmidts | this is the patch on chan_sip.c for the ao2 callback |
| 15:07.22 | schmidts | the other one i will submit tomorow, have to go home now or my wife will be angry ;) |
| 15:08.21 | schmidts | 20k user still online with a load around 0,10 ;) |
| 15:09.13 | schmidts | cya tomorrow |
| 15:17.53 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 15:32.10 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 15:33.32 | Qwell | what could happen if you use somestringfield->str directly, rather than ast_str_buffer(somestringfield)? |
| 15:33.43 | seanbright | a puppy would die |
| 15:34.04 | kpfleming | depends on what 'use' means |
| 15:34.16 | seanbright | i think the idea of ast_str_buffer() was just to hide the implementation details |
| 15:34.32 | kpfleming | that is basically true |
| 15:34.44 | kpfleming | because like right now, we could change it to _str, or _seanbright |
| 15:34.55 | seanbright | i vote for _seanbright |
| 15:35.23 | seanbright | bigger binary if you have debugging symbols turned on... but who cares!? |
| 15:35.50 | seanbright | there's your problem - _seanbright is NULL |
| 15:44.28 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:49.09 | tzafrir_laptop | notes that in Hebrew 'vote' and 'point [to]' are the same verb |
| 15:49.29 | kpfleming | interesting |
| 16:22.12 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 16:23.54 | Qwell | votes file menacingly |
| 16:24.49 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 16:26.58 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:13.49 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 17:50.22 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 17:58.18 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 18:08.49 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 18:26.24 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 18:26.24 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 18:36.00 | eliel | Corydon76-dig: if i commit latest code from gsoc today, we could merge it to 1.8? |
| 18:43.15 | Corydon76-dig | eliel: where are you committing it? |
| 18:43.48 | Corydon76-dig | Things that go into 1.8 are committed there first, then merged forward to trunk |
| 18:44.52 | Corydon76-dig | eliel: I'd suggest that anything like that for inclusion in 1.8 should be carefully reviewed by Russell or myself before it goes into 1.8 |
| 18:45.58 | eliel | ok, there is already a review request of the latest data providers |
| 18:46.14 | eliel | i will wait for the last reviews |
| 18:46.24 | eliel | i will commit it in trunk |
| 18:47.32 | Corydon76-dig | eliel: I'm saying if you commit it to trunk, that there's no merge path from trunk to 1.8 (only the opposite direction) |
| 18:48.08 | eliel | oh, ok |
| 19:59.34 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 19:59.34 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:06.27 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:06.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:11.23 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:11.23 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:42.25 | *** join/#asterisk-dev crowb4r (~JKLOBUCAR@12.2.84.2) |
| 21:20.58 | *** join/#asterisk-dev hardwire (~spencersr@69-161-26-211.static.acsalaska.net) |
| 21:21.21 | hardwire | trying to find the place in chan_sip.c where I can explicitely ignore sdp on initial invite |
| 21:25.39 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 21:26.21 | kpfleming | umm... if you ignore the sdp in the invite, you won't get an sdp from the other endpoint at all |
| 21:26.48 | hardwire | I'm of course still trying to work that part out |
| 21:27.03 | hardwire | mostly I just want to get rid of 183 and replace it with 180 in all cases |
| 21:27.42 | hardwire | just for one system |
| 21:27.55 | kpfleming | that's completely different than the initial invite |
| 21:28.21 | hardwire | yeh.. I was working off of the myth/idea that if an sdp exists in the initial invite that a 183 is just plain going to happen later on down the orad |
| 21:28.24 | hardwire | road |
| 21:28.46 | kpfleming | and if the other endpoint sends you the SDP in a 183 response and you ignore it, again you'll have no SDP from them, unless they repeat it in the 200 OK, but they might not |
| 21:29.06 | hardwire | I'm hoping to not send them an sdp in my initial invite |
| 21:29.13 | hardwire | I can't seem to avoid that |
| 21:29.15 | kpfleming | but that has nothing to do with the 183 |
| 21:29.18 | kpfleming | the 183 comes from them |
| 21:29.26 | kpfleming | both ends have to send an SDP |
| 21:29.28 | hardwire | indeed.. because I handed them information |
| 21:29.47 | hardwire | on connect, they send an sdp if not resend it. but during ringing no sdp is needed |
| 21:30.03 | kpfleming | that doesn't make any sense at all, sorry |
| 21:30.15 | hardwire | it's ok.. |
| 21:30.48 | hardwire | asterisk is trying to handle the pre-audio on behalf of a sip client when calling a sip peer. |
| 21:31.32 | hardwire | simply put.. the sip client calls and asterisk Dials with no flags a sip peer.. I have prematureaudio and progressinband turned off |
| 21:31.37 | hardwire | alas.. it still happens |
| 21:32.01 | Corydon76-dig | kpfleming: do you have time to lambaste me over code choices? |
| 21:32.09 | kpfleming | Corydon76-dig: i have no idea :-) |
| 21:32.17 | Corydon76-dig | https://reviewboard.asterisk.org/r/876/ |
| 21:32.28 | Corydon76-dig | It relates to optional_api |
| 21:32.35 | kpfleming | ahh.. i meant to look at that this morning |
| 21:39.19 | Corydon76-dig | I've been reading up on ELF format, partly for debugging reasons... I was thinking that there might be a way for us to encode the dependencies directly into a special section |
| 21:39.43 | kpfleming | yes, there is |
| 21:39.47 | Corydon76-dig | instead of loading the code section twice |
| 21:40.01 | kpfleming | i've already commented to that effect on the review, but haven't posted it yet :-) |
| 21:41.13 | Corydon76-dig | I was mainly interested in ELF, because gdb and valgrind use the special debug info sections to correctly identify static functions within loadable modules, while the backtrace_symbols API call in glibc is unable to |
| 21:41.51 | kpfleming | yes, it would be fairly trivial to create a .o file with a section or two in it that contained mandatory and optional dependency modules |
| 21:41.58 | kpfleming | well.. not trivial, but not rocket science |
| 21:42.24 | Corydon76-dig | Fun little project, I think |
| 21:42.35 | kpfleming | i would find it fun, but i'm weird |
| 21:42.36 | Qwell | if it was rocket science, I'd say we're in the right place for it. |
| 21:42.55 | kpfleming | review published |
| 21:42.59 | Corydon76-dig | danke |
| 21:43.08 | kpfleming | no dolphins were harmed |
| 21:43.12 | file | sends anti-gravitons to kpfleming |
| 21:43.28 | Kobaz | i would also be interested in getting valgrind style backtraces into asterisk somehow |
| 21:43.47 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 21:47.01 | Corydon76-dig | Well, the libelf library is LGPL. That MAY be fine for debug only, or it may not be. If it's not, we'll have to roll our own decoder for ELF headers |
| 21:52.44 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 22:16.51 | *** join/#asterisk-dev mboehn (mathias@mboehn.alfa-skk.pr0jectX.net) |
| 22:31.17 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 23:01.10 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 23:01.10 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. |
| 23:46.08 | *** join/#asterisk-dev ahowlader (howlader@180.234.21.97) |