| 00:07.55 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 00:07.55 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 02:21.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:21.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 03:37.01 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 05:37.05 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 06:37.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.67) |
| 07:54.09 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:480d:f273:8651:da46) |
| 11:18.26 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:40.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:40.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:51.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@87.117.139.75) |
| 13:09.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.207.91.72) |
| 13:21.31 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:48.18 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zdfmjrkjgubfjoci) |
| 13:48.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.207.91.72) |
| 14:01.23 | *** join/#asterisk-dev vlad_starkov (~vlad_star@89.207.91.72) |
| 14:11.07 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:11.07 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:30.59 | Kobaz | good morning fair asteriskers |
| 14:36.23 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-xhiisxpqozxlaqda) |
| 14:41.08 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:41.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:10.41 | *** join/#asterisk-dev Izzyg (~Izzy@static-98-113-96-227.nycmny.fios.verizon.net) |
| 15:55.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:55.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:12.17 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 17:06.43 | *** join/#asterisk-dev psanders (~psanders@184.2.115.125) |
| 17:09.21 | *** join/#asterisk-dev mjordan1 (~mjordan@nat/digium/x-iiesnqmzpqxbtcsh) |
| 17:09.22 | *** mode/#asterisk-dev [+o mjordan1] by ChanServ |
| 17:48.20 | putnopvut | Attention all: I am about to pull the trigger on the massive GULP->PJSIP renaming. |
| 17:48.55 | seanbright | god speed |
| 17:50.09 | leifmadsen | important work you're doing there |
| 17:50.26 | pabelanger | leifmadsen: I lol'd |
| 17:50.32 | leifmadsen | pabelanger: :) |
| 17:50.45 | putnopvut | Yep, exactly how I wanted to spend 3 hours. |
| 17:51.00 | leifmadsen | putnopvut: ya, I'm trolling "the community", not you in case it wasn't clear |
| 17:51.07 | putnopvut | Yeah, I figured :) |
| 17:51.08 | pabelanger | putnopvut: There is a beer with your name on it in ATL |
| 17:51.09 | leifmadsen | heh |
| 17:51.14 | seanbright | how dare you quote us |
| 17:51.14 | leifmadsen | drinks that beer |
| 17:51.17 | seanbright | "leif" |
| 17:51.29 | seanbright | you're part of the community |
| 17:51.30 | seanbright | for now... |
| 17:51.42 | file | I try not to think of... time... used... for certain things |
| 17:52.04 | Qwell | pabelanger: It'll be stale by the time he gets there. |
| 17:52.17 | Qwell | can beer get stale? whatever happens to 3 month old beer. |
| 17:53.02 | opticron | so I have a channel that I've told to depart a bridge and I'm having trouble finding a way to poke it so the bridge_channel thread wakes up |
| 17:53.53 | pabelanger | Qwell: it goes moldy. Lets some in the DJ booth for a week, not a pretty sight |
| 17:56.19 | file | putnopvut, you got the memo that it's being called joe now, right? |
| 17:56.41 | putnopvut | Yep! |
| 17:56.47 | file | good! just checking |
| 17:56.56 | file | opticron, how are you departing it? |
| 17:57.46 | WIMPy | The memo about TPS repots? |
| 17:57.55 | opticron | ast_bridge_depart(channel) |
| 17:58.35 | opticron | I probably need to add some debugging to figure out exactly what's going on, it looks like it's eventually waking up, but just taking a long time |
| 17:59.20 | file | interestin' |
| 18:00.16 | putnopvut | crap. I think I've confused subversion. |
| 18:00.51 | opticron | putnopvut, it's not hard |
| 18:01.43 | putnopvut | http://ur1.ca/etu5v |
| 18:02.11 | Qwell | How did res_pjsip come into existence? |
| 18:02.13 | putnopvut | I don't understand a "path not found" error for something I'm trying to add. |
| 18:02.15 | Qwell | svn mv? |
| 18:02.23 | putnopvut | I svn mv'ed res/res_sip to res/res_pjsip |
| 18:02.51 | putnopvut | Obviously it's new. Of course you can't find the path. I'm adding it. |
| 18:02.52 | Qwell | Can this be redone easily, if a revert needs to happen? |
| 18:02.58 | Qwell | (it shouldn't need to happen) |
| 18:03.00 | putnopvut | No. No it cannot. |
| 18:03.09 | putnopvut | I'm not fucking reverting this. |
| 18:03.21 | seanbright | step 1. backup your WC. |
| 18:03.46 | seanbright | i don't have a step 2 |
| 18:04.39 | opticron | huh, I thought it was chan_gulp -> chan_pjsip |
| 18:04.46 | opticron | not the res_sip stuff |
| 18:04.51 | putnopvut | opticron: lot more to it than that. |
| 18:05.05 | Qwell | putnopvut: Can you make a copy of the working directory, and try to svn up that? |
| 18:05.23 | putnopvut | Just cp it to another location? |
| 18:05.28 | Qwell | yeah |
| 18:05.52 | Qwell | If it works, even if there are no changes - try to commit. |
| 18:07.01 | putnopvut | waits for the copy to complete |
| 18:07.57 | putnopvut | Nope, same thing there. |
| 18:08.49 | Kobaz | do de do |
| 18:12.32 | putnopvut | I may have this figured out. |
| 18:26.25 | Kobaz | allrightey |
| 18:26.26 | Kobaz | soo |
| 18:26.46 | Kobaz | say i have a module, that may or may not be loaded |
| 18:26.56 | Kobaz | and there's some part of core that may need to call that module, if it's loaded |
| 18:27.26 | Kobaz | so for example, somewhere in app.c i need to call a function in func_groupcount.c but only if func_groupcount is loaded |
| 18:28.33 | seanbright | i think you're looking for optional_api |
| 18:28.38 | seanbright | but it's been a while |
| 18:28.38 | Kobaz | k |
| 18:28.56 | file | ugh |
| 18:31.51 | opticron | virtual function table |
| 18:32.31 | seanbright | i'm not thrilled with the idea of something in the core relying on a module being loaded either |
| 18:32.54 | Kobaz | well i'm making group variables entirely self-contained in func_groupcount |
| 18:33.08 | Kobaz | to avoid direct public exposure of a linked list |
| 18:33.16 | Kobaz | might as well make it all in one module anyway |
| 18:33.37 | Kobaz | theres the ast_app_group_discard which gets called on hangup |
| 18:33.51 | Kobaz | actually this would be a good reason to post up my internal channel hangup handlers patch |
| 18:34.10 | seanbright | weren't hangup handlers already implemented? |
| 18:34.34 | Kobaz | yeah |
| 18:34.37 | Kobaz | but that's public hangup handlers |
| 18:34.42 | Kobaz | dialplan |
| 18:34.43 | seanbright | ah |
| 18:34.52 | Kobaz | not internal hangup handlers in the c code |
| 18:35.06 | mjordan1 | FYI: core shouldn't depend on a module |
| 18:35.12 | seanbright | yeah |
| 18:35.20 | Kobaz | yeah that does make sence |
| 18:35.23 | Kobaz | sense |
| 18:36.12 | Kobaz | what's the odds i can get this stuff into 12 |
| 18:36.21 | seanbright | you have until tomorrow |
| 18:36.25 | Kobaz | hah yeah |
| 18:36.35 | Kobaz | i know |
| 18:37.06 | seanbright | i'm almost done with my chan_sofiasip patch. hoping to land that later today. |
| 18:37.31 | Kobaz | cool |
| 18:37.36 | seanbright | (i'm kidding) |
| 18:38.04 | Kobaz | oh |
| 18:38.20 | file | and... the last thing I wanted for 12 is now up for review |
| 18:38.24 | seanbright | i don't contribute any more. i just sit here with ops and inject snarky commentary when required. |
| 18:39.05 | Kobaz | so really, if i get in the internal callback hangups, the dialplan hanguphandlers should use that internally |
| 18:39.32 | seanbright | hmm |
| 18:43.57 | file | Timbits for all! |
| 18:46.34 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:46.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.113) |
| 18:49.27 | mjordan1 | file: exciting :-) |
| 18:49.44 | seanbright | yeah, URIs are sweet |
| 18:51.32 | Kobaz | so |
| 18:51.48 | Kobaz | internal hangup callbacks will allow for func_group to get rid of it's stuff from app.c |
| 18:51.57 | Kobaz | and remove the dependency on the module in channel destroy |
| 18:56.09 | Qwell | putnopvut: res_pjsip_endpoint_identifier_constant isn't compiling for me |
| 18:56.19 | Qwell | I think it might've been missed in the endpoint restructure. |
| 19:00.01 | *** join/#asterisk-dev jkroon (~jkroon@41.13.80.205) |
| 19:01.45 | jkroon | hi guys, not sure if anybody has been following my rampage in #asterisk, igcwielding suggested I rather move the discussion here. I'm trying to understand why sip REGISTER packets takes so much (200x) longer than other SIP packets to process, and then, if there is anything I can do to improve the situation. |
| 19:02.12 | jkroon | a few suggestions has been made with respect to possible causes, including astdb, but seemingly REGISTER packets just require much more processing. |
| 19:06.57 | putnopvut | Qwell: It likely was |
| 19:07.27 | putnopvut | The question becomes: fix or just remove? <- file? |
| 19:07.40 | file | fix |
| 19:07.43 | file | don't remove :P |
| 19:07.54 | putnopvut | Okay then. |
| 19:07.59 | file | actually I lied |
| 19:08.07 | putnopvut | lol |
| 19:08.10 | jkroon | from some rudementary timing analysis it takes <1ms to process non-register packets (often <100us) whereas REGISTER packets almost without exception seem to take >100ms. |
| 19:09.54 | putnopvut | I'll start by fixing. It's probably not much to have to change. It can be removed later. |
| 19:10.39 | putnopvut | Qwell: try rev 395779 |
| 19:11.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.113) |
| 19:11.44 | putnopvut | jkroon: I have no concrete evidence of anything, but the astdb argument is the one that makes the most sense to me. None of the other types of SIP requests require disk i/o. REGISTER does. That's the most fundamental difference. If you run a profiler, it can show where the most CPU time is spent. |
| 19:12.37 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:12.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:18.32 | jkroon | putnopvut, suggestions on profilers? |
| 19:18.54 | jkroon | and would waiting for disk IO register as CPU in such a profiler? |
| 19:19.34 | jkroon | the other suggestion has been to try and offload the SIP processing to a SIP proxy - which I guess would make a lot of the REGISTER work go away? |
| 19:20.11 | file | that depends on how you deploy things, if you move registrations to the SIP proxy then of course REGISTERs wouldn't go to Asterisk |
| 19:22.10 | jkroon | file, ok, let me rephrase - where can I find documentation on such a setup, and does it make sense to do that? Is there a proxy out there that can be recommended? |
| 19:22.47 | file | I don't know any links off hand, and it depends on the deployment |
| 19:23.27 | file | and doing so may just be moving the problem elsewhere or hiding it |
| 19:23.56 | jkroon | at this stage hiding it may well be acceptable. |
| 20:02.58 | jkroon | but not feasible on what I've just read, at least, not in any kind of short (couple of days) time frame. |
| 20:18.38 | jkroon | putnopvut, how about this for a consideration - how easy would it be to queue REGISTER requests to a different thread, to be handled "out of band" from the normal requests? |
| 20:37.41 | *** join/#asterisk-dev eZz (~ez@194.28.91.17) |
| 20:37.48 | eZz | hello |
| 20:38.26 | eZz | is there a way to simple itterate over a channels (even with state != STATE_UP) in custom module in thread? |
| 20:44.08 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.83) |
| 20:46.47 | mjordan1 | eZz: yes. You can get an ao2 iterator to the channels container using ast_channel_iterator_all_new, and traverse it using ast_channel_iterator_next |
| 20:47.08 | mjordan1 | since they're ao2 objects, you'll need to understand ao2 object reference counting |
| 20:47.28 | eZz | mjordan1: ok thank you for pointing |
| 20:47.45 | mjordan1 | eZz: take a look at handle_chanlist in cli.c in Asterisk 11 |
| 20:48.06 | eZz | what about to 1.8 ? |
| 20:48.12 | mjordan1 | eZz: depending on your use case, there are better ways to do it in trunk |
| 20:48.16 | mjordan1 | Asterisk 1.8 would be similar |
| 20:48.18 | mjordan1 | and has the same function |
| 20:48.38 | eZz | ok |
| 20:49.14 | eZz | basically I need to hook the channel before dial() and mix the frames of any early media with application's channel |
| 20:49.32 | mjordan1 | well. |
| 20:49.33 | eZz | or whatever way to hear a call disposition when Dial()'ing |
| 20:49.36 | mjordan1 | That won't do what you want |
| 20:49.51 | mjordan1 | Well. It could |
| 20:50.02 | mjordan1 | but you're iterating over every channel in the system when you do that, not every channel that is dialing |
| 20:50.11 | eZz | yeah |
| 20:50.13 | mjordan1 | which means it's an expensive operation and giving you a lot more channels then you want |
| 20:50.30 | mjordan1 | so that's not the right approach. |
| 20:50.46 | mjordan1 | if you mix all of the early media, you know you're going to get multiple MoH streams |
| 20:50.49 | eZz | I tried to establish a call inside my app but it's the same as re-use app_dial.c |
| 20:51.26 | mjordan1 | Not our MoH streams mind you, but the remote end sending entertainment early media will end up getting mixed with another end's entertainment, resulting in garbage |
| 20:51.47 | mjordan1 | or are you only doing this with a single dial, and not a parallel dial? |
| 20:51.59 | eZz | no, a sequental dial |
| 20:52.29 | eZz | so it should be only one dial, like a sequental connect a client to conference |
| 20:52.30 | mjordan1 | I'm missing why the existing early bridge isn't sufficient then |
| 20:53.38 | eZz | I just stucked on this problem and can't understand where to look for ツ |
| 20:53.48 | mjordan1 | take a look at the calls to ast_channel_early_bridge in app_dial. That is supposed to create an early bridge between the two channels |
| 20:54.03 | file | that's for early native bridging |
| 20:54.19 | file | to "bridge" early app_dial forwards media frames if only dialing one channel outbound |
| 20:54.21 | mjordan1 | ah, true. I keep thinking "SIP" |
| 20:54.22 | eZz | yes but to do it, need to find the dialing channel first, right ? |
| 20:54.51 | mjordan1 | eZz: the dialing channel is the channel in app_dial. The outbound channel(s) are created at that time. |
| 20:55.04 | mjordan1 | so you have both the dialing channel and the set of dialed channels |
| 20:57.02 | eZz | my idea is: 1) generate some id and exec some app (like HookChan(id)), 2) set some variable with this id, 3) then iterate over a channels and fetch this variable, if matched - it is a correct channel |
| 20:57.10 | eZz | I'm thinking wrong way? |
| 20:57.12 | mjordan1 | there's no need to do that however |
| 20:57.23 | mjordan1 | eZz: what file said. app_dial already 'mixes' the media by forwarding the early media from the outbound channel to the calling channel. |
| 20:57.53 | mjordan1 | If you look for the handling of the VOICE frames in app_dial, you'll see the part where the frame ends up falling through to an ast_write that sends the frame to the inbound channel |
| 20:57.56 | eZz | the problem is that originating channel is already bridged to another application |
| 20:58.09 | mjordan1 | eZz: use a Local channel |
| 20:58.37 | mjordan1 | A non-Local channel can't be both in a bridge and performing a DIal at the same time |
| 21:00.27 | eZz | hm. I can't still understand how the local channel can help me in this channel because as I said, an originator of dial() is already bridged to application and app held him inside |
| 21:01.16 | mjordan1 | eZz: what channel technology are you currently using |
| 21:01.25 | eZz | the only one way to execute dial() (I mean through c-api) inside app |
| 21:01.25 | eZz | mjordan1: SIP |
| 21:01.36 | mjordan1 | k, so you have a SIP channel in a bridge with something else, right? |
| 21:01.45 | eZz | yes |
| 21:02.00 | mjordan1 | and you want to dial someone else and have them be brought into the bridge? |
| 21:02.09 | eZz | are you familiar with meetme/app_conference/appkonference? |
| 21:02.15 | mjordan1 | yes. |
| 21:02.28 | eZz | this app is close to this conf core |
| 21:02.46 | mjordan1 | k. So you've written your own conferencing core? |
| 21:02.51 | eZz | yes |
| 21:03.00 | eZz | I did it already |
| 21:03.13 | eZz | but stucks on early media |
| 21:03.49 | mjordan1 | not knowing your conference core, I can't help you. All dialing does is receive frames from the outbound channel when that channel has a frame. What you do with it is up to you |
| 21:04.35 | eZz | yes I understand this part |
| 21:05.10 | eZz | but until the next member is out of conf - this app will not receive any frame |
| 21:05.24 | eZz | but he will be at conf only when answer |
| 21:05.29 | *** join/#asterisk-dev psanders (~psanders@74.204.136.78) |
| 21:05.34 | eZz | and hence will be a frames ツ |
| 21:06.24 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:06.29 | mjordan1 | Are you reading the frames from your outbound channel? |
| 21:06.40 | eZz | yes |
| 21:06.49 | eZz | outbound and inbound both |
| 21:07.16 | eZz | so to lead to a common denominator need to either dial from app or hook a channel before dial() and catch inside app with a loop I think |
| 21:07.42 | mjordan1 | or do neither. What you've described is perfectly doable using dialplan and ConfBridge. |
| 21:08.25 | mjordan1 | ConfBridge <-> L;1 <-> L;2 (Dial) <--> SIP/foo |
| 21:08.40 | eZz | hm |
| 21:09.44 | eZz | so are you propose to bridge a member before entrance to conf with the new member before dial() ? |
| 21:10.32 | eZz | anyways, I will look at this all, thanks guys! :-) |
| 21:58.35 | *** part/#asterisk-dev mjordan1 (~mjordan@nat/digium/x-iiesnqmzpqxbtcsh) |
| 22:39.39 | *** join/#asterisk-dev John1001 (~John1001@82-169-149-142.ip.telfort.nl) |
| 22:39.59 | John1001 | Hello developers , may i ask a question here in "local" please ... |
| 22:40.58 | WIMPy | "local"? |
| 22:41.12 | John1001 | yes the general chatroom |
| 22:41.22 | John1001 | i dont know how to say it otherwise :-) |
| 22:58.56 | *** part/#asterisk-dev John1001 (~John1001@82-169-149-142.ip.telfort.nl) |