| 00:00.54 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:00.54 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:30.26 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 01:26.27 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 01:39.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hvdafkuitwaamacl) |
| 01:39.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 01:51.47 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:52.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.247) |
| 02:06.47 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 02:13.41 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 02:28.32 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 02:52.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.195) |
| 03:00.57 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 03:17.48 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 03:43.47 | *** join/#asterisk-dev rogersja (~rogersja@S0106c03f0ed65cc5.wp.shawcable.net) |
| 03:58.13 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 04:08.29 | *** part/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 04:16.48 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 04:16.48 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 05:05.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:05.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:05.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.168) |
| 06:39.29 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 06:53.45 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:21.00 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.26) |
| 08:58.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.26) |
| 09:50.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.73.235.150) |
| 09:55.14 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:55.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:58.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.73.235.150) |
| 10:46.28 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:16.56 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 11:16.56 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 12:00.19 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:14.19 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 12:18.33 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 13:09.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.73.235.150) |
| 13:30.02 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uxfqjswvrdmrvqdj) |
| 13:30.02 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:02.27 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:09.43 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:41fc:3604:29c2:8670) |
| 14:14.15 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:20.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xjejfbvbcllcnace) |
| 14:21.32 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:21.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:22.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:22.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:35.45 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-coufepwfskmtktzp) |
| 14:41.16 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-wlbrxhoujqdxzuzf) |
| 14:42.35 | putnopvut | file: So, in all seriousness, I'm considering removing res_pjsip_endpoint_identifier_constant.c from the source. If you actually try to use it, GODAWFUL things happen. |
| 14:42.44 | file | go for it |
| 14:42.49 | putnopvut | Okay, cool. |
| 14:51.45 | pabelanger | sounds like a ton more res_* modules are added now |
| 14:53.33 | putnopvut | pabelanger: yeah, in comparison to Asterisk 11, there are a bunch. That's because the majority of the new SIP stuff is in small res_ modules |
| 14:54.00 | pabelanger | interesting |
| 14:54.07 | putnopvut | And then ARI uses res_ modules as well, I suppose. |
| 14:54.37 | file | oui |
| 14:55.21 | WIMPy | I've been trying to find out why Dial() has quite a dely before sending calls out and in the debug I see dialplan lookups. Can someone explain what's going on there? |
| 14:56.45 | mjordan | WIMPy: what particular part of app_dial? |
| 14:56.55 | Kobaz | i like small modules |
| 14:57.02 | pabelanger | WIMPy: Resolving DNS? |
| 14:57.23 | Kobaz | 30,000 line modules not so fun |
| 14:57.51 | putnopvut | Kobaz: indeed |
| 14:58.13 | Kobaz | eyes chan_sip |
| 14:58.40 | WIMPy | mjordan: I have no idea what's going on. Could it be looking for some gosub that's defined via channel variables or something? |
| 14:59.07 | WIMPy | It's looking for "",1, but in a context I'm not sure of how it's related to the call. |
| 14:59.08 | putnopvut | Kobaz: largest one at the moment is res_pjsip_session, which is 2132 lines. Second largest is res_pjsip.c at 1900 lines, although that one also has a lot of XML docs in it. |
| 14:59.14 | WIMPy | pabelanger: DNS? |
| 14:59.59 | Kobaz | cool |
| 15:00.14 | Kobaz | sooo |
| 15:00.16 | WIMPy | It happens after I see the newchannel event, but seems to happen before any generated channel is actually used. |
| 15:00.23 | Kobaz | being that there's this whole sip redo that I don't know much about |
| 15:00.27 | pabelanger | WIMPy: not sure if you are dialing a SIP URI or something |
| 15:00.30 | pabelanger | but know more now |
| 15:00.32 | pabelanger | :) |
| 15:00.35 | Kobaz | is sip going to be a lot more controllable |
| 15:00.45 | Kobaz | like you can do fancy stuff based on username/ip/etc/etc |
| 15:00.54 | Kobaz | and not be limited to predefined peer matching rules |
| 15:01.07 | WIMPy | pabelanger: Ah, no. Only dynamic SIP accounts and hardware. |
| 15:01.48 | WIMPy | But the real phones are delayed just as well. |
| 15:04.02 | WIMPy | Unfortunately without good timing indication, but here's the debug http://wimpy.yeti.dk/pastebin |
| 15:04.38 | file | Kobaz, that's modular so you can write one to do whatever the heck you want |
| 15:04.49 | Kobaz | cool |
| 15:04.50 | Kobaz | very cool |
| 15:04.51 | file | match on a SIP header from a proxy, if you want |
| 15:04.57 | Kobaz | yaaaay |
| 15:05.01 | WIMPy | Dial starts at line 174 |
| 15:05.04 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-epkxmrtrppxrnaim) |
| 15:05.49 | Kobaz | none of this match_auth_username, or insecure=port,invite shenanagins |
| 15:07.46 | WIMPy | So you can see there are dundi lookups going on as a result of a dialplan lookup, which explains the observed delay. But where does the dialplan lookup come from? |
| 15:13.25 | *** join/#asterisk-dev eZz (~ez@194.28.91.17) |
| 15:13.44 | *** part/#asterisk-dev eZz (~ez@194.28.91.17) |
| 15:13.48 | *** join/#asterisk-dev eZz (~ez@194.28.91.17) |
| 15:20.29 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-50-4.user.veloxzone.com.br) |
| 15:25.50 | putnopvut | mjordan: as I suspected, some of the external parking changes you made will invalidate my ast_bridged_channel() changes. And that's a *good* thing :) |
| 15:26.04 | mjordan | yay! |
| 15:26.44 | Kobaz | cool |
| 15:27.25 | putnopvut | Kobaz: important thing to remember is that today's feature freeze applies strictly to getting things up on reviewboard. They don't have to be committed by the end of the day. |
| 15:27.44 | Kobaz | oooooh |
| 15:27.50 | Kobaz | here i am panicing since i wanted too long |
| 15:27.55 | Kobaz | waited |
| 15:28.01 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:28.04 | file | let that be a lesson to get stuff in earlier, then :P |
| 15:28.05 | Kobaz | i mean like, i did all the code changes all a while ago |
| 15:28.13 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:28.16 | Kobaz | but looked at the date and went oh crap |
| 15:28.32 | file | did you have it up to date on the review? |
| 15:28.41 | Kobaz | yeah it is as of this week |
| 15:28.47 | eZz | mjordan: hi, thanks for helping with channels yesterday |
| 15:28.54 | mjordan | WIMPy: not entirely sure. It is occurring between the requesting of the channels and the actual dialing. I'd suspect that something is attempting to get device state however, possibly by querying AST_OPTION_DEVICE_NAME |
| 15:29.00 | mjordan | eZz: np, hope it was helpful |
| 15:29.07 | eZz | mjordan: I'm almost close to finish, I got the channels using ast_channel_iterator_all_new and ast_channel_iterator_next |
| 15:29.16 | eZz | all is fine |
| 15:29.27 | Kobaz | all we need now is ast_channel_iterator_all_new_real2 |
| 15:29.32 | Kobaz | mysql style |
| 15:30.02 | Kobaz | channel iterators are so awesome |
| 15:30.05 | mjordan | uhm |
| 15:30.09 | mjordan | Kobaz: no :-P |
| 15:30.11 | file | no. |
| 15:30.37 | Kobaz | it was a joke, heh |
| 15:30.46 | file | channel iterators are not something to joke about! |
| 15:30.53 | Kobaz | but i do like them |
| 15:31.07 | putnopvut | I like hot wings |
| 15:33.42 | WIMPy | mjordan: Device state as in a hint? But that should have priority set to -1, shouldn't it? |
| 15:42.28 | mjordan | WIMPy: It was my best guess. There's only one thing that should execute dialplan at that time, which is a pre-dial handler, but you didn't have that in your dial and didn't actually *see* the dialplan execute |
| 15:42.57 | WIMPy | No, I don't use them. |
| 15:42.59 | mjordan | WIMPy: The only other thing that I can think of that actually does go out to dialplan and interact with the dialplan at some level is device state, some of which is interacted with during that time period |
| 15:43.08 | WIMPy | And there is no match in the dialplan. |
| 15:43.14 | mjordan | Now, chan_sip doesn't do anything along that path |
| 15:43.18 | mjordan | I don't know about chan_lcr |
| 15:43.32 | mjordan | It depends on what it does with that channel technology query option |
| 15:43.36 | WIMPy | lcr doesn;t support device state. |
| 15:43.46 | mjordan | that's fine, this is a more generic thing |
| 15:43.55 | mjordan | if it does a pbx extension look up as a result of a query option, that would make some sense |
| 15:44.18 | WIMPy | For a received call? |
| 15:44.32 | mjordan | Doesn't really matter received versus non-received. |
| 15:44.43 | mjordan | there's a channel technology option callback called query_option |
| 15:44.49 | mjordan | it is called during this time period |
| 15:44.59 | WIMPy | But it only forwards the calls between applications. |
| 15:45.25 | WIMPy | Let's see if that exists. |
| 15:45.51 | mjordan | easy way to test: remove LCR from your dial string |
| 15:46.01 | WIMPy | Nope. Doesn't exist. |
| 15:46.25 | WIMPy | Yes, I can try to reduce it further. |
| 15:47.44 | file | build, build, build |
| 15:52.59 | WIMPy | I still see the lookups without dialling lcr. |
| 15:55.20 | WIMPy | But they are gone when I remove the sip channels. |
| 15:56.32 | WIMPy | Ringing after 5ms instead of some 700ms. |
| 16:03.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.66.67) |
| 16:09.36 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-jbcsphuefjafbdrc) |
| 16:26.39 | file | yayyyy multiple codecs in my answer |
| 16:36.26 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-pjszofdqmyxwpylj) |
| 16:40.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:40.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:47.26 | WIMPy | So does anyone have an idea what chan_sip is doing there? |
| 16:47.36 | WIMPy | Or rather how I can prevent it from doing so? |
| 16:48.14 | pabelanger | WIMPy: what version of asterisk? |
| 16:48.24 | WIMPy | TRUNK |
| 16:48.35 | pabelanger | Ah |
| 16:49.54 | pabelanger | I'd be real curious to see performance metrics between 12 and previous versions (11, 1.8). See how the new code holds up |
| 16:50.43 | pabelanger | too bad https://wiki.asterisk.org/wiki/display/~pabelanger/Project+L never came to light |
| 16:51.25 | file | I don't expect raw simultaneous to differ that much, but calls per second... I would expect a change |
| 16:51.49 | WIMPy | Does that ah mean that it was more than just a feeling that I had less delay inthe past? |
| 16:53.56 | pabelanger | WIMPy: no, I missed the discussions because of my crappy network. So, didn't know which branch you were on. Seeing since this is trunk, you might be the first to see the issue |
| 16:54.10 | pabelanger | not sure how many people are playing with it |
| 17:01.03 | Kobaz | pabelanger: woah interesting |
| 17:03.09 | mjordan | WIMPy: are you using the register context option in chan_sip? |
| 17:03.31 | pabelanger | Kobaz: https://wiki.asterisk.org/wiki/display/~pabelanger/Load+testing+notes give notes of the discussion we had |
| 17:03.45 | WIMPy | mjordan: Yes. |
| 17:03.53 | mjordan | that might be your culprit |
| 17:04.09 | mjordan | register context causes a dialplan look up to add an extension for the peer |
| 17:04.39 | WIMPy | Err. What does Dial have to do with that? |
| 17:04.58 | mjordan | I am reaching a little bit, and I have about 30 seconds to put together a guess |
| 17:05.16 | mjordan | but when you do an outbound dial, you have to look up in the SIP/Registry to see if what you're dialing is a peer |
| 17:05.23 | mjordan | that can cause a register_peer_exten to get called |
| 17:05.53 | mjordan | it's more of a side effect than anything else, and wouldn't be unique to trunk |
| 17:06.13 | mjordan | you could try removing that option and see if it stops it; otherwise, I'm unfortunately out of time to dig through chan_sip right now :-) |
| 17:06.33 | WIMPy | So it is new, but because I enabled registercontext when I moved stuff over to a new server. |
| 17:07.07 | WIMPy | I think I don;t need it any more. Will try to remove it. |
| 17:14.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.66.67) |
| 17:23.29 | WIMPy | I disabled regcontext. Still have the delay, but maybe a 'sip reload' isn;'t enough for that? |
| 17:26.47 | WIMPy | Over 1200ms this time :-( |
| 17:27.13 | pabelanger | WIMPy: what does your dial syntax look like? |
| 17:27.40 | WIMPy | YOu can look at the old debug at http://wimpy.yeti.dk/pastebin |
| 17:27.55 | WIMPy | Line 174 is the dial |
| 17:28.30 | WIMPy | Removing lcr makes no difference, removing the sip channels and the delay is down to 5 ms. |
| 17:31.42 | WIMPy | ok. it IS a regression. I just downgraded to 389343 which I still had lying around and the delay is gone. |
| 17:33.54 | WIMPy | fsck |
| 17:34.22 | WIMPy | The debug looks the same. There's som dialplan lookup going on there as well. |
| 17:35.08 | WIMPy | The dialplan doing senseless lookups seemed to bee a good explanation for the delay. |
| 17:41.04 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:41.04 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 18:08.18 | WIMPy | hastes svn |
| 18:10.57 | WIMPy | No matter if I start from the current or the old version. I don't get anything in between to compile. Not even the revision I used before. |
| 18:10.57 | WIMPy | blows a cloud of steam out of his ears. |
| 18:18.29 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-88-71.hsd1.mi.comcast.net) |
| 18:18.39 | *** join/#asterisk-dev coreyf1513 (~cfarrell@24-177-3-55.dhcp.nwtn.ct.charter.com) |
| 18:36.27 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 18:54.50 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:40.45 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 19:46.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@194.154.66.67) |
| 19:52.34 | putnopvut | leedm777: Is 15 April, 1992 a special date to you? |
| 19:53.17 | leedm777 | putnopvut: About a month before graduating high school... |
| 19:53.31 | putnopvut | Just curious since your JSON_MAGIC is 0x1541992 |
| 19:53.41 | leedm777 | ah. |
| 19:53.45 | Qwell | putnopvut: That was the last day that people could submit tax forms before the LA riots. |
| 19:53.49 | Qwell | big day |
| 19:54.01 | putnopvut | Yeah, had to get them in before the 26th |
| 19:54.15 | leedm777 | nope; it's just a random number. |
| 19:54.23 | putnopvut | Actually Sublime is really confusing with the date. |
| 19:54.31 | putnopvut | They say 26th in the song, but the title says 29th. |
| 19:55.31 | Qwell | putnopvut: The lyric is incorrect |
| 19:56.18 | putnopvut | Ah. Weird that they wouldn't re-take. |
| 19:56.28 | Qwell | shrugs |
| 20:17.45 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 20:52.20 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 21:07.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 21:20.29 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:59.30 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 21:59.30 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:06.27 | *** join/#asterisk-dev italoros_ (~italoross@187.60.66.11) |
| 22:06.45 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 22:14.32 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 22:22.23 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 22:23.34 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 22:44.05 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.204) |
| 23:35.02 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 23:35.02 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |