| 00:17.48 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 00:17.48 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 00:33.35 | snuff-work | wedhorn: found somethin else slightly anonying.. will see if i can fix.. (related to the showing of 'Unknown') |
| 00:34.15 | snuff-work | aka if u have 'missed calls'.. u dont see the 145 text saying number/unknown |
| 00:34.40 | snuff-work | doesn't matter too much since its in huge text above it.. but we'll see |
| 00:40.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:40.41 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:05.18 | *** join/#asterisk-dev jdoe (jdoe@falseprophet.ca) |
| 01:15.52 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 01:15.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 01:49.51 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 01:59.59 | wedhorn | snuff-work: are you meant to see it? ie can you see it on devices connected to ccm? |
| 02:00.15 | snuff-work | yes otherwise wouldn't care :) |
| 02:01.01 | wedhorn | okay, it's probably displayed with a 144 rather than a 145 message then |
| 02:01.26 | snuff-work | mm maybe.. i still have my 144 scrap around |
| 02:01.32 | wedhorn | 145 is associated with a specific call, 144 is the general prompt (I think) |
| 02:02.53 | snuff-work | so.. '1 missed call displayed' .. inbound call 'swaps to phone number' (on ccm).. ast.. '1 missed call' inbound call '1 missed call' still displayed while ringing |
| 02:02.59 | wedhorn | if you use 144, you'll probably need to then clear it so the 145's will be displayed |
| 02:03.35 | snuff-work | course if u have 0 missed.. then u get the number as u expect.. |
| 02:03.39 | wedhorn | for a test, just change the 145 to type 144 and see what it does |
| 02:03.51 | snuff-work | implemented ur 'unknown suggestion' for 145 will repost soon |
| 02:04.02 | wedhorn | ah, bugger, you'll need to remove the callRef as well |
| 02:04.16 | snuff-work | working on diversion dp |
| 02:05.46 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:05.46 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:05.50 | snuff-work | we migt just be missing a clear |
| 02:07.16 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 02:07.21 | wedhorn | don't remember seeing any clears at the beginning of a call |
| 02:07.29 | snuff-work | dont particularly care though.. |
| 02:07.39 | wedhorn | but maybe |
| 02:07.43 | wedhorn | up to you |
| 02:08.47 | snuff-work | looking over a ccm pcap.. there is no clear.. |
| 02:14.02 | wedhorn | look for the 144 and 145 being sent together |
| 02:14.10 | snuff-work | i see them |
| 02:14.53 | wedhorn | The first group is the same contents (sans callRef) |
| 02:15.03 | wedhorn | How about the second group? |
| 02:15.46 | snuff-work | basically.. for a 144.. i have 2x uint32 + dialnumber array.. |
| 02:15.52 | snuff-work | as my guess |
| 02:17.30 | snuff-work | in my 144 func i basically copied the func of 145.. minus the callref setting etc |
| 02:17.45 | wedhorn | snuff-work: that sounds right |
| 02:18.30 | wedhorn | you should be able to copy all the 145, change 145 to 144, remove callRef, and it should work |
| 02:18.34 | snuff-work | the uints are always 0a and 05.. the rest is as per 145 string set (octal+string) |
| 02:18.34 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 02:18.34 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:19.01 | wedhorn | I think they're the same as the 145 uints |
| 02:19.12 | wedhorn | ie, we can just set then to 0 |
| 02:20.30 | wedhorn | actually, think I'd need to look at some pcaps |
| 02:20.43 | snuff-work | i will start with the 'correct' version :) |
| 02:20.58 | wedhorn | one of them may be lineInst |
| 02:21.02 | snuff-work | nope |
| 02:22.01 | snuff-work | its a more 'global' one.. |
| 02:22.39 | snuff-work | as the numbers dont line up vs 145 |
| 02:22.50 | snuff-work | there is no line-inst/callref |
| 02:24.55 | wedhorn | okay, agree. Try 0a/05, seems the same as a pcap I've got |
| 02:25.03 | wedhorn | Maybe the |
| 02:25.16 | wedhorn | 're a time (10 seconds = 0a?) |
| 02:26.34 | snuff-work | no idea.. |
| 02:27.41 | wedhorn | call a ccm device with missed calls and see if the missed calls text reappears after 10 seconds of ringing |
| 02:29.28 | snuff-work | yep seems a fast 10 sec.. but might be right.. maybe its the 5.. not a0 |
| 02:30.14 | wedhorn | possible, anything change at 10 secs? |
| 02:31.12 | snuff-work | mm.. i think the 10 is right.. doing 1 more check |
| 02:31.54 | wedhorn | so 1 of the uints is probably a timeout |
| 02:31.57 | wedhorn | cool |
| 02:32.15 | snuff-work | ok.. it is 10 sec |
| 02:32.49 | snuff-work | but course that is from the second its dialed.. so sometimes it can hang around longer |
| 02:32.59 | snuff-work | if u dialed for like 2 sec n hangup |
| 02:33.20 | snuff-work | it will show 'from 3202' etc for 8 more sec on phone |
| 02:41.11 | wedhorn | okay, guess that's a cisco bug then. Not much we can do about that |
| 02:41.32 | snuff-work | yeah but it confirms that the a0 = timeout :) |
| 02:42.00 | wedhorn | was thinking, guessing, maybe the other is a priority, ie, higher priority messages are displayed |
| 02:42.15 | wedhorn | yep, agree that a0 looks like a timeout |
| 02:42.57 | wedhorn | maybe missed calls has priority 0 with a timeout of 0 (set internally on the device of course) |
| 02:43.37 | wedhorn | the from message has priority 5, timeout 10, so trumps missed calls for 10 secs |
| 02:43.57 | wedhorn | but suppose we need a working 144 implementation to play around with that ... |
| 02:44.06 | snuff-work | mm well i have most of it ready.. |
| 02:44.41 | snuff-work | but need to do other stuff now.. might be in my frantic 20 min from around 5:50 |
| 02:44.49 | snuff-work | or i can send u what i have atm |
| 02:48.42 | wedhorn | you can send it, not sure that i'll have time to play with it, see what happens. Also need to make sure this stuff flows on to the <v17 stuff |
| 02:52.18 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:52.19 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:52.21 | snuff-work | i will add it to that issue |
| 02:53.53 | snuff-work | btw.. ur DB() getting error when there was nothing set.. if its only 1 value u care about then u just put ur db call in quotes and ur wanted result in quotes.. then doesn't matter if value doesn't exist :) |
| 02:54.56 | snuff-work | aka like most of my calls atm.. gotoIf($["{DB(blah/one)}" = "2"]?this:that) |
| 03:02.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 03:02.08 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:07.52 | snuff-work | mm.. seems ast doesn't like blank vars either trying to do math on em :) |
| 03:09.35 | snuff-work | wedhorn: found 1 other thing.. seems if other side hangs up on a call u make.. they won't show in ur dialed num (arrow down list) |
| 03:16.13 | wedhorn | hey, thanks for the db heads up |
| 03:16.37 | wedhorn | when you say the other side hangs up, you mean rejects the call? |
| 03:16.59 | snuff-work | nope.. as in they accept call talk for a while.. they hangup before u |
| 03:17.11 | snuff-work | u get nada msg in ur phone |
| 03:17.36 | wedhorn | okay, we must be missing a part of the hangup sequence if called from internally, will have a look |
| 03:18.00 | snuff-work | did a little compare of debug packet sub.. |
| 03:18.10 | snuff-work | seems close.. |
| 03:18.50 | snuff-work | only diff i noticed was 'dumping' twice.. of sub |
| 03:19.11 | snuff-work | and 1 extra DEFINETIMEDATE_MESSAGE |
| 03:28.19 | wedhorn | snuff-home: seems to be skinny to skinny calls only. I tested calls from skinny to sip, and the calls get logged irrespective of who hangs up |
| 03:30.11 | snuff-work | mm.. i think that is because u probably still have the 'dialed number' for any proto version |
| 03:30.28 | wedhorn | actually scratch that. Make a call from my v17 to another skinny device, hang up the other device and the call is in the placed calls log |
| 03:30.40 | wedhorn | possibly |
| 03:31.11 | wedhorn | i'm running trunk with my serviceURL patch |
| 03:31.32 | snuff-work | i guess if i disable my check it will work correctly.. |
| 03:34.29 | *** join/#asterisk-dev bOOinK[DK] (~quassel@79.138.248.254.bredband.3.dk) |
| 03:37.44 | wedhorn | not sure, I'm seeing some issues with my <v17 devices about logging place calls |
| 03:40.59 | wedhorn | worse, intermittent. Seems to be working fine now |
| 03:41.47 | wedhorn | Still seems weird that you get different results depending on who hangs up. We must be doing something wrong somewhere |
| 03:42.16 | snuff-work | mm |
| 03:44.57 | wedhorn | what takes precedence, == or && |
| 03:45.43 | snuff-work | == |
| 03:46.04 | snuff-work | http://en.cppreference.com/w/c/language/operator_precedence |
| 03:53.44 | wedhorn | damn there's some whacky stuff in there |
| 03:53.51 | wedhorn | try this is set_substate |
| 03:54.19 | wedhorn | if (actualstate == sub->substate) { |
| 03:54.19 | wedhorn | send_callinfo(sub); |
| 03:54.19 | wedhorn | transmit_callstate(d, l->instance, sub->callid, SKINNY_HOLD); |
| 03:54.19 | wedhorn | return; |
| 03:54.19 | wedhorn | } |
| 03:54.50 | snuff-work | set_substate.. doesn't exist |
| 03:54.51 | wedhorn | on the second time through, actualstate and sub->substate will be both ONHOOK |
| 03:55.02 | snuff-work | line no ? |
| 03:55.03 | wedhorn | sorry, setsubstate |
| 03:55.21 | wedhorn | about 5360 |
| 03:55.22 | snuff-work | got it |
| 03:55.29 | snuff-work | 5207 on mine ;) |
| 03:55.51 | wedhorn | sorry, I mean the bit I referenced, not setsubstate |
| 03:56.07 | wedhorn | I must have had too many beers when I wrote that bit |
| 03:56.38 | snuff-work | ah k.. the bit just above the 'case SUBSTATE_OFFHOOK' ? |
| 03:56.48 | wedhorn | yep |
| 03:57.35 | snuff-work | but mine already reads like that |
| 03:57.42 | wedhorn | but you said there were no additional packets (bar a datetime - which is part of handle_onhook) |
| 03:58.05 | wedhorn | sorry, I was pointing out the whackiness |
| 03:58.43 | wedhorn | is a callstate HOLD sent at the end of the call when dumpsub is called twice? |
| 04:00.12 | snuff-work | nope.. just.. sub xx - dumping... sub xx - change state from connected to onhook.. whole series of 'transmitting.' then sub xx - dumping.. sub xx -destroying |
| 04:01.23 | wedhorn | ah yeah okay, bails from setsubstate right at the top on the second loop through ... |
| 04:09.44 | wedhorn | I can't see what's different in what's sent to the device (except the datetime packet) |
| 04:11.45 | wedhorn | either way should run through setsubstate(ONHOOK) and emit the same packets (some differences internally, like not queueing a hangup if being called from a hangup) |
| 04:57.45 | *** join/#asterisk-dev moy (~moy@unvlon55-1176057127.sdsl.bell.ca) |
| 05:45.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 05:45.27 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:07.33 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 06:37.49 | *** join/#asterisk-dev studybot_ (~studybot_@gateway/tor-sasl/studybot/x-68286794) |
| 06:47.51 | snuff-work | wedhorn: 144 success :) |
| 06:48.14 | wedhorn | cool |
| 06:50.58 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:50.59 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:51.29 | oej | Good morning folks |
| 06:52.17 | wedhorn | says morning, while having a swig of beer |
| 06:53.04 | oej | That seems like an early beer |
| 06:53.25 | wedhorn | i don't know, it's 5:55 |
| 06:53.32 | oej | he he |
| 06:53.45 | wedhorn | snuff's about to call it quits for the day |
| 06:54.08 | wedhorn | and today was a shit of a day, so beer required |
| 06:54.19 | snuff-work | still have the saga of missing placed :( |
| 06:54.50 | wedhorn | yeah, I'll have to try replicate that and see if I can see anything |
| 06:55.12 | snuff-work | i will do 1 more rebuild without my vers check for dialed num |
| 06:56.08 | wedhorn | whatever you do, don't through out the patch that causes the different handling. There is an underlying problem that should be identified |
| 06:56.27 | snuff-work | atm just commenting stuff |
| 06:58.21 | snuff-work | yer.. makes no diff atm.. call not logged even with the extra dialed number put in |
| 06:58.40 | snuff-work | u can even just do it via a like 'answer/playback/hangup' extension |
| 06:59.27 | wedhorn | okay, sounds like something weird |
| 07:00.25 | wedhorn | you haven't changed anything else except as per jira and the 144 packets? |
| 07:00.41 | wedhorn | silly point, have you hard rebooted the phone |
| 07:01.44 | snuff-work | i just have now |
| 07:02.21 | wedhorn | do yours take a couple of minutes to come back up? |
| 07:02.34 | snuff-work | at least 1-2 |
| 07:03.02 | wedhorn | yeah, bugger of things, the 7960 is probably only 15-20 secs |
| 07:05.24 | snuff-work | ok the only changes in my skinny atm are.. the 144 packet and the 145 minor alt.. and the fragment warning |
| 07:09.41 | snuff-work | sent u what i have for the 144/145 minor update |
| 07:11.22 | wedhorn | okay, the 145 edit is as per your jira bug? |
| 07:11.35 | snuff-work | from what i recall |
| 07:11.44 | wedhorn | looks about the same |
| 07:12.13 | snuff-work | i'm missing changes in the variable parts |
| 07:12.38 | wedhorn | yep, you've just got the last block |
| 07:12.52 | wedhorn | 2 blocks even |
| 07:13.06 | snuff-work | i kinda went on a del spree.. i can resend |
| 07:13.15 | wedhorn | no worries |
| 07:13.25 | wedhorn | how's your callsMade log? |
| 07:14.02 | wedhorn | (we really want to do 144 as a separate bug anyway) |
| 07:16.12 | snuff-work | placed is same as my dropdown list.. |
| 07:16.26 | snuff-work | aka if person hangs up on us.. call is not there |
| 07:17.02 | snuff-work | wait now it is.. |
| 07:17.03 | wedhorn | okay, I'll apply the patch you sent and see if I get the same results |
| 07:17.08 | wedhorn | ah... |
| 07:17.24 | snuff-work | this is for a skinny to sip call |
| 07:17.29 | snuff-work | sip hangs up |
| 07:17.40 | snuff-work | for skinny to dp only.. nothing logged |
| 07:17.51 | wedhorn | dp? |
| 07:17.56 | snuff-work | dial plan |
| 07:18.06 | wedhorn | okay |
| 07:18.07 | snuff-work | aka answer() -> playback -> hangup |
| 07:18.16 | wedhorn | okay, will try that |
| 07:18.30 | snuff-work | but i have also re-enabled the sending of 'dialed number' for proto > 16 |
| 07:19.21 | snuff-work | gotta go as usual now :) |
| 07:19.39 | wedhorn | no worries |
| 07:19.49 | wedhorn | I'll leave a message here and what happens |
| 07:20.21 | snuff-work | k will probably check late tonight.. as wil be out |
| 07:20.50 | wedhorn | okay, answer then hangup results in no call logged on my 7961 |
| 07:20.59 | wedhorn | but do get a call logged on my 7960 |
| 07:21.23 | snuff-work | ur 60 would def be using the original callinfo + dialed num |
| 07:21.27 | wedhorn | yep |
| 07:21.27 | snuff-work | *gone* |
| 07:21.32 | wedhorn | but it's a start |
| 07:21.41 | *** join/#asterisk-dev schmidts (~schmidts@vie-188-118-255-190.dsl.sil.at) |
| 07:21.43 | schmidts | good morning |
| 07:22.52 | wedhorn | snuff-home: for later tonight, that's without your patches. Just trunk and serviceURL |
| 07:23.14 | wedhorn | morning schmidts |
| 07:37.23 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 07:37.23 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:58.53 | wedhorn | snuff-home: I think I found at least one of the issues, you may have two. When we use answer in the dialplan, SUBSTATE_RINGOUT is skipped and so we dont send the SKINNY_PROGRESS to the device. Hence on v17, the device doesn't log the call (see bug https://issues.asterisk.org/jira/browse/ASTERISK-20964) |
| 08:07.59 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:19.32 | *** join/#asterisk-dev studybot_ (~studybot_@gateway/tor-sasl/studybot/x-68286794) |
| 08:59.16 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1004) |
| 08:59.16 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:21.25 | *** join/#asterisk-dev oej (~Adium@2001:16d8:cc57:1000::42:1001) |
| 09:21.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:15.31 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:15.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:59.50 | *** join/#asterisk-dev schmidts (~schmidts@vie-91-186-159-076.dsl.sil.at) |
| 11:23.39 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:23.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:20.59 | acidfoo | hi snuff-home |
| 12:29.06 | acidfoo | have you ever played with GListen on a 7905 |
| 12:53.49 | snuff-home | nope |
| 12:54.12 | snuff-home | i have used a 7905 before |
| 13:03.01 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 13:03.20 | oej | Afternoon sirs |
| 13:04.24 | *** join/#asterisk-dev Rico29 (~rico@oceanet-telecom-fttb-129-2.olm.fr) |
| 13:04.27 | Rico29 | hi people |
| 13:05.07 | Rico29 | I don't know if it's the right place, but I have a warning in the asterisk CLI when using odbc voicemail messages |
| 13:05.14 | Rico29 | [Feb 13 14:02:04] WARNING[7668]: app_voicemail.c:3468 retrieve_file: SQL Get Data error! coltitle=category |
| 13:05.14 | Rico29 | [SELECT * FROM AST_voicemail_messages WHERE dir=? AND msgnum=?] |
| 13:33.59 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 13:43.30 | *** join/#asterisk-dev mwally (~mwally@mwally.opencnam.com) |
| 13:55.17 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-eyaqmdnfaceszbnx) |
| 14:17.45 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:17.45 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 14:24.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ygmncqqiijdthqmd) |
| 14:24.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:44.12 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:44.12 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:56.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:56.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:12.30 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 15:50.47 | tzafrir | mjordan, could you please add kharwell to the authors file in repotools? |
| 15:51.06 | tzafrir | (a missing author breaks my git-svn mirroring) |
| 15:52.12 | mjordan | tzafrir: blech, I had it in there and forgot to commit it |
| 15:52.14 | mjordan | sorry about that |
| 15:53.51 | tzafrir | Great. Thanks. Git mirror now up to date |
| 16:05.35 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:05.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:49.30 | mjordan | Qwell: https://code.asterisk.org/code/browse/asterisk-pjproject |
| 17:16.34 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:16.34 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:23.20 | pabelanger | https://github.com/pabelanger/pjproject for a import that preserves the subversion history |
| 17:24.34 | pabelanger | I also emailed the pjsip mailing list to see if they wanted an official mirror on github, but sadly no feedback |
| 17:55.44 | *** join/#asterisk-dev rmeyerriecks (~rmeyerrie@nat/digium/x-vvpolrdmpsmnnzxo) |
| 17:56.24 | rmeyerriecks | seanbright: ping |
| 18:12.19 | seanbright | rmeyerriecks: ping |
| 18:12.25 | seanbright | protocol error... |
| 18:12.27 | seanbright | PONG |
| 18:12.36 | rmeyerriecks | seanbright: was going to take the discussion to irc but you already answered :-p |
| 18:12.47 | seanbright | gotcha |
| 18:13.11 | seanbright | am i right though that without help from mindspeed this will always be a problem? |
| 18:13.41 | rmeyerriecks | seanbright: assuming it's not a driver bug that I'm missing, yes we don't know why the device returns that error code sometimes |
| 18:13.52 | seanbright | do you know what the error means? |
| 18:14.23 | rmeyerriecks | does anybody really know what anything /really/ means? |
| 18:14.30 | seanbright | touche |
| 18:15.24 | rmeyerriecks | According to mindspeed it means "You are trying to create a channel on the timeslot which is already in use or the number of timeslot is invalid" |
| 18:16.58 | seanbright | i haven't looked too closely at the driver source but i would assume that is an unlikel |
| 18:17.01 | seanbright | y |
| 18:19.22 | seanbright | that sentence was awful - i'm assuming that because it works 99.9% of the time, there is something wrong with their chip and not with your driver. |
| 18:20.56 | rmeyerriecks | indeed |
| 18:21.33 | seanbright | here is where is how my ignorance - does their chip have replaceable firmware? |
| 18:21.42 | seanbright | wow i can't type for shit today |
| 18:25.17 | rmeyerriecks | seanbright: Yes |
| 18:26.23 | seanbright | but you no longer get updates? |
| 18:27.00 | rmeyerriecks | afaik |
| 18:27.16 | seanbright | hmm |
| 18:27.25 | seanbright | i enourage digium to up their support contract :D |
| 18:29.26 | rmeyerriecks | I agree but again, not really positive where the fault lies |
| 18:29.35 | seanbright | your code is perfect |
| 18:29.51 | seanbright | shaun told me |
| 18:30.28 | rmeyerriecks | sruffell has never said anything negative about my code, not once, ever |
| 18:30.54 | seanbright | i told him you should get a raise. he said he would speak to the right people. |
| 18:30.57 | seanbright | whatever that means. |
| 18:33.50 | rmeyerriecks | seanbright: haha, if that happens i'll have to send you a beer |
| 18:38.02 | file | raises for none! cookies for some! |
| 18:38.46 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:38.46 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 18:54.55 | seanbright | it tzafrir's asterisk git mirror public? |
| 19:02.35 | seanbright | rmeyerriecks: tip of dahdi linux safe? |
| 19:03.24 | seanbright | i should restate that in a way that you can answer it... is the latest revision in the master branch of dahdi linux on git.asterisk.org safe for production in your estimation? |
| 19:06.05 | rmeyerriecks | seanbright: We strive to keep the trunk of dahdi in a good state. I wouldn't run trunk unless you have a specific reason to use a patch that's on it, but yes I would run it in production if needed |
| 19:18.18 | seanbright | good enough for me |
| 19:18.30 | seanbright | as long as core timing and the tc400b work, i'm good |
| 19:41.14 | *** join/#asterisk-dev serafie1 (~erin@76.73.167.231) |
| 20:01.36 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 20:01.37 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:03.36 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:03.36 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 20:21.27 | wedhorn | snuff-home: been doing some pondering on not logging calls to the calls made list. Not sure whether its a bug or feature... |
| 20:22.02 | wedhorn | arguably, unless a dial() is used in the dialplan, a place call probably shouldn't be logged, think voicemail |
| 20:23.07 | wedhorn | the bug bit maybe that if you do something like answer() before calling dial() it won't log it either as the callstate will jump over SUBSTATE_DIALING |
| 20:24.31 | wedhorn | you want to check your dialplan for your call logging issue and see if there's something weird in there, but I think that an answer/playback/hangup shouldn't be added to the calls made list |
| 20:25.28 | *** join/#asterisk-dev jmls (~somefake@77.107.171.82) |
| 21:25.34 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |
| 21:26.15 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 21:26.15 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 21:32.32 | mjordan | file: is your location work taking NAT into account currently, i.e., local/external address information for Asterisk? |
| 21:33.19 | file | mjordan, no |
| 21:33.23 | seanbright | i would just go IPv6 only so you don't have to worry about NAT |
| 21:33.33 | seanbright | no one runs an IPv4 network anymore |
| 21:33.41 | file | the purpose of location is simply to know where something is and to potentially update that |
| 21:33.46 | mjordan | gotchya. |
| 21:33.56 | file | NAT handling will be separate |
| 21:33.56 | mjordan | It'd be nice if it could be purposed to store the location information of the Asterisk instance |
| 21:34.12 | file | that's transport specific really |
| 21:34.30 | mjordan | true, with extern[trans] |
| 21:34.47 | oej | You need to keep track of flows - tcp connections |
| 21:35.09 | mjordan | seanbright: alas, "IPv6 or die" isn't quite a reality yet |
| 21:35.42 | mjordan | is there anything we can improve on in our current NAT settings? |
| 21:35.51 | mjordan | (and on that note, brb) |
| 21:36.28 | oej | The current nat is overworked and have too many confusing options, bad design |
| 21:36.49 | oej | For SIP, you always send the messages to the IP:port you got it from. |
| 21:36.58 | oej | NAT should reflect media handling only |
| 21:37.29 | putnopvut | And for that, we have STUN/TURN/ICE |
| 21:53.10 | oej | That's good, but doesn't solve all issues. |
| 21:53.22 | oej | Those are just mechanics to discover what's going on. |
| 21:53.44 | oej | And asteirks will only need a TURN server help in some corner cases, so it's not a big thing |
| 21:53.58 | oej | We could be a TURN server though. |
| 21:54.08 | oej | Anyway, I'm logging off for the night. Good night. |
| 22:43.33 | snuff-work | wedhorn: any call a user makes should be logged.. |
| 22:44.00 | snuff-work | still have issue with the other side hanging up etc.. and no log.. |
| 22:44.27 | snuff-work | follows same states.. unset->off->dial->ringo->conn->on |
| 22:44.39 | snuff-work | a dp one just skips the 'ringout' phase |
| 22:45.08 | snuff-work | aka if i ring a valid number i dont expect the phone to 'eat it' ;) |
| 22:53.06 | mjordan | file: did you already enable SIP session timers in chan_gulp? |
| 22:54.13 | jsmith | mjordan: <sarcasm>No, that's in chan_chug!</sarcasm> |
| 22:54.48 | mjordan | jsmith: it really is a silly name |
| 22:55.24 | jsmith | mjordan: I'm fine with the name. But if you're chugging a liquid, you can't stop! |
| 22:55.33 | jsmith | thinks his feeble attempt at humor fell flat |
| 23:04.49 | file | mjordan, yes |
| 23:06.35 | mjordan | jsmith: sorry, creating backlog |
| 23:06.42 | mjordan | :-) |
| 23:06.47 | jsmith | It's all good :-p |
| 23:16.26 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 23:16.26 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:32.37 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ygmncqqiijdthqmd) |
| 23:57.17 | *** join/#asterisk-dev serafie (~erin@76.73.167.231) |