| 00:29.50 | *** join/#asterisk-dev suneye (~atcmmi@119.139.62.227) |
| 00:57.34 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 01:16.11 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 01:16.11 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:03.02 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 05:03.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:19.18 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:b9ef:fce0:8d41:c467) |
| 09:19.27 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 09:19.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:37.23 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:37.23 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:05.44 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 11:51.29 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:06.27 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 12:06.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:20.11 | *** join/#asterisk-dev serafie (~erin@user-24-214-173-250.knology.net) |
| 12:43.00 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 12:56.07 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-rzmpqemogzfixtli) |
| 13:04.50 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 13:19.37 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 13:21.30 | file | oh yeah yeah |
| 14:11.26 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 14:11.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:17.17 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-epjtebiiwxsggrsm) |
| 14:17.26 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-epjtebiiwxsggrsm) |
| 14:17.44 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-epjtebiiwxsggrsm) |
| 14:18.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:18.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:22.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-opsrhwsuqhysfigv) |
| 14:22.06 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:26.43 | snuff-home | putnopvut: your mention about multiple aco_types i think i hit something with that the other day.. or maybe slightly different.. |
| 14:27.16 | putnopvut | snuff-home: Yeah, basically I wanted to have two different objects, foo and bar, that are both configured in the general section. |
| 14:27.35 | putnopvut | But unfortunately, the config API expects that objects foo and bar each have their own configuration section. |
| 14:27.55 | putnopvut | I came up with a workaround that I expect will thoroughly be shat upon at code review time. |
| 14:28.21 | snuff-home | when making my ghetto attempts at cli cmds for res_sip.. i found that i had issue with 'sorcery apply default'.. |
| 14:28.53 | putnopvut | I'm kind of surprised you'd be calling that function from a CLI command. |
| 14:28.57 | snuff-home | in location.c.. it refers to 'contacts' as astdb stuff.. i couldn't also make it refer to file types |
| 14:29.11 | snuff-home | i'm not.. but it wasn't readin my config |
| 14:29.28 | snuff-home | <PROTECTED> |
| 14:29.28 | putnopvut | Did you try changing your sorcery config file? |
| 14:29.40 | snuff-home | i can't have THAT.. as well as |
| 14:29.48 | snuff-home | ast_sorcery_apply_default(sorcery, "aor", "config", "res_sip.conf,criteria=type=contact"); |
| 14:29.51 | snuff-home | oops.. |
| 14:29.57 | snuff-home | ast_sorcery_apply_default(sorcery, "contact", "config", "res_sip.conf,criteria=type=contact"); |
| 14:30.38 | putnopvut | Yeah, I think a default can only be applied once. The default can be overridden by changing your sorcery.conf file though. |
| 14:30.41 | snuff-home | so to make it see my contacts.. i had to just leave in my type=contact line and remove the astdb/registrar one.. |
| 14:31.06 | file | you can specify explicit contacts in the config file without any changes |
| 14:31.06 | snuff-home | if i didn't do it.. wouldn't read any contacts from res_sip.conf :( |
| 14:31.16 | file | they are put in the AOR |
| 14:31.38 | snuff-home | i thought that was only perm contacts? |
| 14:32.05 | file | I don't understand |
| 14:32.32 | snuff-home | if i have.. just a 'contact' entry in res_sip.conf.. it is not picked up as a contact object at all |
| 14:33.00 | snuff-home | aka.. [mycon] type=contact \n uri=sip://myuser@localhost |
| 14:33.04 | file | right |
| 14:33.28 | snuff-home | is there a really good reason why not ? |
| 14:34.12 | file | because sorcery doesn't allow you to have multiple default sources |
| 14:34.42 | snuff-home | i may throw up my 1st attempt at some redone cli cmds in coming days.. it works.. think i have useful summary fields.. |
| 14:35.12 | snuff-home | ok.. so you can NEVER define contacts EVER in res_sip.conf.. they must all register to a AOR? |
| 14:35.12 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-bzzsqymkhbfolapv) |
| 14:35.22 | file | you can override behavior in sorcery.conf |
| 14:35.33 | file | if you want to have contacts in the astdb, a realtime database, and flat-file - you can |
| 14:35.41 | file | but the default is astdb only |
| 14:37.25 | snuff-home | i guess.. if u have the 1 to 1 mapping for aor = 1 contact.. then u can live with just astdb.. you just can't pre-define contacts.. unless u format correct astdb entries? or allow sorcery.conf to have multi source |
| 14:37.39 | file | you can specify contacts in the aor |
| 14:37.43 | file | contact=sip:1000@bob.com |
| 14:38.09 | snuff-home | btw.. did anyone ever put forward a memcache module for storing stuff.. i know i have a branch kicking around that did most of it |
| 14:38.19 | file | nope |
| 14:39.09 | snuff-home | mm.. might look at reviving it.. though seems to have gone out of favour again.. damn cloud moves so fast :) |
| 14:41.13 | snuff-home | what's hip these days.. some forms of rabbit mq or 0mq.. |
| 14:42.14 | *** join/#asterisk-dev asilva (~asilva@2801:88:1000:2::12) |
| 14:43.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:43.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:46.38 | oej | Why does 1.8 have a LOG_WARNING that encrypted signalling is required? |
| 14:46.49 | oej | I think that's a debug log, but not a warning |
| 14:47.25 | putnopvut | That's funny. I can swear I've made calls in 1.8 without encrypted signaling. |
| 14:47.26 | mjordan | file: figured out what's going on with CDRs post-origination work. Apparently the ;1 of the Local channel isn't getting a CDR. I'm not really worried about that, because the CDR patch should take care of that, and it does look like all of the Stasis messages are occurring |
| 14:47.42 | file | mjordan, aye |
| 14:47.49 | mjordan | so, that's the two CDR failures |
| 14:47.57 | oej | ast_log(LOG_WARNING, "Encrypted signaling is required\n"); |
| 14:49.16 | oej | Ok to change? |
| 14:49.28 | snuff-home | gets some zz's |
| 14:49.46 | mjordan | well |
| 14:49.57 | oej | mjordan: I don't think it was strictrtp, the stuff I discussed last week. |
| 14:50.02 | mjordan | Still chasing it down, but it will only occur if the channel had AST_OPTION_SECURE_SIGNALING set on it |
| 14:50.19 | oej | SHould never be a warning though. |
| 14:50.35 | oej | ast_log(LOG_WARNING, "SRTP audio setup failed\n"); |
| 14:50.38 | oej | SHould be LOG_ERROR |
| 14:50.41 | Corydon76-home | Qwell: ping |
| 14:50.41 | oej | I think |
| 14:50.55 | oej | I'm really looking for other things, just following code. |
| 14:51.32 | mjordan | oej: maybe. It occurs if you use the CHANNEL function to require a secure bridge, and the channel requested can't/doesn't support TLS |
| 14:51.57 | oej | Isn't that an ERROR? If you require security and don't get it. The call should fail. |
| 14:52.06 | mjordan | I'm fine if that's an error |
| 14:52.49 | oej | ast_log(LOG_WARNING, "No audio format found to offer. Cancelling call to %s\n", p->username); |
| 14:53.04 | oej | I think the problem is bigger than I noticed. It's many messages that should be changed. |
| 14:53.18 | oej | Cancelling a call is an ERROR, not a warning. |
| 14:53.59 | mjordan | I think people have focused WARNING on things that are off nominal paths but that doen't affect Asterisk running. ERRORs have been used primarily to convey when something horrific has gone wrong |
| 14:55.09 | mjordan | so you'll probably find a lot of WARNING messages that are calls getting terminated due to an off nominal path. You'll also probably find some ERROR messages. |
| 14:57.58 | Qwell | Corydon76-home: If that's the same article I saw, it's silly, because it would require massively changing how we do things. We shouldn't, depending on when inlining happens, need any of that stuff - just attribute(cleanup). |
| 14:59.07 | Corydon76-home | Since it's just a macro, shouldn't that be sufficient? |
| 14:59.16 | Corydon76-home | It shouldn't massively change anything |
| 14:59.53 | Qwell | No, because you need to call the macro in different places, with the clang version, if I understood it correctly. |
| 15:01.39 | Corydon76-home | I think that's only necessary if you're running the error handler, right? |
| 15:01.59 | Corydon76-home | i.e. the exceptions part of it |
| 15:04.18 | Corydon76-home | But the basic idea is that Clang uses a cleanup block where gcc uses a nested function, but that should be the only difference. |
| 15:12.47 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 15:12.47 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 15:23.20 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 15:38.48 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 16:20.55 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 16:25.56 | mjordan | file: ping |
| 16:26.00 | file | PONGY |
| 16:26.45 | mjordan | I think pbx_outgoing_attempt is unbalanced in its channel locking |
| 16:27.13 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 16:27.14 | file | you'll have to be specific |
| 16:27.27 | mjordan | in trunk, see line 10070 |
| 16:28.01 | mjordan | that would be the first time we lock the channel. We unlock it if we're synchronous and we perform an ast_cond_wait, then relock the channel. |
| 16:28.06 | mjordan | but I don't see where we unlock the channel |
| 16:28.26 | file | that's because the function allows the channel to be returned locked |
| 16:28.45 | mjordan | hrm. |
| 16:29.10 | mjordan | at least one test appears to be failing due to this, but I'm still hunting it down |
| 16:29.24 | file | ack |
| 16:29.39 | file | if we want to break that API we can have it return a ref |
| 16:31.51 | file | leedm777, I like how I'm just doing stuff with stasis and it's working |
| 17:25.45 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 17:25.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:42.38 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 17:45.29 | leedm777 | file: i also like how things work the way they are supposed to. it's less surprisey that way. |
| 17:48.03 | file | sometimes I want surprisey, though! |
| 17:49.49 | leedm777 | file: here you go, then: http://media.screened.com/uploads/0/5125/466875-jokey_smurf.jpg |
| 17:50.11 | file | I refuse to click that |
| 17:50.21 | leedm777 | Your loss |
| 17:50.29 | mjordan | clicked |
| 17:51.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-mvqdtkrnrutpxvme) |
| 17:59.15 | opticron | A++++ would click again |
| 18:20.22 | *** join/#asterisk-dev serafie1 (~erin@nat/digium/x-urstlnwdhuezpiei) |
| 19:23.01 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yxedymornmxdeqhk) |
| 19:53.31 | pabelanger | Always wanted to know, does alwaysauthreject technically break the SIP RFC? |
| 19:53.39 | pabelanger | I thought I seen a thread about it on -users before |
| 20:07.55 | pabelanger | http://lists.digium.com/pipermail/asterisk-users/2011-July/265080.html |
| 20:07.58 | pabelanger | question answered |
| 20:08.16 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 20:08.16 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:08.56 | putnopvut | Yep, there's no place where an RFC says that if you send a 401 you must be prepared to actually verify an authentication attempt. |
| 20:09.21 | putnopvut | However, we are misrepresenting the real reason why the request was denied. |
| 20:09.35 | Qwell | Yes, that's the point. |
| 20:09.38 | putnopvut | exactly |
| 20:09.49 | Qwell | oh, I misread nicks. |
| 20:09.51 | putnopvut | heh |
| 20:10.14 | Corydon76-home | We could always change the textual reason to something more appropriate. |
| 20:10.22 | putnopvut | That would cause an information leak |
| 20:11.02 | Corydon76-home | Like "401 Something wasn't correct, but for the sake of security, we're not going to tell you what it was" |
| 20:11.10 | putnopvut | lol |
| 20:11.23 | mjordan | I think every 401 should have a random text string applied to it |
| 20:11.31 | putnopvut | 401 wsyaerafdakerwsaskd |
| 20:11.40 | mjordan | "401 gremlins" |
| 20:11.42 | Corydon76-home | Put a long enough reason in, and I'm sure we'd crash some client with a buffer overflow |
| 20:11.45 | putnopvut | That's not random! |
| 20:11.50 | mjordan | putnopvut: you don't know that |
| 20:11.53 | putnopvut | ...like chan_sip perhaps |
| 20:12.25 | mjordan | chan_sip: that awkward moment when you crash on a request sent from another Asterisk system |
| 20:12.51 | Qwell | mjordan: so, Tuesdays? :p |
| 20:15.04 | file | chan_sip is perfect |
| 20:16.27 | pabelanger | woah |
| 20:16.38 | pabelanger | that escalated quickly |
| 20:16.54 | pabelanger | Now I remember why I remember the thread, bruce bruce |
| 20:16.59 | pabelanger | Oh, I miss that guy |
| 20:17.23 | putnopvut | Was he "premium dailing minties" or was he someone else? |
| 20:20.37 | pabelanger | He was the guy always telling what digium should do |
| 20:20.43 | pabelanger | vs him actually doing the work |
| 20:21.00 | pabelanger | that thread from above is a classic Bruce Bruce |
| 20:21.15 | pabelanger | Security? Ya, that is a digium issue |
| 20:23.25 | putnopvut | pabelanger: I was thinking of "Info Info" :) |
| 20:23.58 | pabelanger | Double usernames FTW |
| 20:33.22 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 20:33.22 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 20:49.25 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 20:57.25 | file | <3s all the sorcery unit tests |
| 21:00.49 | putnopvut | just plain <3s sorcery |
| 21:02.02 | pabelanger | file: I approve of that message |
| 21:02.32 | pabelanger | Still need to fire up asterisk 12 and see all the new features |
| 21:18.13 | mjordan | opticron: ping - transfer_failure tests |
| 21:18.25 | mjordan | pabelanger: it's still a work in progress |
| 21:18.50 | opticron | mjordan, pong |
| 21:19.23 | opticron | are they exploding? |
| 21:20.53 | mjordan | it has been for quite some time |
| 21:21.06 | opticron | well :/ |
| 21:21.11 | opticron | I'll look into it |
| 21:21.16 | mjordan | what I'm trying to figure out is how it ever succeeded. The transfer fails, but when a transfer fails it just goes back to the bridge. The participants don't hang up |
| 21:21.41 | mjordan | opticron: part of it was the DTMFEnd event not being handled, which we kind of needed jbigelow's versioning patch for |
| 21:21.51 | opticron | ah |
| 21:22.21 | mjordan | opticron: but now the first transfer attempt and its digits are getting detected. The second one never fires however |
| 21:22.35 | opticron | the bridge config section hangs up the call when all feature tests are completed |
| 21:22.57 | opticron | it must not be getting confirmation that all the tests completed |
| 21:42.44 | mjordan | nope |
| 21:42.53 | mjordan | hm |
| 21:43.40 | mjordan | a test iteration occurs when channels have hung up, however |
| 23:05.51 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-opsrhwsuqhysfigv) |
| 23:23.46 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
