| 00:29.58 | *** join/#asterisk-dev acidfoo (~inetrio.c@unaffiliated/acidmen) |
| 04:14.15 | Kobaz | this is kind of wiggity wack |
| 04:14.25 | Kobaz | Program received signal SIGILL, Illegal instruction. |
| 04:14.33 | Kobaz | 0x081a94dd in timesub (timep=0xbf91f8dc, offset=-14400, sp=0x824d4d8, tmp=0xbf91fa84) at stdtime/localtime.c:1822 |
| 04:14.35 | Kobaz | 1822 seconds = tdays * SECSPERDAY + 0.5; |
| 04:32.27 | *** join/#asterisk-dev snuff-work (~blatus@203.63.71.233) |
| 04:32.27 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 05:36.54 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 05:36.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:18.52 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 06:18.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:30.33 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 06:43.24 | wedhorn | snuff-work: ping |
| 06:49.43 | snuff-work | hello wedhorn |
| 06:50.34 | wedhorn | hey, so how's skinny treating you (notice you've been doing a fair bit of playing with gulp lately) |
| 06:50.40 | snuff-work | did a skinny test other day.. blew ast up.. set dnd to 'on' on phone and rang it.. went boom |
| 06:51.49 | wedhorn | yeah, think I know about that one. Had some of my devices limited to a single call, when a new call came that was rejected came in, similar boom |
| 06:52.32 | wedhorn | apart from that, do things seem to be working? |
| 06:57.43 | snuff-work | ok atm.. |
| 06:58.05 | snuff-work | i will get a pcap for the 7937 |
| 06:58.15 | snuff-work | for reload with speedial stuff |
| 06:59.08 | wedhorn | okay. Been busy with other stuff for a while. Got a bit of time now so thought I should get some of the stuff committed |
| 06:59.36 | wedhorn | but I think some of the patches on jira are incomplete |
| 07:03.45 | snuff-work | most likely.. |
| 07:08.31 | wedhorn | snuff-work: when you get a chance, can you send me the diffs that you're running |
| 07:08.39 | snuff-work | sure |
| 07:09.02 | wedhorn | thanks |
| 07:09.12 | wedhorn | should be able to work it out from there |
| 07:11.36 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1006) |
| 07:11.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:12.01 | oej | Morning folks |
| 07:12.07 | snuff-work | ello oej |
| 07:12.36 | oej | How's life, snuff-work? |
| 07:12.59 | snuff-work | busy busy.. internal vmware migrations |
| 07:19.34 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:14de:f2f8:77d5:8fce) |
| 07:23.03 | snuff-work | might take my laptop home tonight work on my doco for res_sip |
| 07:32.18 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:32.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:07.06 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 08:07.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:16.21 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 08:16.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:50.05 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:50.05 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:50.22 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 11:12.40 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 11:27.59 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 12:06.08 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:14de:f2f8:77d5:8fce) |
| 12:47.07 | oej | Afternoon folks |
| 12:55.40 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-subuzpxnbjrmdiwe) |
| 13:31.21 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mlfghuhyezpepeyc) |
| 13:31.21 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:40.07 | oej | Hi Matt! |
| 13:40.36 | oej | By starting the DNS work in pgtips, I seem to have stumbled upon a whole set of issues. |
| 13:40.49 | oej | ASTERISK-18353 |
| 13:40.50 | LieutPants | [ASTERISK-18353] [Status: Reopened] SIP registration doesn't use round-robin DNS. - https://issues.asterisk.org/jira/browse/ASTERISK-18353 |
| 13:40.54 | oej | ASTERISK-21752 |
| 13:40.55 | LieutPants | [ASTERISK-21752] [Status: Triage] Asterisk peers with host=<dnsname> doesn't accept calls from host - https://issues.asterisk.org/jira/browse/ASTERISK-21752 |
| 13:40.59 | oej | And http://www.dslreports.com/forum/r23342155-Another-asterisk-question |
| 13:41.12 | oej | We need to figure out what parts of this that are bugs and what's new features. |
| 13:41.38 | oej | And make sure chan_gulp_sip_pineapple.c has proper support of it. |
| 13:45.15 | mjordan | looks |
| 13:47.09 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pjhsjbrtkukeyjpi) |
| 13:47.48 | mjordan | ASTERISK-18353 I'd treat as an improvement for the most part. There's no question that Asterisk's DNS support is "limited", and changes there are probably going to have ripple effects. If there's a way to modify the REGISTER request portion without impacting the actual DNS layer, then that portion could be treated as a bug (or at least, a workaround) |
| 13:47.48 | LieutPants | [ASTERISK-18353] [Status: Reopened] SIP registration doesn't use round-robin DNS. - https://issues.asterisk.org/jira/browse/ASTERISK-18353 |
| 13:48.25 | mjordan | looks at the next one |
| 13:49.09 | oej | I agree that we have a lot of known issues so most of it is improvements. |
| 13:49.15 | mjordan | ASTERISK-21752 is definitely an improvement. See "Asterisk DNS support is less than stellar". Although, making Asterisk parse multiple DNS SRV records isn't the hard part, it's making use of it - which ASTERISK-21752 implies |
| 13:49.15 | LieutPants | [ASTERISK-21752] [Status: Triage] Asterisk peers with host=<dnsname> doesn't accept calls from host - https://issues.asterisk.org/jira/browse/ASTERISK-21752 |
| 13:49.39 | oej | But I kind of think that the issue of definiing host="serviceproviderdomain.com" should work more as expected... |
| 13:49.43 | mjordan | unless I'm misconstruing what David was implying in 21752 |
| 13:49.54 | oej | It could just be me feeling bad reading all the reports on the web. |
| 13:50.03 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:50.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:50.04 | mjordan | oej: no, I get hammered with it too |
| 13:50.40 | mjordan | but it's the balance between wishing Asterisk could parse and process multiple addresses for a DNS record, and not blowing up existing systems |
| 13:50.47 | oej | The fun part with 21752 is that I came up with that all by myself looking at the code thinking "this is how it should work" and added it to the README, Then I found that bug report. |
| 13:50.54 | mjordan | lol |
| 13:51.00 | oej | It has to be optional. |
| 13:51.44 | oej | I mad a bad mistake telling my customer that fixing SRV was just three days of work. I have working SRV outbound now, but no failover yet and no peer matching. |
| 13:51.57 | oej | I have an ACL for peer matching and will start messing with the peer list. |
| 13:51.58 | mjordan | ideally, chan_sip would attempt to send to a host, and try it on the first IP address. If that fails, it would fall back to the next record for the host, etc. That's the part that scares me |
| 13:52.04 | mjordan | oej: :-( |
| 13:52.43 | oej | I handle IPv6/IPv4 already. If the first priority hosts only has IPv6 and I only have IPv4, I continue until I find IPv4. |
| 13:52.52 | oej | That's a good start. Now I need to connect and fail over. |
| 13:53.10 | oej | the SIP dialog and the SIP peer now have the full SRV list stored. |
| 13:53.35 | oej | DNSmanager is soo broken that I'm working around it just now. Having TTLS of our own is bad. |
| 13:53.51 | mjordan | and yeah, I think the forum post hints at why solving ASTERISK-18353 only for REGISTER requests will still run into problems. Nuts. |
| 13:53.52 | LieutPants | [ASTERISK-18353] [Status: Reopened] SIP registration doesn't use round-robin DNS. - https://issues.asterisk.org/jira/browse/ASTERISK-18353 |
| 13:54.16 | oej | Using round robin DNS in SIP doesn't really give failover as they expect. |
| 13:54.26 | mjordan | oej: I suspect that when dnsmanager was written - which was a long time ago - it was working around a lot of problems that don't exist now |
| 13:54.28 | oej | It's something that has been used for old clients. |
| 13:54.42 | oej | DNS failover that is. |
| 13:54.46 | oej | sorry DNS rr |
| 13:54.51 | oej | Me confused. |
| 13:55.12 | oej | But I think we will have to implement an option to include the full set of IPs in a DNS round robin set in the ACL for peer matching. |
| 13:55.24 | oej | I don't think this customer will bother paying for that though. |
| 13:55.57 | mjordan | I think a lot of things would want to treat DNS as an opaque layer that handles the records for them |
| 13:57.28 | oej | How do you mean? |
| 13:58.41 | mjordan | well, this is all pretty much impossible with chan_sip's current architecture (or chan_iax, for that matter) - but if you specify 'host=foo.com', you don't really want to know when you send a request to foo.com that it used to be at xxx.xxx.xxx.xxx and is now at xxx.xxx.xxx.xxy. You want that to be handled by what transport layer is actually doing the retransmits and keeping track of this stuff for you |
| 13:59.15 | oej | Right. |
| 13:59.16 | mjordan | with their current design, you'll end up with great DNS handling in chan_sip and crap DNS handling everywhere else, because they've re-invented the transport wheel over and over again |
| 13:59.51 | oej | Well, it turned out that the func_srv work had opened up a bit of the API. I just made a few small changes to that part. |
| 14:00.12 | mjordan | to some extent, we've only partially resolved that problem with the new SIP work. While pjproject does a nice job of abstracting things out the transport layer so that you can add new transports, you can't really 'share' the transports |
| 14:00.18 | mjordan | oej: nice |
| 14:00.27 | oej | It seems to have turned even messier with IPv6 patches. There are functions in chan_sip that doesn't belong there for DNS handling. |
| 14:00.34 | oej | And we have some in acl.c that doesn't belong there. |
| 14:01.00 | oej | I wonder if we should clean that up a bit. |
| 14:01.13 | oej | I could open a group branch for just moving stuff around without changing the code. |
| 14:01.22 | mjordan | oej: that'd be beneficial |
| 14:01.27 | oej | It irritates me when things are too messy. |
| 14:01.37 | oej | Ok, I'll do that and we'll work on it together. Shouldn't take long. |
| 14:02.15 | mjordan | eek - you're drawing me into DNS land :-P |
| 14:02.25 | oej | Much better than CDR land. |
| 14:02.35 | oej | Correction: Slightly better |
| 14:02.37 | mjordan | marginally, and I'm still partially stuck there :-D |
| 14:03.30 | mjordan | oh for the love of pete. Fire drills. |
| 14:04.09 | oej | Ouch. |
| 14:25.07 | oej | https://issues.asterisk.org/jira/browse/ASTERISK-17722 seems to be a clear bug opened in April 2011 |
| 14:25.08 | LieutPants | [ASTERISK-17722] [Status: Open] SIP SRV lookups for registration discard the port when dnsmgr disabled (the default) - https://issues.asterisk.org/jira/browse/ASTERISK-17722 |
| 14:29.10 | mjordan | yup |
| 14:44.48 | oej | Like I said, a can of worms. |
| 14:45.22 | oej | I see a few closed feature requests on SRV records as well. I haven't worked with the bug tracker for a long time, but if I had, I would have read the signs earlier. |
| 14:45.24 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:45.27 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:16.09 | file | mjordan, oh dear me CDRs |
| 15:31.30 | mjordan | did you take a look at the review? |
| 15:38.25 | file | Yes. I like it. |
| 15:38.42 | file | The amount of code removed from places makes me happy. |
| 15:43.04 | mjordan | in all honesty, I'm not sure the complexity is less. But it's certainly not sprinkled everywhere |
| 15:45.17 | file | Aye |
| 16:41.42 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 16:46.15 | mjordan | gr. Silly utils |
| 16:47.41 | opticron | silly indeed |
| 16:48.54 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-105-205-226.user.veloxzone.com.br) |
| 16:50.59 | Qwell | How much of the stuff in there, that has the wackiness, do we actually need? |
| 16:58.26 | mjordan | I have a feeling ael still uses a fair amount of it. |
| 16:58.28 | mjordan | refcounter is useful |
| 16:58.36 | mjordan | astcanary is obviously used a lot |
| 16:58.39 | mjordan | astman ... meh. |
| 16:58.45 | Qwell | astcanary doesn't have crap, neither does astdb stuff |
| 16:59.05 | mjordan | no. The real problem is that it all exists outside of the normal build system. I have a feeling that AEL imposes a lot of the problems. |
| 17:03.27 | Qwell | for AEL, res/ stuff doesn't depend on util/ - util/ stuff depends on res/. The AEL utils aren't really used much. |
| 17:03.55 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 17:03.55 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 17:22.36 | *** join/#asterisk-dev Devon_ (~Devon_@63.214.236.169) |
| 17:24.04 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 17:24.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:26.32 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1003) |
| 17:26.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:57.45 | Qwell | <PROTECTED> |
| 17:57.47 | Qwell | whistles |
| 18:03.42 | pabelanger | do Yankee Doddle Dandy next! |
| 18:46.33 | mjordan | Qwell: madness |
| 18:46.45 | Qwell | mjordan: You don't even know the half of it. |
| 18:46.53 | mjordan | no, I do. I've stared into extconf before. |
| 18:47.02 | mjordan | And it stared right back at me |
| 18:47.07 | Qwell | Do we actually care? |
| 18:47.16 | Qwell | If you want to test your configs...reload Asterisk. |
| 18:48.43 | Qwell | anyways, just a lunch proof of concept. No big loss, either way. |
| 18:51.09 | pabelanger | Qwell: what are you testing? |
| 18:53.51 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 18:57.10 | Qwell | pabelanger: not testing anything |
| 18:57.56 | pabelanger | s/testing/working on |
| 18:58.17 | Qwell | killing utils/ |
| 18:59.23 | pabelanger | I see |
| 19:23.37 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:23.38 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:29.15 | mjordan | is there nothing RAII_VAR can't do |
| 20:34.20 | snuff-home | be compiled by clang? |
| 20:45.12 | putnopvut | zing! |
| 20:54.18 | mjordan | snuff-home: touche |
| 20:54.22 | *** join/#asterisk-dev sputnik_too (~sputnik@funtoo/user/sputnik-too) |
| 21:03.47 | mjordan | opticron: leedm777: are channels keyed by name or uniqueid in the stasis cache? |
| 21:03.54 | leedm777 | uniqueid |
| 21:03.57 | mjordan | gracias |
| 21:04.01 | leedm777 | de nada |
| 21:16.10 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 21:16.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:39.34 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mlfghuhyezpepeyc) |
| 22:17.55 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:17.55 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:08.07 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |