| 00:40.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.218) |
| 01:21.04 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 01:40.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.161) |
| 02:02.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.222) |
| 02:17.33 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 02:40.42 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.173) |
| 03:40.43 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.193) |
| 04:40.46 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.193) |
| 05:12.04 | *** join/#asterisk-dev serafie1 (~erin@24.96.64.240) |
| 05:40.49 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.247) |
| 06:40.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.187) |
| 06:52.31 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.160) |
| 06:59.52 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.160) |
| 07:06.28 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.160) |
| 07:13.10 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:19.03 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:35.25 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 07:49.19 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 07:54.48 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.186) |
| 08:17.34 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 08:36.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:3184:38ff:c11e:7714) |
| 08:59.09 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 09:17.07 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 09:52.13 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:17.07 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 10:19.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:19.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:16.12 | *** join/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 11:17.08 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 11:27.53 | tzafrir | it's early monday morning now (their local time) |
| 11:41.46 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:43.56 | *** part/#asterisk-dev oron (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 12:17.14 | *** join/#asterisk-dev roderickm (~roderickm@99-124-89-102.lightspeed.dctral.sbcglobal.net) |
| 12:21.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 12:23.54 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 12:29.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.166) |
| 12:31.36 | danjenkins | morning |
| 12:33.23 | skrusty | morning dan |
| 12:33.31 | skrusty | (or afternoon here :) |
| 12:33.52 | danjenkins | oh i hadnt noticed |
| 12:33.54 | danjenkins | whoops |
| 12:33.56 | danjenkins | afternoon! |
| 12:34.18 | danjenkins | anyone good with xsl functions? |
| 12:35.46 | danjenkins | ive added the ami event classes to the wiki pages but annoyingly the class is in the XML generated from Asterisk as EVENT_FLAG_CLASS - so EVENT_FLAG_DTMF - but i just want it in the wiki as DTMF and i cant figure it out for the life of me |
| 12:35.56 | danjenkins | https://github.com/danjenkins/publish-docs/compare/add-class-to-event-page#diff-b7581f44fdecdcc52062c99d8fa15352R148 |
| 12:40.29 | skrusty | sorry, not a clue :) |
| 12:44.20 | danjenkins | oh i figured it out! |
| 12:44.22 | danjenkins | :) |
| 12:46.32 | *** join/#asterisk-dev ulogic (421e6b4f@gateway/web/freenode/ip.66.30.107.79) |
| 12:49.41 | danjenkins | woohoo, number 1! https://github.com/asterisk/publish-docs/pull/1 |
| 13:12.32 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 13:13.47 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:22.35 | skrusty | danjenkins: get you! ;) |
| 13:26.24 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 13:28.47 | danjenkins | number 1 number 1 number 1 skrusty |
| 13:32.52 | skrusty | :] |
| 14:07.00 | *** part/#asterisk-dev mjordan (~matt@75.76.55.191) |
| 14:14.46 | *** join/#asterisk-dev Greenlight (wluke@cpc1-dund9-0-0-cust142.16-4.cable.virginm.net) |
| 14:23.28 | *** join/#asterisk-dev BrokenNoze (~BorkenNoz@host81-133-140-79.in-addr.btopenworld.com) |
| 14:24.31 | BrokenNoze | Hi, I'm having an issues understanding the ISeqNo and OSeqNo within the IAX2 protocol and when my soft phone should increment them, does anyone have a bit more knowledge than that within the RFC 5456 |
| 14:24.49 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mvovbsvlxdybbczd) |
| 14:42.06 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.99) |
| 15:00.32 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 15:01.22 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:04.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:437:ce01:2677:3ff:fe8f:2730) |
| 15:05.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:05.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:09.28 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-qxfzfytanooofnnx) |
| 15:09.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:10.14 | danjenkins | leedm777: right back at you ;) https://github.com/asterisk/publish-docs/pull/1#issuecomment-33373816 |
| 15:11.22 | putnopvut | I want to merge my PJSIP body generation code, but there are two things to consider. 1) Should I wait until the corresponding review for testsuite tests also has a ship it! so I can commit them both at the same time? and 2) I developed the feature against Asterisk trunk, but I heard murmurs that this may be wanted for Asterisk 12 instead. Since it is PJSIP-related and has tests, it is a valid 12 contribution. Which branch |
| 15:11.22 | putnopvut | should it go in? |
| 15:19.11 | wdoekes | (+0 for as much pjsip stuff as possible in 12 so 13 gets less changes and can be more stable) |
| 15:19.40 | file | provided it has tests I'm fine with 12 |
| 15:31.03 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-dmmbtivyoqkfyhus) |
| 15:31.57 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:33.05 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 15:33.05 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:34.36 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-twlukhibkukfumgn) |
| 15:36.52 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-prruvkzuoenaikvc) |
| 16:02.33 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-eynogjmoddhhrxxm) |
| 16:18.24 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 16:23.22 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 17:09.50 | tm1000 | file: mjordan do I need enablestatic=yes in httpd.conf for ARI and/or Websockets (webrtc)? |
| 17:09.57 | tm1000 | or can I keep that disabled |
| 17:10.10 | file | if you aren't serving static content it should be fine off |
| 17:10.41 | tm1000 | ok |
| 17:15.30 | tm1000 | file: also, does prefix= apply? |
| 17:15.47 | tm1000 | if I did prefix=asterisk then it would be <address>/asterisk/ws |
| 17:16.10 | tm1000 | right now I have it as prefix=, so it works as <address>/ws |
| 17:16.32 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-unkgxbitfuywtnev) |
| 17:16.49 | file | looks like it |
| 17:17.47 | tm1000 | file: thanks |
| 17:32.18 | mjordan | russellb: "Merge config updates". |
| 17:32.37 | russellb | mjordan: commit messages are lovely like that if you have to go back that far |
| 17:33.11 | mjordan | file just hit one from r358 |
| 17:33.17 | russellb | nice |
| 17:33.27 | file | yeah... |
| 17:33.28 | mjordan | it's like archeology at that point |
| 17:33.50 | file | "Version 0.1.9 from FTP" |
| 17:34.01 | russellb | file: yes, doesn't get much better than those |
| 17:34.13 | russellb | the "damnit, we lost the CVS server" commits |
| 17:34.31 | mjordan | lots of heroic effort goin on |
| 17:35.23 | *** join/#asterisk-dev roramirez (~rodrigo@pc-34-179-160-190.cm.vtr.net) |
| 17:35.47 | file | I keep saying to myself, "this can go away... we can do better" |
| 17:36.10 | mjordan | just remember what they say about scope creep |
| 17:36.24 | mjordan | and the great bridge merge crisis of 2013 |
| 17:36.59 | file | mjordan, unfortunately this is within scope :P |
| 17:37.05 | mjordan | oh, I know |
| 17:37.31 | file | I'm actually quite excited about having preference order and framing carried around... it'll allow us to make stuff not suck in the future |
| 17:37.52 | mjordan | tomorrow, tomorrow, it'll suck less, tomorrow |
| 17:38.15 | file | mjordan, quite |
| 17:38.15 | russellb | "making code suck less" -- all of our job descriptions |
| 17:38.40 | file | we could... wait for it... put smoothers in the core and intelligently add them |
| 17:38.44 | mjordan | NOOO |
| 17:38.47 | mjordan | crazy talk. |
| 17:39.44 | mjordan | file: are you considering making T.38 an actual format? |
| 17:39.58 | file | we could... adhere more closely to preference order |
| 17:40.00 | file | mjordan, meh eventually |
| 17:40.03 | mjordan | k |
| 17:40.07 | mjordan | just wondering. |
| 17:40.14 | file | it wouldn't be that hard |
| 17:41.39 | file | mjordan, SCOPE CREEP :p |
| 17:42.27 | mjordan | I wasn't advocating it |
| 17:42.27 | [TK]D-Fender | The trick is adjusting for elevation... |
| 17:42.32 | mjordan | just figuring out what needs to be in the tests |
| 17:42.39 | [TK]D-Fender | goes to check out a new water-tower |
| 17:42.44 | file | mjordan, test all the things! |
| 17:44.52 | *** join/#asterisk-dev ColonelShorts (~ColonelSh@nat/digium/x-khnhdawfvggiuldi) |
| 17:47.36 | russellb | poor testsuite still seems to be flakey |
| 17:47.41 | russellb | i get angry emails when i commit stuff |
| 17:48.10 | file | it has improved, but there's still some bouncy tests |
| 17:48.33 | russellb | how long does it take to run these days? |
| 17:50.19 | russellb | avg full testsuite run is 218m bamboo says ... |
| 17:50.29 | mjordan | well |
| 17:50.33 | mjordan | the full run is about that long. |
| 17:50.56 | mjordan | but we've broken it up into a few other subsets. Channel Drivers and ARI |
| 17:50.57 | russellb | tempting to start a test suite rev 2 with parallel test cases running from the beginning |
| 17:51.13 | mjordan | that'd be interesting |
| 17:51.16 | russellb | as in, tests written such that they don't assume they're the only trest case running |
| 17:51.31 | mjordan | yeah. It'd be some interesting dialplan |
| 17:51.35 | mjordan | and debugging test failures would suuuck |
| 17:51.41 | russellb | nods |
| 17:52.00 | russellb | it's almost like debugging a real system :) |
| 17:52.36 | russellb | the actual paralellization part is easy if rev2 was written in standard Python test case style, as there is a nice python test runner that will run test cases in parallel for you |
| 17:52.54 | russellb | if only we all had infinite time |
| 17:53.21 | mjordan | indeed. Sort of hard to justify throwing away all the tests |
| 17:53.45 | russellb | right, it'd be a parallel effort, have both suites and port tests over until porting is done |
| 17:54.01 | mjordan | heh |
| 17:54.07 | mjordan | not all of the lua tests have been ported over |
| 17:54.11 | russellb | nice |
| 17:54.16 | mjordan | at least the last of the bash tests died |
| 17:54.22 | russellb | which of course is the main reason it's *not* using a python test running and python test cases to begin with |
| 17:54.29 | russellb | runner* |
| 17:54.31 | file | history. |
| 17:54.37 | russellb | file: yup |
| 17:54.42 | russellb | takes all the blame for this of course |
| 17:54.53 | file | my music needs to index faster... I want to listen to the soundtrack to Hackers >_> |
| 17:55.03 | russellb | file: love that soundtrack |
| 17:55.05 | Qwell | russellb: nah, blame mnicholson, since he's not here |
| 17:55.10 | russellb | Qwell: heh, there ya go |
| 17:55.23 | file | russellb, I rewatched the movie this weekend |
| 17:55.25 | Qwell | or jrose! |
| 17:55.25 | russellb | we're all learning and improving. |
| 17:55.33 | Qwell | he's gone too, quick, get the pitchforks |
| 17:55.40 | russellb | what happened to jrose? |
| 17:55.50 | Qwell | he just disconnected |
| 17:55.58 | russellb | heh |
| 18:01.22 | mjordan | file: have you gotten into defining how codecs will be offered on an outbound dial? |
| 18:01.33 | file | no |
| 18:01.39 | mjordan | want some ideas? |
| 18:01.51 | file | sure |
| 18:02.30 | mjordan | so, if we go with offer only the peer's preferred codecs, we'll be doing what users want and expect (yay) |
| 18:02.41 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-bfbjhybpmzhbmfeb) |
| 18:02.43 | mjordan | however, there's always the chance that we'll end up in transcoding situations. |
| 18:03.28 | mjordan | I'm thinking the best answer there, however, is to let the user control what is sent in the response to the inbound channel's INVITE request |
| 18:03.54 | mjordan | that seems to be the point where you make the decision of "okay, this is what the far-end came back with - now what do I actually want to do" |
| 18:04.07 | file | aye |
| 18:04.09 | mjordan | we could still keep the 'normal' functions that let you modify the outbound channel's INVITE request |
| 18:04.10 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 18:04.21 | mjordan | so you can override the endpoint's preferences |
| 18:04.31 | pabelanger | Okay, PRI peeps. How can I tell which channel this is in dahdi? http://pastebin.com/r3stMH9T |
| 18:04.52 | pabelanger | for some reason it return cause 34 back to telco |
| 18:05.02 | pabelanger | and I think my dahdi channel is some how stuck |
| 18:05.04 | file | putnopvut, I may scrap your format capability string caching... I don't think I'll need it ^_^ |
| 18:05.59 | mjordan | file: the real trick there is that we don't want to limit this to just dialing. It actually is more of a generic thing that should be done or set on the channel prior to Answer |
| 18:06.05 | mjordan | that way it will still work with ARI |
| 18:06.13 | file | mjordan, yes |
| 18:06.19 | file | mjordan, accepted formats |
| 18:06.23 | mjordan | yup |
| 18:06.36 | mjordan | you can then limit yourself to only one format as well in the reply if you so desire |
| 18:06.44 | mjordan | preferred_codec_only, as it were |
| 18:07.13 | mjordan | so, that works for chan_pjsip |
| 18:07.19 | mjordan | how crazy do we want to mess up chan_sip |
| 18:07.25 | mjordan | and, uhm, everything else. |
| 18:07.37 | file | I'd like to keep touching them to a minimum... |
| 18:07.42 | file | it's already going to happen "enough" |
| 18:07.45 | mjordan | yeah. |
| 18:07.54 | mjordan | pabelanger: your best bet is asterisk-users mailing list. |
| 18:08.27 | file | the impact of just changing ast_format to a reference counted structure alone is... mind boggling |
| 18:08.36 | tzafrir | pabelanger, what version of asterisk is it? I remember newer versions include span number in that trace |
| 18:09.25 | pabelanger | tzafrir, still 1.8 |
| 18:09.31 | pabelanger | looking for the patch that adds support |
| 18:11.08 | mjordan | file: the question then, I guess, is do we allow forced transcoding by default? Say Alice supports ulaw only and Bob supports g729 - do we let the dial go through? |
| 18:11.51 | file | define "supports g729" using PJSIP as an example - do you mean it's disallow=all allow=g729 only? |
| 18:12.17 | putnopvut | Feel free to get rid of the string caching if it doesn't fit. |
| 18:12.18 | putnopvut | Yo |
| 18:12.19 | mjordan | correct |
| 18:12.38 | mjordan | Alice has disallow=all; allow=ulaw - Bob has disallow=all; allow=g729 |
| 18:12.44 | mjordan | there is a translation path in Asterisk |
| 18:13.01 | file | then that's a valid scenario |
| 18:13.02 | mjordan | but they don't have a shared capability to speak of, per se |
| 18:13.04 | mjordan | right |
| 18:13.09 | file | so, allow it |
| 18:13.21 | file | that's the expected behavior |
| 18:13.25 | file | (by a lot of people) |
| 18:13.55 | mjordan | what if you have Alice: allow=!all,ulaw - Bob: allow=!all,g729,ulaw |
| 18:14.12 | mjordan | since g729 is Bob's preferred codec, that should be the first codec listed |
| 18:14.32 | file | that's what we prefer, doesn't mean that's what Bob will be happy with |
| 18:14.54 | mjordan | true. If Bob returns just g729, then we transcode, otherwise his endpoint may switch over to ulaw |
| 18:14.56 | pabelanger | tzafrir, was the patch for libpri? |
| 18:15.03 | file | mjordan, indeed |
| 18:15.03 | pabelanger | or dahdi |
| 18:15.24 | mjordan | and again, something in between the dialing and bridging can allow a user to change the formats if desired. |
| 18:15.33 | tzafrir | hmm... maybe it was dropped on the 1.8 rewrite? |
| 18:15.35 | file | mjordan, and really until the call is up there can't be an informed enough decision |
| 18:15.36 | mjordan | we'll have to really make sure we get all ends checked |
| 18:15.54 | mjordan | file: by up, media passing through the core from both endpoints? |
| 18:16.08 | file | media doesn't have to pass, but you do need an answer from the other side |
| 18:16.14 | mjordan | right |
| 18:16.22 | file | so it can tell you accepted formats |
| 18:16.56 | mjordan | at the end of the day, we should follow "let the user tell us the configuration, and let them change it dynamically if they want" |
| 18:17.02 | mjordan | guessing has led us poorly |
| 18:17.34 | file | don't try to be clever. |
| 18:18.00 | mjordan | chan_sip will probably still attempt to be so. |
| 18:18.02 | mjordan | oh wellz. |
| 18:19.30 | file | there is only one scenario really where you can be clever and not allow it... which is single codec on inbound, single codec on outbound, different codec, no transcoding path available |
| 18:20.57 | mjordan | well |
| 18:21.05 | mjordan | no transcoding path should always result in a failed call |
| 18:21.43 | mjordan | we don't have to be aggressive about it, that should happen just prior to bridging (and actually, I'll bet our bridging could still take care of it) |
| 18:21.54 | mjordan | softmix - transcode everything to SLIN |
| 18:22.06 | file | yeah |
| 18:26.22 | roramirez | Hello everyone. I'm new here. |
| 18:27.35 | roramirez | i developed a little feature to cel_pgsql https://issues.asterisk.org/jira/browse/ASTERISK-23186 |
| 18:27.35 | CaptainPants | [ASTERISK-23186] [Status: Triage] Add usegmtime option to cel_pgsql.conf - https://issues.asterisk.org/jira/browse/ASTERISK-23186 |
| 18:29.44 | mjordan | file: so here's a weird one. Alice offers ulaw/g729 - Bob's codecs are g729/ulaw. So Alice and Bob prefer different codecs. We reply in our response to Alice with ulaw/g729. Can we still do native bridging? |
| 18:30.30 | mjordan | roramirez: cool - I imagine that was done for a similar reason to pabelanger's patch to app_queue? |
| 18:30.38 | file | you can always do native bridging, but do you want it to reliably work? |
| 18:31.00 | mjordan | in other words, if we don't have the same codec as the preferred codec between both endpoints, just bridge in the core |
| 18:31.03 | file | the answer therefore is: in order to reliably do it you need to re-invite to a single codec to force it |
| 18:31.55 | pabelanger | roramirez: seen your message this morning, but closed my irc client before I could response, then lost your handle. |
| 18:31.57 | mjordan | well, ostensibly, if phone A has the same set of negotiated codecs as Phone B, regardless of the order, they should be able to interpret the media |
| 18:32.13 | mjordan | but something tells me that won't always work |
| 18:32.19 | pabelanger | mjordan, roramirez: Ya, the only real want to setup logging to gmt ATM. I had to add something to app_queue |
| 18:32.31 | file | mjordan, right |
| 18:32.32 | pabelanger | Ideally, it would be global to all logging |
| 18:33.06 | mjordan | hm. |
| 18:34.30 | file | mjordan, thus reinviting to a single codec to force it to work |
| 18:35.00 | mjordan | not sure how to do that from dialplan. |
| 18:35.05 | mjordan | That would have to be post-answer |
| 18:35.21 | mjordan | sighs |
| 18:36.01 | mjordan | I suppose you could set a channel datastore on the channel that says "hey, when you go into a bridge, try to re-invite back to whatever the other guy has" |
| 18:36.15 | mjordan | smart bridging should do the rest |
| 18:37.23 | file | mjordan, actually yeah... |
| 18:37.46 | file | mjordan, we can use the control frame for requesting a specific codec |
| 18:38.24 | mjordan | the trick is not having to poll in the bridging code for when a channel finally changes its format |
| 18:38.27 | file | and then if conditions change we can have the bridging react and try to smart bridge |
| 18:38.33 | mjordan | so that the smart bridge gets triggered |
| 18:39.01 | file | it's reactive at ingress :D |
| 18:39.17 | file | the RTP stack will notice the difference and queue up a control frame ahead of media |
| 18:39.22 | mjordan | correct |
| 18:39.25 | mjordan | good |
| 18:40.03 | file | so it may end up being two control frames... one for notification, one for request |
| 18:41.06 | file | applications or bridging can do the request, and then they can react to the notification |
| 18:46.35 | roramirez | yea mjordan, pabelanger told me about how was possible to get this feature. |
| 18:48.02 | roramirez | i thinks you should also set global the use gtm log |
| 18:48.44 | roramirez | no problem pabelanger, thanks for your help. Its was very useful |
| 18:49.55 | mjordan | so, the correct solution to this problem isn't to have this option in every .conf file. That way lies madness. In the end, you should be able to configure the timezone for your Asterisk instance (most likely in asterisk.conf). |
| 18:50.57 | mjordan | The problem then becomes: what to do with the CEL/Queue/wherever else options? |
| 18:51.08 | mjordan | do you just deprecate them? |
| 18:51.10 | mjordan | remove them? |
| 18:51.15 | mjordan | let them override asterisk.conf? |
| 18:53.21 | roramirez | mmm i thinks the asterisk.conf should be override the other options for modules |
| 18:53.33 | roramirez | that's IMHO |
| 18:55.03 | pabelanger | well, if we are doing a redesign, we should allow the user to specific the TZ they want the files logged in, vs just GMT |
| 18:58.02 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 18:58.11 | mjordan | heh |
| 18:58.14 | mjordan | we aren't doing a redesign |
| 18:58.27 | mjordan | the question is, however, should we continue to add options that aren't really fixing the problem? |
| 18:58.52 | mjordan | by "we", I mean folks here at Digium. If someone wants to go tackle this from a holistic, all of Asterisk perspective, that would rock out |
| 18:59.37 | mjordan | if no one is interested in doing that work, then I'm not really against this patch per se. But it'd be nice to know if this is really a systemic problem |
| 18:59.49 | mjordan | that someone would be interested in addressing in a long term, complete solution kind of way |
| 19:02.56 | mjordan | actually |
| 19:03.04 | mjordan | fixing this in a long term fashion isn't that hard. |
| 19:03.10 | mjordan | It may even be less code than the queue/cel options. |
| 19:04.13 | mjordan | heh |
| 19:04.28 | mjordan | there's even code conditionally compiled in for SOLARIS for this |
| 19:04.45 | mjordan | in stdtime/localtime, ast_tzset has a case for handling when a timezone isn't set |
| 19:05.01 | mjordan | instead of always deferring to /etc/localtime, have an option set from asterisk.conf that defaults the zone to GMT |
| 19:05.35 | mjordan | roramirez: if you're interested, that patch would be hugely welcome, and would have a much larger reach than only changing CEL for Postresql |
| 19:05.50 | mjordan | plus, all the log entries across Asterisk would be unified, unless they had an explicit timezone set. |
| 19:15.08 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 19:19.05 | roramirez | ok mjordan, thanks for advocacy |
| 19:19.18 | coreyf1513 | roramirez: mjordan: I find it useful to have CDR in GMT for long term storage and to avoid daylight savings overlap. I like messages/full in local time for easier reading while troubleshooting (these are not long term records). |
| 19:20.43 | mjordan | fair enough - the good news is that having a 'default' in ast_tzset wouldn't interfere with other modules |
| 19:21.02 | mjordan | seeing the same option propagated across Asterisk feels like a code smell |
| 19:22.41 | roramirez | i thinks, imho, i am new here. I could try the develop the this feature for cel and backend. |
| 19:28.40 | mjordan | roramirez: that'd be awesome |
| 19:28.56 | mjordan | roramirez: the location I was referring to was in main/stdtime/localtime |
| 19:29.08 | mjordan | ast_localtime is defined there - which is the function you were modifying for CEL |
| 19:29.21 | mjordan | if you look at that function call, you'll see it calls ast_tzset |
| 19:29.43 | mjordan | ast_tzset could default the timezone to either "GMT" or "/etc/localtime" |
| 19:32.06 | mjordan | you could define a new extern option for this in asterisk/options.h - ast_default_timezone, or something like that |
| 19:37.03 | pabelanger | anybody want to review https://reviewboard.asterisk.org/r/3159/ ? |
| 19:37.12 | pabelanger | one liner that fixes #includes |
| 19:37.18 | roramirez | ok mjordan let me see there, thanks for your help |
| 19:37.20 | pabelanger | apparently the bug is like 8 years old |
| 19:48.10 | mjordan | bugs are like wine. |
| 19:48.18 | mjordan | Eventually, they get corked and you just throw the whole thing out. |
| 19:53.54 | mjordan | file: to summarize all the musings earlier - in the absence of everything, (a) whatever an endpoint is configured with is what we offer on an outbound INVITE, (b) our response to an INVITE should always be the intersection of the endpoint's configured codecs and what was offered to Asterisk, giving preference to the order of the codecs that were configured |
| 19:54.12 | mjordan | file: dialplan functions/variables can modify the set of codecs that are offered on an outbound invite request |
| 19:54.43 | mjordan | file: and similar dialplan functions/variables can modify the set of codecs that are sent on the response to an INVITE request, assuming the channel isn't answered |
| 19:54.52 | file | oui |
| 19:55.30 | mjordan | finally, a function can be used that sets on the channel a flag to attempt to negotiate to a common codec with whoever they are bridged with |
| 19:55.48 | mjordan | er, not finally. That's an additional one. |
| 19:56.04 | mjordan | and THEN finally, a dialplan function can be set to force a re-INVITE on a channel at any point in time to a set of codecs. |
| 19:56.21 | mjordan | (which would be the ultimate "you don't like what you got, go change it") |
| 19:56.22 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:59.58 | file | yup |
| 20:06.08 | *** join/#asterisk-dev jmls (~julian@77.107.171.82) |
| 20:06.19 | jmls | happy new year, all ! |
| 20:06.26 | jmls | only 27 days late .. |
| 20:09.02 | jmls | using asterisk SVN-branch-11-r406567 , whenever my polycom 331 tries to place any call, I get a core dump ... http://pastebin.com/98KkS2DS |
| 20:10.49 | pabelanger | so, I'm trying to understand something in chan_sip.c, why Asterisk will Unregister an extension in parse_register_contact(), then send 200 OK, but not actually register the extension within asterisk. Hopefully, I'm reading this trace correctly: http://pastebin.com/ky66qxRq |
| 20:12.06 | pabelanger | I believe it has to do with the Expiry being set to 0 |
| 20:12.12 | pabelanger | expires* |
| 20:15.45 | pabelanger | Here is another REGISTER sequence that works as I expected: http://pastebin.com/jNr4x5K4 |
| 20:15.52 | pabelanger | asterisk does not Unregister the phone first |
| 20:19.12 | pabelanger | <PROTECTED> |
| 20:19.32 | pabelanger | okay, so basically if Asterisk gets Expires: 0, it will unregister the phone |
| 20:19.43 | pabelanger | but should it be sending back 200 OK? |
| 20:25.27 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:25.27 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:58.50 | wdoekes | pabelanger: the register succeeds, so 200 is the right answer |
| 21:00.03 | pabelanger | wdoekes, well, I think the first one is snom asking to deREGISTER |
| 21:00.09 | pabelanger | that is what Expires:0 means I think |
| 21:00.49 | pabelanger | but why the phones doesn't reREGISTER after that, is a mystery right now |
| 21:00.59 | pabelanger | I just want to confirm my understand is correct |
| 21:01.06 | wdoekes | I didn't read the pb, so |
| 21:01.32 | pabelanger | ok |
| 21:02.02 | wdoekes | expires:0 means unregister indeed |
| 21:02.52 | wdoekes | the point I was trying to make is that if the phone asks for an expiry of 0 or 1 or 3600 -- if asterisk complies, it sends a 200 |
| 21:03.25 | pabelanger | wdoekes, what should asterisk reply for the expires header in the 200 OK? |
| 21:03.54 | wdoekes | I presume it should mimic the request, unless it has alternate limits (but for unregister, it sounds like 0) |
| 21:06.08 | pabelanger | okay, need to confirm what it should be, asterisk is sending back minreg |
| 21:06.29 | pabelanger | only recent issue I see is ASTERISK-22428 but not sure that is the issue |
| 21:06.29 | CaptainPants | [ASTERISK-22428] [Status: Closed] [Assigned: elguero] [patch] SIP unregister does not fully unregister when using Realtime sip peers and Expires not 0 on 200ok - https://issues.asterisk.org/jira/browse/ASTERISK-22428 |
| 21:06.43 | wdoekes | hm |
| 21:06.44 | wdoekes | <PROTECTED> |
| 21:06.45 | wdoekes | <PROTECTED> |
| 21:06.46 | wdoekes | <PROTECTED> |
| 21:06.46 | wdoekes | <PROTECTED> |
| 21:06.48 | wdoekes | <PROTECTED> |
| 21:07.20 | pabelanger | ASTERISK-12810 |
| 21:07.20 | CaptainPants | [ASTERISK-12810] [Status: Closed] [patch] When unregistering a UA, 200 OK response from Asterisk is not SIP compliant - https://issues.asterisk.org/jira/browse/ASTERISK-12810 |
| 21:08.00 | pabelanger | That is the issue with my 200 ok expire, but it is an OLD issue |
| 21:08.34 | wdoekes | so you're unregistering 10.1.4.155, but asterisk says it will linger on for 60 more seconds instead |
| 21:09.48 | pabelanger | well, no. I don't know why 10.1.4.155 is unregistering it the first place. Asterisk will unregister it, but got side tracked on the 200 OK expires field. For some reason, my phone is not reregistering |
| 21:09.51 | pabelanger | and I don't know why |
| 21:10.20 | pabelanger | The next step would be to setup SIPp and confirm the validation |
| 21:11.03 | wdoekes | it might not be reregistering because it gets the expires=60.. |
| 21:11.10 | wdoekes | instead of the expected 0 |
| 21:11.21 | pabelanger | right |
| 21:11.58 | mjordan | jmls: please file a bug |
| 21:12.03 | pabelanger | ASTERISK-22428 likely is the fix then |
| 21:12.03 | CaptainPants | [ASTERISK-22428] [Status: Closed] [Assigned: elguero] [patch] SIP unregister does not fully unregister when using Realtime sip peers and Expires not 0 on 200ok - https://issues.asterisk.org/jira/browse/ASTERISK-22428 |
| 21:12.12 | pabelanger | will have the client upgrade |
| 21:12.52 | *** part/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 21:14.34 | wdoekes | sounds plausible |
| 21:14.52 | mjordan | jmls: also, your backtrace doesn't appear to line up with the latest chan_sip from SVN. Are you running a modified version of Asterisk? There's only a single memset in process_sdp, which is clearing out a t38 parameter structure, and that's on line 10379. The memset in your backtrace is way back on line 9942 |
| 21:17.24 | pabelanger | wdoekes, the fact there the testsuite is testing this logic, makes me happy. And seems to be on par with what the RFC is saying |
| 21:17.34 | mjordan | the other option is that the memset is occurring as it allocates the ast_rtp_codecs structures on the stack, which appears to be what is actually happening. And you're probably blowing past the stack. |
| 21:17.50 | mjordan | jmls: in which case, what the heck are you running this on, and have you tried compiling with LOW_MEMORY? |
| 21:18.24 | putnopvut | I'm a bit confused about stasis caching practices. From what I can tell, looking at code, when a stasis message is published, the cache is updated by that thread before the stasis_publish() returns. However, I'm writing a test at the moment and finding that not to be the case. Am I mistaken about how stasis caching works/misreading the code? |
| 21:18.53 | jmls | mjordan: it's a virgin asterisk 11 svn checkout, no mods |
| 21:19.14 | jmls | running on a raspberry pi, which has been fine for 18 months ;) |
| 21:19.25 | jmls | I should say , 10 was fine |
| 21:19.30 | mjordan | 10 != 11. |
| 21:19.38 | jmls | ya, I think I see that ;) |
| 21:20.08 | mjordan | And you probably are blowing the stack, as ast_rtp_codecs structures are rather large. I'd recommend trying with LOW_MEMORY, although that option may or may not work. Your mileage may vary. |
| 21:20.20 | jmls | I'll give it a try |
| 21:20.33 | mjordan | I will say that it is highly unlikely that we'll rip apart the codecs structures for a raspberry pi. |
| 21:20.41 | jmls | heh |
| 21:20.50 | jmls | it's a smart little box for soho |
| 21:21.10 | jmls | oh crap. |
| 21:21.18 | jmls | low memory already selected ;) |
| 21:21.27 | mjordan | hm. |
| 21:21.40 | jmls | you know what, I've had problems with LOW_MEMORY before |
| 21:21.46 | mjordan | try without it. That may seem counterintuitive, but LOW_MEMORY may be causing more problems than it solves |
| 21:21.47 | jmls | let me reset |
| 21:23.04 | putnopvut | LOW_MEMORY certainly results in a smaller stack, so it may therefore be easier to blow the stack. |
| 21:23.28 | file | formatsssss |
| 21:24.35 | mjordan | heh |
| 21:24.52 | *** join/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 21:24.54 | mjordan | putnopvut: I'll bet that is what is happening, particularly since I'm fairly sure that the size of ast_rtp_codecs isn't reduced accordingly |
| 21:25.08 | mjordan | even if it was, it probably wouldn't reduce it enough |
| 21:30.31 | jmls | if I were to only include some codecs in teh build. not them all, would that also make a difference ? |
| 21:30.44 | file | sadly no |
| 21:30.56 | jmls | bugger |
| 21:31.14 | jmls | what's the definition of low_memory ? 1K ? ;) |
| 21:31.41 | putnopvut | Dang, I saw my name highlighted and thought there was an answer to my stasis cache question. |
| 21:33.42 | leedm777 | putnopvut: I believe you are correct about how stasis caching should work. |
| 21:33.54 | leedm777 | I have no idea why it would behave differently for your test, though. |
| 21:34.41 | putnopvut | Well, there's always the possibility I'm "doing it wrong" when checking the cache. |
| 21:34.43 | mjordan | it should be updated on the publisher thread, since the caching topic makes a subscription without a mailbox |
| 21:34.53 | putnopvut | Yeah, that's what I was seeing. |
| 21:36.15 | *** part/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:36.24 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 21:36.24 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 21:36.45 | putnopvut | Ugh. ctrl+w in vim is quite different from ctrl+w in x-chat |
| 21:37.20 | jmls | lol |
| 21:37.42 | putnopvut | So the sequence is ast_devstate_changed_literal(SOME_STATE, AST_DEVSTATE_CACHABLE, SOME_DEVICE); Then I follow that up with stasis_cache_get(ast_device_state_cache(), ast_device_state_message_type(), SOME_DEVICE); |
| 21:37.55 | putnopvut | Sometimes the stasis_cache_get() returns NULL, and sometimes it returns non-NULL |
| 21:38.13 | file | devicestate is... different |
| 21:38.44 | putnopvut | I also tried replacing the SOME_DEVICE in stasis_cache_get by using the constructed eid+device that device state uses initially. |
| 21:38.49 | putnopvut | Same varied results. |
| 21:39.33 | file | I assume the state is known? |
| 21:39.45 | putnopvut | Yes. It starts as "Not in Use" |
| 21:39.52 | putnopvut | Unless ast_devstate2str() lies |
| 21:40.45 | file | I meant what are you passing to ast_devstate_changed_literal |
| 21:41.05 | putnopvut | AST_DEVICE_NOT_INUSE |
| 21:41.13 | file | yup yup |
| 21:42.02 | putnopvut | The thing is, at every level that I see, all of the publications that are occurring have no associated mailbox, so I'd expect the cache to be fully updated once the initial device state publication is made. |
| 21:51.00 | jmls | hmm. works now |
| 21:56.50 | mjordan | jmls: probably ASTERISK-19612 |
| 21:56.50 | CaptainPants | [ASTERISK-19612] [Status: Open] Asterisk crash with compiler flag LOW_MEMORY - https://issues.asterisk.org/jira/browse/ASTERISK-19612 |
| 21:57.06 | mjordan | you're probably just hitting it earlier on |
| 21:57.51 | jmls | certainly looks like it |
| 21:58.57 | jmls | never mind, it's working for me now without LOW_MEMORY (actually I'm sure that I didn't have it set in 10 either) |
| 21:59.08 | jmls | thanks for the help though. Appreciated |
| 22:14.51 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:14.54 | jmls | mmm |
| 22:15.56 | jmls | what could cause "ls -l /var/lib/asterisk/moh" to give me "total 0". Standard compile, core moh files selected in menuselect |
| 22:16.06 | jmls | is there an option to reinstall just moh ? |
| 22:56.49 | *** part/#asterisk-dev ehsjoar (~jonas@c-24-9-87-13.hsd1.co.comcast.net) |
| 23:11.48 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 23:13.12 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 23:25.56 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:25.56 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:48.43 | *** join/#asterisk-dev luckman212_ (~luckman21@unaffiliated/luckman212) |
| 23:51.53 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 23:51.53 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |