| 00:17.47 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-mcrbynvimntuzihf) |
| 03:31.38 | *** join/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 03:31.43 | *** part/#asterisk-dev jagruti_ (~root@182.70.116.47) |
| 05:32.40 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 05:51.44 | *** join/#asterisk-dev snuff-work (~blatus@1.148.91.15) |
| 05:51.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 06:23.29 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:23.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:43.41 | *** join/#asterisk-dev apten (~apten@b2b-46-252-133-250.unitymedia.biz) |
| 06:54.58 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 06:54.58 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:37.55 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 08:49.30 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 08:49.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:03.05 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:45.54 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 11:12.48 | stefan27 | I'm using latest 1.0.1 from fedora 20 repository openssl-1.0.1e-41.fc20.x86_64 . I have 1 or more dtls sessions created by Asterisk 13.1 and Chrome Webrtc and Firefox webrtc. The application asterisk crashes after call to dtls1_accept(). I do not understand the full process but I noticed the len variable in do_dtls1_write is MAX_INT, and the commenting code surrounding line 327 in |
| 11:12.48 | stefan27 | https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/d1_both.c says "THIS SHOULD NEVER HAPPEN". Can anyone shed some light on how this can happen? the len variable seems to be produced from "curr_mtu" im not sure how that process works. crashdump http://pastebin.com/HLxademN |
| 11:13.20 | stefan27 | Trying to figure out if the bad guy is asterisk src, openssl src, fedora packaging process or something else |
| 12:11.04 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 12:14.17 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 12:14.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:52.22 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 12:59.53 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:61c9:275d:4665:6f4c) |
| 13:14.38 | *** join/#asterisk-dev snuff-home (~brad@203-219-29-182.tpgi.com.au) |
| 13:14.38 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 13:17.35 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 13:34.56 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:39.25 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-twfiqriqbotcozoq) |
| 13:40.25 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-cjtuadkerdgifuas) |
| 13:40.55 | *** join/#asterisk-dev sgriepentrog (sgriepentr@nat/digium/x-knobigzhhtvkrvra) |
| 14:05.34 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-vqozixtbymaiybjv) |
| 14:05.52 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 14:05.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:29.50 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 14:29.50 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:39.04 | *** part/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 15:00.41 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-krbiflklsbqrhgyb) |
| 15:00.41 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:04.04 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-mtqqavjibmporywi) |
| 15:19.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ddinavccvkglmrlb) |
| 15:32.45 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-dwjbvlllavpsfvxm) |
| 15:32.45 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:44.12 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:52.15 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-npjghdufxxpdcsva) |
| 16:27.17 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-kycnegauooyryyzw) |
| 16:51.33 | mjordan | Huh: [2015-02-16 04:47:34] WARNING[6067][C-00000009] chan_pjsip.c: Unable to push answer task to the threadpool. Cannot answer call |
| 16:51.35 | mjordan | cra cra |
| 16:52.02 | mjordan | never thought I'd see that in a log :-P |
| 16:52.43 | file | mjordan, answering calls... why... would you... do... THAT |
| 16:53.45 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 16:53.49 | mjordan | Then I'd have to talk to people. Who would want to do that? |
| 16:55.38 | file | exactly |
| 17:03.56 | *** join/#asterisk-dev jgowdy (bt@hur.ruhr) |
| 17:40.33 | tm1000 | file: so quick question for you, in regards to webrtc. Iâve never had to use stunaddr until last night. Is the reasoning for this because the server is behind a natâd firewall instead of being exposed directly to the internet. Basically without that setting I am in no audio land, with it I have two way audio |
| 17:43.15 | gtjoseph | anyone know how you find the license id of someone on Jira? |
| 17:48.01 | mjordan | gtjoseph: it's kinda squirrely |
| 17:48.08 | mjordan | have they attached a file to the issue? |
| 17:48.09 | coreyfarrell | gtjoseph: click the down array on the top-right of the attachments list, click Manage Attachments. The pop-up should show you license numbers of uploaders |
| 17:48.14 | mjordan | yup, like that |
| 17:48.22 | gtjoseph | ah, let me look |
| 17:48.23 | rmudgett | gtjoseph: If they have attached a patch you can look at the attachments option pulldown menu and select the manage attatchments option. |
| 17:49.20 | gtjoseph | git it. sneaky |
| 17:49.25 | gtjoseph | got |
| 17:49.45 | gtjoseph | too bad I already did the commit. |
| 17:52.32 | jgowdy | So in looking at the pjsip usage in Asterisk, it looks like when events are processed, the tasks themselves are serialized and then queued into an alternate thread pool for actual processing. I get that design overall, but in some cases the work done to actually determine the result and send the response seems like it would be trivial. In many cases as trival as the error path which isn't queued into a thread pool thread. I'm definitely not being critical, I'm |
| 17:54.01 | mjordan | jgowdy: what case are you thinking of? |
| 17:54.11 | jgowdy | I'm just looking at register |
| 17:54.27 | mjordan | so, when we receive a REGISTER request, we have to figure out if it is for an endpoint we know of |
| 17:54.40 | mjordan | say that endpoint is not statically configured, and is not yet in memory |
| 17:54.46 | mjordan | that means traipsing off to a database |
| 17:54.58 | mjordan | if we single-threaded that, we just put the db lookup in the critical path of every other request |
| 17:55.11 | jgowdy | Do you only have one pjsip event thread running? |
| 17:55.33 | mjordan | IIRC, there is one thread that services the requests as they come out of the stack and dispatches them to the threadpool |
| 17:55.42 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 17:55.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:55.45 | mjordan | multi-threading that doesn't really buy you anything; you've just shifted the location of the threadpool |
| 17:56.28 | jgowdy | Sure, and I would guess that Asterisk would prefer its thread pool impl, although nothing stops you from using that for your multi-threaded event handling |
| 17:56.32 | file | and our threadpool is more flexible - in that it can shrink/grow |
| 17:56.42 | jgowdy | but pjsip supports multiple threads dequeuing events |
| 17:56.57 | file | we could do that in the pjsip event thread, but it would be more difficult |
| 17:57.35 | mjordan | I guess what I'm getting at is that if you "single thread" some of the message handling in the Asterisk side of things, you necessarily have to multi-thread at a lower layer to prevent that message handling from blocking the event handling |
| 17:57.46 | jgowdy | In my pjsip application, I spawn multiple threads with pj_thread_create, each of them loop on pjsip_endpt_handle_events |
| 17:57.53 | mjordan | which means you haven't really bought yourself anything: you just shift who has to serialize and/or provide the contention control |
| 17:58.08 | mjordan | jgowdy: keep in mind that all of Asterisk is not a PJSIP application |
| 17:58.23 | jgowdy | yeah, definitely understand that |
| 17:58.24 | mjordan | that means we have to define a thread boundary between what is a PJSIP registered thread, and what is not |
| 17:59.00 | jgowdy | It was just interesting to me that for example, some of the error conditions that return 4xx are in the on_rx_data function, whereas some are in rx_task |
| 17:59.23 | jgowdy | But I think where I'd draw the line is, are you authenticated enough for me to spend resources putting you in the thread pool |
| 17:59.34 | jgowdy | which is probably where the line was drawn |
| 17:59.51 | mjordan | I'd probably draw the line on "do I have to go to sorcery to look you up" |
| 17:59.57 | mjordan | because that's where things start to block |
| 18:00.24 | mjordan | you could provide more threads earlier in the stack to alleviate that, which would be an interesting experiment |
| 18:00.27 | jgowdy | yeah, at the point where you're locking on some shared collection |
| 18:00.39 | jgowdy | or going to an external data source |
| 18:00.55 | mjordan | any time you see a call into ast_sorcery to get an object, that's a potential point where that happens |
| 18:01.08 | mjordan | it may not, if we've already extracted it, but there is a chance it can |
| 18:01.40 | mjordan | jgowdy: have you profiled Asterisk and noticed that as being a bottleneck/ |
| 18:01.42 | mjordan | ? |
| 18:01.57 | jgowdy | Oh not at all, I'm just trying to understand the code |
| 18:02.14 | jgowdy | As I said, definitely not being critical |
| 18:02.38 | jgowdy | Asterisk now provides one of the best sources of a sample pjsip consumer for server scenarios |
| 18:03.37 | jgowdy | So I'm literally reading the Asterisk pjsip code to compare and improve my own pjsip development, which would also help me if I were to contribute to Asterisk in the same realm |
| 18:05.40 | mjordan | heh |
| 18:05.42 | mjordan | thanks! |
| 18:05.50 | mjordan | (or more realistically, file & putnopvut) |
| 18:06.05 | file | I did nothing. |
| 18:06.18 | mjordan | jgowdy: I will say that parts of the stack were constrained but what we were referring to, i.e., that we had to provide a hard thread boundary between "this is Asterisk" and "this is PJSIP" |
| 18:06.46 | mjordan | you'll see in chan_pjsip in particular there are places where we explicitly marshal calls between the thread boundaries to prevent cross-contamination |
| 18:07.30 | jgowdy | I do have some ideas for different ways to blend it that I might try on a branch and profile as you suggest |
| 18:08.05 | jgowdy | maybe the sip monitor thread is just a long lived Asterisk pool thread rather than being standalone (just register it), maybe spin up a couple from the Asterisk pool |
| 18:08.54 | jgowdy | probably not hugely relevant, since you're probably not moving 50mbit of signaling traffic ;) |
| 18:12.20 | jgowdy | oh it's already it's own asterisk thread pool, just a different one only for sip. cool |
| 18:13.17 | jgowdy | oh that's for the offload |
| 18:16.22 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:16.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:17.46 | mjordan | yeah |
| 18:17.54 | mjordan | the monitor thread, IIRC, is just its own little beasty |
| 18:18.21 | mjordan | that sits there, sucks things out from PJSIP, and dispatches it off to the Asterisk thread pool for the PJSIP stack (which is a thread pool only for servicing PJSIP messages) |
| 18:19.23 | file | correct - optionally serializing it if it needs to be |
| 18:24.58 | oej | How embarrassing with the Max-Forwards header missing... |
| 18:25.13 | oej | Life. |
| 18:58.31 | pabelanger | Damn Matt Riddell and his auto dialers |
| 18:58.40 | pabelanger | always know it is his |
| 18:58.43 | pabelanger | press 9 |
| 18:58.51 | pabelanger | call hangs up |
| 19:08.45 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 19:43.25 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:43.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:50.25 | *** join/#asterisk-dev kharwell (~kharwell@24.96.171.3) |
| 19:51.43 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 19:51.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:08.09 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 20:11.00 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-smwehlkfrljphsnt) |
| 20:13.04 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 20:13.04 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 20:20.39 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 20:20.39 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 20:20.53 | seanbright | is there any way to distinguish the original INVITE from a retransmitted INVITE? |
| 20:21.46 | file | where... |
| 20:22.11 | seanbright | in the SIP headers |
| 20:22.21 | file | no |
| 20:22.24 | seanbright | ok |
| 20:22.30 | seanbright | thank you |
| 20:27.00 | seanbright | does chan_sip adjust the T1 timer based on qualify times? |
| 20:28.17 | mjordan | yes |
| 20:28.33 | mjordan | line 6000 in Asterisk 13's chan_sip |
| 20:28.49 | seanbright | ok. well that explains my pcaps. |
| 20:36.25 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:36.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:09.11 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 21:09.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:10.55 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-jlkehiiijankugib) |
| 21:10.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:29.02 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 21:29.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 21:46.19 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:00.47 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:37.06 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:43.34 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |
| 22:45.37 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 22:45.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 23:14.07 | *** join/#asterisk-dev newtonr (~RustyNewt@173-21-90-203.client.mchsi.com) |
| 23:14.07 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 23:30.15 | *** join/#asterisk-dev superscrat (~asanders@173-17-133-2.client.mchsi.com) |