| 00:08.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.166) |
| 00:11.40 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:07.57 | *** join/#asterisk-dev Marquis42 (~mrbmw@c-68-43-92-199.hsd1.mi.comcast.net) |
| 01:09.25 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.166) |
| 01:37.03 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:38.35 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 02:10.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.166) |
| 03:10.50 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.166) |
| 04:09.24 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 04:11.36 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.166) |
| 05:12.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.181) |
| 05:55.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.197) |
| 06:16.44 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.197) |
| 06:56.12 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.61.47) |
| 07:14.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.197) |
| 07:54.32 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:54.32 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:36.03 | *** join/#asterisk-dev vlad_starkov (~vlad_star@195.239.220.131) |
| 09:12.10 | *** join/#asterisk-dev wedhorn (~wedhorn@123-243-209-34.static.tpgi.com.au) |
| 09:28.23 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 09:28.23 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 09:53.25 | *** join/#asterisk-dev newtonr (~newtonr@64.34.219.47) |
| 09:53.25 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 10:05.03 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 10:05.05 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 10:15.20 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 10:38.40 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 11:24.17 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:00.10 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.20) |
| 12:13.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.20) |
| 12:28.41 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 12:28.41 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 12:35.58 | *** join/#asterisk-dev zerohalo (~zerohalo@c-174-62-142-83.hsd1.ma.comcast.net) |
| 12:41.32 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 12:53.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.20) |
| 13:28.54 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:28.54 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:29.51 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 13:30.48 | *** join/#asterisk-dev file (~file@mctnnbsa51w-142166190248.dhcp-dynamic.FibreOp.nb.bellaliant.net) |
| 13:33.13 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 13:40.49 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-bueaubulvylhhoiu) |
| 14:12.46 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 14:14.40 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 14:14.40 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 14:15.05 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 14:15.28 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 14:41.26 | file | a minor change that I would enjoy: arbitrary file descriptor adding/removing on a channel (with no specific limit on number), with a specified callback including data |
| 15:03.35 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 15:03.35 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 15:05.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93.191.18.82) |
| 15:09.22 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:09.22 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:12.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@93.191.18.82) |
| 15:15.22 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.35) |
| 15:18.01 | *** join/#asterisk-dev vlad_st__ (~vlad_star@93.191.18.82) |
| 15:37.19 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 15:42.37 | jmls | afternoon all |
| 15:43.00 | jmls | is pbx_builtin_setvar_helper the one to use to set a variable (I need to add a var in chan_sip.c) |
| 15:43.15 | file | that is how you set a variable on the channel, yes |
| 15:45.34 | jmls | is a coder ;) |
| 15:52.32 | jmls | if I have a struct sip_pvt *p, p->owner is the channel, right ? |
| 16:01.56 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 16:01.56 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 16:03.52 | file | yes |
| 16:26.26 | putnopvut | PJSIP has a mechanism such that it can automatically add certain headers to all outgoing requests. The mechanism is global and can only be set once. On the other hand, we could attempt to mimic this behavior ourselves in a way that is reload-friendly and potentially applicable per-endpoint rather than globally. The downside to rolling our own is that there is not currently a single function that all outgoing requests get f |
| 16:26.26 | putnopvut | iltered through, so it would mean having to repeat the same logic in several places, meaning it is potentially error-prone. The types of headers that I'm envisioning using such a mechanism for are User-Agent, Max-Forwards, and other headers that could be argued to be endpoint-specific or should be global. |
| 16:27.02 | file | putnopvut, can we sip service it? |
| 16:27.02 | putnopvut | So what are opinions on this? Go with the global one-time setting method, or go with the per-endpoint reload-friendly, but potentially error-prone method? |
| 16:27.14 | putnopvut | I don't understand the question. |
| 16:27.46 | file | instead of doing it within an API call directly do it as a SIP service that the messages pass through, which adds applicable headers |
| 16:28.36 | putnopvut | Yeah, that's a good idea. The problem is that such a service doesn't currently exist in our code. Unless PJSIP has some sort of service API that I'm unaware of. |
| 16:29.23 | putnopvut | The natural place for such a mechanism to exist in our code would be ast_sip_create_request(). The problem is that currently, SIP sessions and I believe outbound registrations don't create requests this way. |
| 16:29.37 | putnopvut | Same for other in-dialog requests. |
| 16:29.39 | file | right, the pjsip APIs do it |
| 16:30.09 | file | as long as the module is added to pjsip, and also added to created dialogs... the on_tx thingy will get called |
| 16:30.20 | putnopvut | Ah, I get what you're saying now. |
| 16:30.30 | putnopvut | And yes, that's a fantastically simple way to do it. |
| 16:30.54 | putnopvut | And I'm stupid for not thinking of it myself :) |
| 16:31.43 | putnopvut | If the settings end up being endpoint-specific, then the tricky part of that will be getting to the endpoint from our service. |
| 16:31.51 | putnopvut | If the options are global, then it's not a big deal. |
| 16:32.06 | file | NOW - there's a finite number of modules we can add (stored in an array) so further down the line we may want to abstract it out with a single module, and us doing the delegation (slightly related) |
| 16:32.32 | putnopvut | Yes. The number of modules is limited to either 32 or 64 I think. |
| 16:33.36 | file | thankfully you wrapped that already, so implementing it will have no impact externally to modules |
| 16:33.53 | putnopvut | Yerp |
| 16:37.27 | putnopvut | (also just checked. 32 max modules) |
| 16:37.51 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 16:37.51 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 16:38.41 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 16:40.42 | file | putnopvut, hum hum hum as for the global versus endpoint... |
| 16:41.45 | file | it would be nice but I think it'll complicate things a lot, and not many will use it probably... and if you were clever you could use it to do some discovery |
| 16:45.04 | file | so imo global |
| 16:49.57 | putnopvut | file: that's where I was leaning too |
| 17:02.37 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 17:03.27 | Qwell | leedm777: Since /channels now has a POST method, and dev-mode changes the failure response, how would you feel about me switching the authentication test to use /asterisk/info instead? |
| 17:03.42 | Qwell | rather, implements |
| 17:04.35 | Qwell | (had to start there, to make sure tests work on my system at all, before writing mine - turns out, they don't) |
| 17:06.23 | leedm777 | Qwell: So if you POST on /channels with no parameters, it does something now? |
| 17:06.34 | Qwell | in dev-mode, it gives me a 500 |
| 17:06.58 | Qwell | regularly, I think it would give a 400 Bad Request |
| 17:07.13 | leedm777 | That's a validation failure, then. |
| 17:07.42 | Qwell | yes |
| 17:12.20 | Qwell | oh. I suppose it's actually looking at errorResponses now. |
| 17:12.22 | Qwell | checks |
| 17:13.34 | leedm777 | Qwell: that's right. I just fixed that in trunk. |
| 17:43.59 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 17:43.59 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 17:52.09 | jmls | is an advanced coder .. |
| 17:52.13 | jmls | file: thanks |
| 17:53.53 | putnopvut | file: Is the fd returned by ast_websocket_fd() a socket? Though the documentation says I can't read or write to the fd, it doesn't say anything about using setsockopt(). Would doing that be a problem? |
| 17:54.49 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 17:54.49 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 17:57.08 | file | putnopvut, nope |
| 17:57.26 | putnopvut | which question was that "nope" for? |
| 17:58.03 | file | do the problem question |
| 17:58.05 | file | erm to |
| 18:03.02 | putnopvut | ah good then |
| 18:04.13 | putnopvut | Trying to implement the QOS options. Since we don't manage the SIP sockets directly, figuring out how to handle the QOS stuff is interesting. For TCP, it's super easy. It's part of the configuration that you pass in when starting the transport. For UDP and Websocket, I can get to the socket so I can set the option directly. For TLS...I'm still searching. |
| 18:04.32 | putnopvut | Oh looks like TLS is just like TCP |
| 18:04.34 | putnopvut | Cool |
| 19:32.29 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 19:32.29 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 19:35.38 | putnopvut | nomenclature discussion: with the SIP configuration work I'm doing, there's going to be a need for global values to be set. Some of these values will be used by Asterisk and can be changed by performing a reload. Other options will be fed into PJSIP when initializing PJSIP and cannot be altered without unloading res_sip.so and then loading it again. Because of the difference between the two, I'll have to use two separate s |
| 19:35.38 | putnopvut | orceries for representing the values. This means I'll need two separate configuration sections. My ideas for the two section names so far are either "asterisk" and "pjsip" or something like "general" and "system". |
| 19:35.51 | putnopvut | Anyone have any thoughts on the matter? |
| 19:50.20 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 19:50.20 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 20:06.09 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.179) |
| 20:23.53 | file | putnopvut, based on the lack of response you can safely assume going with whatever strikes your fancy |
| 20:26.04 | putnopvut | file: Sounds good to me! |
| 20:30.28 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 20:30.28 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 20:54.53 | *** join/#asterisk-dev ChanServ (ChanServ@services.) |
| 20:54.53 | *** mode/#asterisk-dev [+o ChanServ] by orwell.freenode.net |
| 20:56.39 | *** join/#asterisk-dev spditner (~simon@206-248-134-100.dsl.teksavvy.com) |
| 20:59.16 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:59.16 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 21:02.41 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-qinzuykqhyvguqsi) |
| 21:06.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.179) |
| 21:31.00 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 21:32.21 | *** join/#asterisk-dev tonyclewis (uid6025@gateway/web/irccloud.com/x-ghqrbnpuwunoacev) |
| 22:01.01 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-huzkxdzgcybrcofg) |
| 22:07.33 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.179) |
| 22:15.02 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:15.02 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 22:26.38 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-qinzuykqhyvguqsi) |
| 22:31.31 | opticron | hmmm...CEL may need a local channel optimization meta-event |
| 23:08.18 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.179) |
| 23:45.46 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:45.47 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:46.03 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |