| 00:34.08 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 01:06.19 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-fgnulrrttjchtcoe) |
| 03:51.21 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 06:17.22 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.164) |
| 06:23.47 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:23.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:33.41 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:e0a4:d0ca:b545:ca19) |
| 06:41.18 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:06.46 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:306d:bcc7:9472:9b97) |
| 07:08.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:09.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:31.21 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 08:07.52 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:07.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:41.49 | *** join/#asterisk-dev t4nk707 (b807ef82@gateway/web/freenode/ip.184.7.239.130) |
| 09:07.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 09:07.04 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:07.07 | oej | Hello folks |
| 09:12.25 | skrusty | morning |
| 11:28.32 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-xhjlpcyvyzytjotq) |
| 12:03.42 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:15.21 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:17.28 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 12:23.17 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:56.51 | *** join/#asterisk-dev vassilux (~vassilux@LMontsouris-656-01-80-156.w82-127.abo.wanadoo.fr) |
| 13:01.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:07.34 | vassilux | I have to dial a peer from my application(C module). Is it possible to call Dial application from my C module application ? |
| 13:11.30 | opticron | yes, you can request the application from the pbx and then run it directly |
| 13:12.09 | opticron | you'll need pbx_findapp and pbx_exec |
| 13:12.33 | opticron | you could also use the dial API |
| 13:13.49 | vassilux | thank again opticron, I tried used ast_call etc but a lot of work and I don't understand well all things :-) I will try to look into pbx_findapp and pbx_exec |
| 13:16.37 | opticron | by dial API, I mean the things in include/asterisk/dial.h |
| 13:17.07 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 13:23.48 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:23.48 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:40.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zivkwjwzasuhcgue) |
| 13:40.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:42.27 | mjordan | opticron: unfortunately, I ended up having to revert your AMI patch this weekend |
| 13:42.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:42.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:45.46 | mjordan | opticron: I think we should still put that patch back in, but there's a lot of tests that need cleanup first. With the media format patch going on, I didn't want those failures to get intermingled with the failures from the media formats work |
| 13:51.51 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-118-98.user.veloxzone.com.br) |
| 13:53.28 | opticron | I saw and I figured that was the reasoning |
| 13:53.50 | mjordan | opticron: mind making an issue for it? We might as well track it and get it on the queue |
| 13:53.56 | opticron | sure |
| 13:54.09 | opticron | we also need to fix the tests that overwrite self.ami |
| 13:55.20 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-sfzkrftxnxeuqipb) |
| 14:00.18 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-cacnvdxivmniebom) |
| 14:04.38 | opticron | ASTERISK-24082 |
| 14:11.28 | mjordan | jrose_atDigium: were there any other changes that needed to be made to chan_iax2 for the media improvements? |
| 14:13.11 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:31.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:45.51 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 14:48.07 | mjordan | file: on the plus side, the full testsuite run didn't really run into any additional test failures |
| 14:48.30 | mjordan | so we only have about 7 tests to fix up |
| 14:48.33 | mjordan | that's pretty decent |
| 14:55.05 | file | I wonder what the age of them is |
| 14:59.12 | *** join/#asterisk-dev terryw (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:11.58 | *** join/#asterisk-dev stevePearPear_ (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 15:12.10 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-aojiudtrzljrelqr) |
| 15:12.10 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:13.22 | jrose_atDigium | mjordan: I wasn't aware of any prior to the test failures, but we'll see. |
| 15:13.58 | file | my FOOT is ITCHY |
| 15:21.02 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-gzjkjrxwebdptdpq) |
| 15:27.58 | pabelanger | These pretzels are making me thirsty |
| 15:42.56 | file | hrm |
| 15:51.54 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:56.59 | file | jrose_atDigium, what additional change did you have? |
| 15:57.14 | jrose_atDigium | file: It's codec negotiation related. |
| 15:57.21 | file | ah |
| 15:57.43 | file | I'm not in that area. |
| 16:06.30 | file | putnopvut, take on me! |
| 16:09.40 | file | there, call parking test fixed |
| 16:11.29 | tm1000 | file: yo |
| 16:11.35 | file | tm1000, hi |
| 16:12.12 | tm1000 | file: So from all of our notes Iâve got everything working with webrtc. only issue is that for some reason when I call in using webrtc asterisk thinks itâs an anon call |
| 16:12.44 | tm1000 | I was thinking maybe my certs are bad, but if they were bad I figure the stream would be rejected instead |
| 16:12.53 | file | the same logic applies regardless of transport, so it would be looking at the From header in the SIP signaling |
| 16:20.18 | file | runs out to lunch, bbiab |
| 16:29.59 | opticron | I'll take the page failure |
| 16:30.31 | mjordan | opticron: It may have been magi-fixed by file's changes |
| 16:30.37 | opticron | nope |
| 16:30.44 | mjordan | yay, things to do |
| 16:30.47 | opticron | it's a crash due to a null cap in dial api |
| 16:30.52 | mjordan | there's actually two, which one do you want? baseline? |
| 16:30.56 | opticron | yeah |
| 16:34.59 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-jmiilfthhvqoglpi) |
| 16:50.11 | tm1000 | file: if you have time when you return still need to pick your brain |
| 16:50.46 | file | tm1000, I'm here |
| 16:52.15 | tm1000 | file: still having this issue with Asterisk thinking my session is an anon call |
| 16:52.24 | tm1000 | (only from websockets) |
| 16:52.28 | file | tm1000, do you have a SIP trace? |
| 16:53.20 | tm1000 | file: getting it |
| 16:55.06 | tm1000 | file: https://www.irccloud.com/pastebin/tUkHCdSp |
| 16:56.05 | file | looks like it found the correct peer |
| 16:56.08 | file | 991004 |
| 16:56.20 | file | what's the sip show peer for that? |
| 16:56.28 | tm1000 | I am 108.67.190.52 |
| 16:56.37 | tm1000 | checking |
| 16:57.05 | tm1000 | file: http://pastebin.com/gPzQK9HC |
| 16:57.21 | tm1000 | ....Context : from-sip-external |
| 16:57.42 | file | et voila |
| 16:57.51 | file | the context is set to from-sip-external, so that's where it is looking |
| 17:00.43 | tm1000 | file: yes |
| 17:00.48 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-fbmnprklmnjruiio) |
| 17:03.01 | tm1000 | file: embarrassing that I missed that (also GameGamer43 missed it too) |
| 17:03.03 | tm1000 | yikes |
| 17:03.05 | tm1000 | but thanks! |
| 17:04.08 | file | tm1000, it's Monday |
| 17:04.15 | file | tm1000, otherwise WebRTC is... working? |
| 17:06.09 | opticron | mjordan, my fix also appears to have fixed the other Page() test failure |
| 17:06.44 | opticron | yeah, definitely the same crash |
| 17:07.10 | mjordan | crash in Asterisk? |
| 17:07.12 | mjordan | interesting |
| 17:07.24 | file | into a brick wall. |
| 17:17.21 | tm1000 | file: yes its working perfectly |
| 17:17.47 | file | well yay for that |
| 17:45.04 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 17:48.53 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-vwrqublrccubunme) |
| 17:52.33 | putnopvut | opticron: crap. There's some overlap in your review r/3728 and my r/3816 |
| 17:53.00 | opticron | yay! |
| 17:54.14 | putnopvut | Not a whole lot, but still, some. |
| 17:54.28 | opticron | ehh, I'll update my diff when yours goes in |
| 17:54.39 | putnopvut | I like that you're confident mine will go in first :) |
| 17:54.46 | opticron | yours is already shipped |
| 17:54.58 | seanbright | has anyone done any benchmarks of chan_sip vs chan_pjsip? |
| 17:55.18 | seanbright | number of simultenous calls, throughput, etc, etc? |
| 17:55.24 | putnopvut | Well, it's shipped, but not formally tested. I'm not committing mine until testsuite tests are either altered or new ones are written to test what I've changed. |
| 17:55.35 | file | simultaneous calls is a silly metric because no signaling will be going on |
| 17:55.42 | seanbright | CPS |
| 17:55.47 | file | calls per second, registrations per second, packets per second is better |
| 17:56.00 | seanbright | well when you put it that way... |
| 17:56.04 | seanbright | has anyone done any benchmarks of chan_sip vs chan_pjsip? |
| 17:56.10 | seanbright | calls per second, registrations per second, packets per second? |
| 17:56.21 | leifmadsen | lol |
| 17:56.24 | opticron | :) |
| 17:56.29 | file | hasn't |
| 17:56.31 | leifmadsen | I have not, but it would be pretty trivial to write with sippycup |
| 17:56.33 | file | not of recent code at least |
| 17:56.43 | putnopvut | seanbright: I don't think we've necessarily done an apples-to-apples test like that. When 12 debuted we did tests of PJSIP in 12 vs. chan_sip in 11. |
| 17:56.43 | seanbright | leifmadsen: thanks. let me know when you're done. |
| 17:56.49 | leifmadsen | seanbright: will do! |
| 17:56.53 | putnopvut | But those tests were mostly a test of 12 vs. 11, not pjsip vs. chan_sip. |
| 17:56.54 | leifmadsen | promptly goes back to fapping |
| 17:57.11 | seanbright | leifmadsen: i'm amazed you stopped |
| 17:57.30 | leifmadsen | seanbright: I didn't |
| 17:57.42 | leifmadsen | I type 120wpm... 50wpm with one hand |
| 17:58.06 | leifmadsen | things you wish you could unread |
| 17:58.24 | seanbright | has anyone done any benchmarks of leifmadsen's typing speed while fapping vs. not fapping? |
| 17:58.39 | opticron | no one has ever observed the latter |
| 17:58.45 | leifmadsen | lol |
| 17:58.49 | mjordan | I come back to asterisk-dev from doing hotel bookings and this is what I get |
| 17:58.57 | leifmadsen | welcome to monday? |
| 17:58.58 | mjordan | considers doing code reviews |
| 17:59.32 | putnopvut | with one hand or two? |
| 17:59.39 | mjordan | seanbright: a lot of the original performance improvements (and those that turned into the great media format death march of 2014) were due to some initial off the cuff tests of chan_pjsip in 12 versus chan_sip in 11 |
| 17:59.45 | mjordan | putnopvut: no comment |
| 17:59.54 | file | mjordan, you should have outsourced it to me! #wantthemiles |
| 18:00.28 | mjordan | to throw a stake in 'speculation land', I have a sneaky suspicion that basic tests aren't going to show much of a difference between chan_sip and chan_pjsip |
| 18:00.44 | mjordan | chan_sip, for all its warts, is pretty dead simple. Packet comes in, SERVICE IT, send response |
| 18:00.57 | mjordan | the problem is when the act of servicing the packet might take awhile. Then you're well and truly hosed. |
| 18:01.23 | mjordan | I'd suspect that things that use Realtime, or do a lot of DNS lookups, or anything else that requires interaction with the SIP request will do much better under chan_pjsip then chan_sip |
| 18:01.32 | file | mjordan, I would actually say better - but not a lot |
| 18:01.36 | mjordan | you'll also probably get a higher CPU load with chan_pjsip, simply because we have more threads attempting to do more at the same time |
| 18:02.00 | file | since the requests coming in will be pushed out to more worker threads and the stuff they deal with has little contention generally |
| 18:02.00 | mjordan | that doesn't mean it can't handle the same or higher cps, just that it will do as much as it can all the time with whatever cpus you have |
| 18:02.41 | mjordan | chan_sip, OTOH, by itself, is only ever going to peg out a single CPU. channel processing will be on other CPUs, but since chan_sip is single threaded, once it's maxed out a CPU, it's done |
| 18:02.45 | putnopvut | I expect chan_pjsip would scale to more processors better than chan_sip does. |
| 18:02.46 | seanbright | well it's better to have those cores doing something other than waiting on i/o |
| 18:02.51 | mjordan | yup |
| 18:03.05 | seanbright | if i'm getting higher utilization and more throughput then it's a win |
| 18:03.24 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 18:03.30 | file | mjordan, can you take a gander at the outbound publish review - specifically what to do when the publication expires and the other server has gone away? |
| 18:03.41 | mjordan | looks |
| 18:04.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 18:04.55 | mjordan | can the updates we receive from an external entity be marked as non-cachable? |
| 18:05.29 | file | I can force them to be - right now cachableness is conveyed over just like XMPP/Corosync |
| 18:06.57 | mjordan | hm. |
| 18:07.18 | mjordan | generally, a device state that is cachable is from an entity that is considered permanent |
| 18:07.30 | leifmadsen | also if chan_pjsip is giving me at least the same metrics with better future possibility to scale better, than I'm already happy |
| 18:07.46 | file | the entity is permanent, the connection between the servers may not be |
| 18:07.47 | leifmadsen | would just suck to be like, "chan_sip does 100 cps, chan_pjsip does 30" |
| 18:07.50 | file | (it should be) |
| 18:07.50 | mjordan | leifmadsen: it will be different at least |
| 18:07.56 | leifmadsen | different is fine :) |
| 18:08.07 | file | leifmadsen, it would be far easier to streamline (ooh fancy word) if that were the case |
| 18:08.23 | leifmadsen | aye, and the discussion around not being single-threaded I'm sure has some advantages |
| 18:08.30 | mjordan | we have ways of removing things gracefully when they actually go away, but generally, things that are devices stick around permanently, even when they are received from an external system, and even if that external system goes away |
| 18:08.42 | putnopvut | I think it would be interesting to test chan_sip on a 2 core vs. chan_pjsip on a 2 core. Then do the same thing on an 8 or 16 core box and see what happens. |
| 18:08.54 | file | mjordan, indeed |
| 18:08.56 | mjordan | That is, if Server A sends you an update for PJSIP/Alice and then dies, you don't want to remove the update for PJSIP/Alice because PJSIP/Alice may be about to subscribe to you (since her server just died) |
| 18:09.41 | mjordan | the only time you purge things from the cache is when someone tells you that the device is dead, Jim, which we don't currently do. This does lend itself to a possible situation where a badly configured system could create a bunch of stuff in the cache... but it still shouldn't be systemic. |
| 18:09.57 | leifmadsen | stop being badly configured! |
| 18:10.40 | mjordan | file: the once exception is if you ask Server A for all of its statuses again, and it doesn't return a device state it previously sent you. You would then want to remove that device state. |
| 18:11.16 | mjordan | I'm not sure that's worth the effort, since again, the device state in the cache is generally harmless (particularly if it no longer exists), and another system shouldn't be sending you a million updates for things that don't exist |
| 18:11.57 | mjordan | and we probably should do something of a performance comparison of 11 versus 13. |
| 18:12.04 | mjordan | is admittedly a bit nervous |
| 18:12.09 | file | I err on the side that without starting everyone fresh it's incredibly hard to ensure that the state is what it should be |
| 18:12.47 | file | mjordan, it will be something |
| 18:12.47 | mjordan | well, if a system shut down gracefully and sent a 'purge my stuff' message, that'd be one thing |
| 18:13.11 | mjordan | we should have a relatively easy mechanism to do something like that, since we have the eid of the source stored with the updtes |
| 18:13.14 | mjordan | er, updates |
| 18:13.52 | mjordan | on an expiration of a PUBLISH timer, however, I'm not sure what we should do |
| 18:14.05 | mjordan | since all we know is that the system hasn't been very nice to us |
| 18:14.10 | mjordan | we don't know that it's gone for sure |
| 18:14.18 | mjordan | you could end up with a refresh a short time after |
| 18:14.28 | mjordan | and purging all those states could cause some "fun" on things subscribed to the local system |
| 18:22.37 | TazzNZ | hey all |
| 18:23.52 | file | hi |
| 18:31.17 | mjordan | file: so, there is one problem |
| 18:31.32 | mjordan | but it exists today in Corosync and XMPP as well |
| 18:31.53 | mjordan | if remote system B marks PJSIP/Alice as Busy and then crashes, Alice will stay Busy until that system clears her |
| 18:32.02 | mjordan | the aggregate state of that device will end up being "Busy" |
| 18:32.04 | file | yes |
| 18:32.15 | mjordan | if you changed the eid of that system when you restart it, hilarity would ensue |
| 18:32.20 | file | yes |
| 18:32.28 | mjordan | the only thing you can do in that situation is to restart the local system. |
| 18:32.40 | mjordan | I'm not sure we should do anything about this right now, however. |
| 18:33.13 | mjordan | granted, Mark's finding does directly address that, as it would solve the "this publish timed out, what should I do with this system's updates" |
| 18:37.03 | file | nods |
| 19:07.57 | file | rmudgett / jrose_atDigium, why does the bridge created in app_bridgewait have the dissolve empty flag set? |
| 19:08.51 | jrose_atDigium | file: BridgeWait bridges go away when they aren't in use. It definitely makes things more complicated, but that was stated as a requirement at the time. |
| 19:09.07 | file | correct, but the wrapper has a reference to it and calls ast_bridge_destroy |
| 19:10.35 | rmudgett | file: Something must call ast_bridge_destroy for the bridge to actually go away. |
| 19:10.38 | jrose_atDigium | It might not be necessary in that case. The wrapping mechanics came after the initial implementation. |
| 19:10.52 | jrose_atDigium | the flag I mean. |
| 19:11.08 | jrose_atDigium | ast_bridge_destroy would still be necessary. |
| 19:11.25 | file | right - I'm fairly certain that flag is what introduces the race condition that the loop in bridgewait_exec tries to work around |
| 19:11.30 | file | and that it isn't needed |
| 19:12.29 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 19:39.02 | file | seems I was... correct |
| 20:14.51 | putnopvut | https://medium.com/p/3633cba8b5c1 |
| 20:15.59 | seanbright | read this earlier... i didn't realize there was still any debate |
| 20:19.06 | file | we're down to 5 failing tests |
| 20:25.26 | mjordan | uhm. Who actually likes i=0; i<condition; i++ in a for loop? |
| 20:27.51 | *** join/#asterisk-dev otherwiseguy (~otherwise@64.19.11.18.nw.nuvox.net) |
| 20:29.14 | Qwell | just avoid for loops altogether, and use while. |
| 20:34.13 | *** join/#asterisk-dev terryw (~otherwise@172.56.10.110) |
| 20:49.41 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.110) |
| 20:57.51 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:04.16 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.110) |
| 21:08.01 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.110) |
| 21:23.40 | jameswf | http://i.imgur.com/FRYWFbv.jpg everything should be a tumblr style quote.... |
| 21:23.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.10.110) |
| 21:37.30 | rmudgett | https://reviewboard.asterisk.org/r/3813/ seems to have been forgotten :) |
| 21:42.37 | X-Rob | 23944 is my favourite bug report ever. |
| 21:42.54 | X-Rob | d) Nobody has fully configured machine names that really map to an IP address. It just does not happens in the real world. |
| 21:42.54 | X-Rob | I think a fair number of people use DNS. |
| 21:43.03 | X-Rob | 23994 even |
| 21:55.33 | Qwell | I may or may not have (I definitely did) just stepped on some toes with r3833... |
| 21:58.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 23:03.38 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-sfzkrftxnxeuqipb) |
| 23:11.47 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:19.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
