| 00:25.22 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 00:25.22 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 00:38.11 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 01:05.34 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 01:05.34 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:17.37 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 02:25.38 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 02:44.29 | wedhorn | snuff-work: I had that with the rereg issue I was discussing with you the other day. Should be fixed in trunk |
| 02:46.20 | snuff-work | ah k |
| 02:46.50 | snuff-work | i got it on only 1 of the phones.. couldn't reprod on others.. |
| 02:48.51 | snuff-work | i got working my link between ccm and *.. so that was a nice thing.. means i can get closer to 'stealth move' ppl from ccm to * for testing |
| 02:49.37 | wedhorn | different firmware? It's because of a large 0x30 packet (bigger than the max size in skinny of 1000 bytes) |
| 02:50.41 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 02:55.02 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 02:55.11 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 02:55.29 | snuff-work | yer.. so my 8.5.4 was ok.. my 8.3.3 was ok |
| 02:55.39 | snuff-work | but the 8.4.1 did have the issue |
| 02:59.46 | wedhorn | who knows, mine was doing it on 8.5.4, also packet sizes tend to grow with later versions |
| 03:00.34 | snuff-work | mm |
| 03:05.46 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 03:05.46 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 04:09.41 | *** join/#asterisk-dev ChrisInSydney (~Chris@110.93.22.141) |
| 04:34.37 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 04:50.57 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 05:07.00 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@mail.redfish-solutions.com) |
| 05:30.38 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 05:30.38 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 06:50.29 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 06:52.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:b023:fd18:771b:9c3b) |
| 07:24.51 | *** join/#asterisk-dev irroot (~irroot@196.44.226.250) |
| 07:50.41 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:00.13 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:00.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:19.51 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:19.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:35.15 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 11:35.15 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 11:57.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:57.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:10.48 | oej | Good morning, Kevin! |
| 12:16.01 | kpfleming | what makes it good? |
| 12:16.10 | kpfleming | did Dzonatas Sol post something useful today? |
| 12:19.32 | irroot | kpfleming lol morning |
| 12:19.41 | irroot | oej hi there |
| 12:22.35 | oej | Now, that's a bad attitude kpfleming. It's a wonderful day that will get better after your breakfast. Enjoy! |
| 12:22.54 | oej | And I'm afraid that Dzonatas is keeping to his previous standards. |
| 12:23.00 | kpfleming | That's possible. It's a bit gray and rainy here though. |
| 12:53.25 | kpfleming | jsmith-away is now known as beefy miracle |
| 13:02.01 | Marquis42 | lol |
| 13:08.45 | jsmith | kpfleming: Right.... |
| 13:09.51 | jsmith | kpfleming: My own personal definition of a "beefy miracle" is a nice filet mingon, not some nasty hot dog... |
| 13:10.03 | irroot | jsmith +1 |
| 13:10.17 | jsmith | That being said, I'll all for injecting a little light-hearted humor into the sometimes mundane process of building a distribution |
| 13:10.33 | jsmith | If you can't laugh at yourself from time to time, you're taking life too seriously |
| 13:12.52 | Marquis42 | jsmith: Agreed. And besides which, now the people who whined that F16 wasn't called that can get back to doing some real work. ;) |
| 13:13.10 | jsmith | Marquis42: Exactly :-) |
| 13:13.31 | irroot | hehe got to love the whiners |
| 13:13.41 | jsmith | While I don't agree with the sentiment 100%, there's something to be said for "All publicity is good publicity" |
| 13:14.22 | irroot | a whine goes round the net faster than a compliment not a bad strategy |
| 13:15.44 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-hjfufcdnbkcjbrxa) |
| 13:15.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:20.47 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-fqfdtsachbvupwyf) |
| 13:34.37 | acidfoo | jsmith, filet mignon ;P |
| 13:52.56 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:52.56 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:13.31 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 14:16.07 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 14:18.36 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 14:26.48 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 14:29.59 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:30.08 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:04.51 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 15:17.01 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:24.35 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:24.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:25.40 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 15:38.55 | *** join/#asterisk-dev p3nguin (~xwQ5kwYl6@cobalt.esxi.hosts.a2infotech.com) |
| 15:51.47 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:58.28 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:58.29 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:18.46 | *** join/#asterisk-dev luckman212 (~irc@pool-108-41-8-176.nycmny.fios.verizon.net) |
| 16:18.51 | *** join/#asterisk-dev irroot (~irroot@197.105.135.199) |
| 16:38.52 | Marquis42 | Asterisk (at least in 1.8, haven't checked 10 or trunk yet) doesn't honor maddr parameters in Contact URIs when they're received in a 302. The fix, I think, is easy enough. But should that be viewed as a bug or a feature? i.e., should I submit the patch for 1.8 to be merged up through trunk? |
| 16:39.05 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:39.31 | kpfleming | maddr is a huge farce... it's never used for what it is really supposed to be used for :) |
| 16:39.43 | Marquis42 | Oh, trust me, I know! |
| 16:39.51 | kpfleming | but if the fix is small and noninvasive, it's fine to treat that as a bug fix |
| 16:40.17 | Marquis42 | OK, cool. A brief glance at the code seems to imply that it is, and if so I'll submit as a bug fix. Thanks |
| 16:50.23 | pabelanger | ASTERISK-18705 |
| 16:50.31 | pabelanger | boo :( |
| 16:50.33 | pabelanger | no bot |
| 17:04.10 | *** join/#asterisk-dev irroot (~irroot@197.105.135.199) |
| 17:23.31 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-ksyjyzlilnnlgqjd) |
| 17:35.54 | *** join/#asterisk-dev oej (~olle@ns.webway.se) |
| 17:35.55 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:44.21 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 17:44.21 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 18:22.50 | *** join/#asterisk-dev michael-i (~anonymous@204.11.230.58) |
| 18:37.33 | *** join/#asterisk-dev zerohalo (~zerohalo@173-13-92-27-NewEngland.hfc.comcastbusiness.net) |
| 19:05.30 | *** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr) |
| 19:31.02 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 19:40.09 | *** join/#asterisk-dev irroot (~irroot@197.104.171.176) |
| 20:02.32 | *** join/#asterisk-dev mpe (~mpe@31.25.23.177) |
| 20:14.04 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:14.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:49.20 | Kobaz | What would i dig into to pass through original callerid when doing an attended teansfer |
| 20:49.46 | Kobaz | A -> B B -> C by default C sees B's callerid |
| 20:49.57 | kpfleming | on the outbound call to the transfer targer, or after the transfer has been completed? |
| 20:50.07 | Kobaz | after a completed transfer |
| 20:50.08 | kpfleming | s/targer/target/ |
| 20:50.16 | Kobaz | is there a way to update the callerid, like connected line |
| 20:50.17 | kpfleming | that's already handle.. it's called a connected line update |
| 20:50.22 | Kobaz | oh |
| 20:50.32 | kpfleming | C is now connected to A, so it will be told that |
| 20:50.34 | Kobaz | wimpy on asterisk was saying it doesn't do that |
| 20:50.42 | kpfleming | depends on the version of asterisk you are talking about |
| 20:50.45 | Kobaz | hmm |
| 20:50.46 | Kobaz | 1.8 |
| 20:50.49 | kpfleming | yes, it does |
| 20:51.03 | Kobaz | i thought it did handle that, i thought that was the whole point |
| 20:51.03 | kpfleming | schmidts has even been testing it this past week and found a problem when a proxy is in the picture |
| 20:51.14 | kpfleming | of course, the phones have to support updating their displays... not all of them do |
| 20:51.15 | Kobaz | so say i have one asterisk, and just three phones |
| 20:51.23 | Kobaz | polycom supports it? |
| 20:51.34 | kpfleming | yes, with modern firmware (3.x) |
| 20:51.38 | Kobaz | ah okay |
| 20:51.59 | Kobaz | but you don't need the new new stuff, that's good |
| 20:52.05 | Kobaz | i'm running 3.3.1 on pretty much everything |
| 20:52.30 | Kobaz | so do I need to do anything special to use it? |
| 20:52.33 | kpfleming | the development of that stuff was tested with polycom phone ~18 months ago, so at least firmware then supported it |
| 20:52.46 | kpfleming | it's documented on the wiki, i believe |
| 20:52.57 | Kobaz | there's new beta stuff for polycom that supports hot config reloads, it's pretty cool |
| 20:53.00 | Kobaz | okay, i'll search around |
| 20:53.05 | Qwell | https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information |
| 20:53.55 | Kobaz | You can use it to send new connected line information to the remote party on the channel when a call is transferred. The CONNECTEDLINE information is passed when the call is answered and when the call is transferred. |
| 20:53.57 | Kobaz | oh |
| 20:54.00 | Kobaz | i think that's exactly it |
| 21:00.18 | Kobaz | what's a good way to check if it's working but the phone is being stupid |
| 21:02.21 | jsmith | Now if only analog calls really took advantage of it, and came directly into the dialplan (and later had their CONNECTEDLINE information updates), rather than waiting for the callerid info before hitting the dialplan |
| 21:02.27 | jsmith | Oh well, it's nice to dream :-) |
| 21:02.47 | Qwell | jsmith: analog is deprecated, remember? |
| 21:03.39 | jsmith | Qwell: It may be buried six feet underground, but it's not dead yet! |
| 21:03.45 | Kobaz | what debug should i turn on? I'm setting CONNECTEDLINE and i'm not seeing anything related in the console |
| 21:03.48 | Kobaz | verbosity 3 |
| 21:04.20 | Qwell | jsmith: it's very dead. as dead as fax. unfortunately they're zombies now. |
| 21:04.43 | jsmith | What are you talking about... I convinced kpfleming and mnicholson to fix a T.38 fax issue for me just a few weeks ago |
| 21:04.56 | jsmith | chuckles |
| 21:06.52 | kpfleming | Kobaz: you'll probably have to use 'sip debug' to see what's happening |
| 21:07.07 | Kobaz | allrightey, no verbose debugging |
| 21:08.37 | Kobaz | oh wait i'm probably doing this wrong |
| 21:08.40 | Kobaz | wow this is going to be tricky |
| 21:09.06 | kpfleming | enabling updates after transfers should not be tricky at all |
| 21:09.21 | Kobaz | well i need to get the name from the first call that came in |
| 21:09.29 | kpfleming | why? asterisk already has it. |
| 21:09.31 | Kobaz | and it's not related to the call that will be transfered at all |
| 21:09.36 | Kobaz | hmm |
| 21:09.46 | kpfleming | umm... what? |
| 21:09.52 | Kobaz | A calls B |
| 21:09.58 | Kobaz | B calls C as a seperate call |
| 21:10.11 | Kobaz | there's no relation of C to A until a transfer is done |
| 21:10.18 | Kobaz | but by then it's too late to set CONNECTEDLINE |
| 21:10.30 | kpfleming | that's correct. and when that transfer is done, asterisk will send an update to both A and C to tell them who they are connected to. |
| 21:10.32 | Kobaz | or, is that what the callbacks are for? |
| 21:10.43 | Kobaz | okay, totally new to connectedline stuff |
| 21:10.49 | kpfleming | C is not going to know who B is transferring before the transfer is completed |
| 21:10.53 | Kobaz | yeah |
| 21:11.03 | Kobaz | do i need to set CONNECTEDLINE at all? |
| 21:11.05 | kpfleming | no |
| 21:11.08 | Kobaz | or will some options take care of it |
| 21:11.09 | Kobaz | okay |
| 21:11.56 | Kobaz | so, if i don't do anything except some Dial()'s |
| 21:12.00 | Kobaz | nothing interesting happens |
| 21:12.13 | *** join/#asterisk-dev irroot (~irroot@197.104.171.176) |
| 21:12.41 | kpfleming | did you look at sip.conf.sample? |
| 21:12.50 | Kobaz | there's no extra sip messages that get sent when i hit transfer |
| 21:13.03 | Kobaz | yeah i'm probably missing something i guess |
| 21:13.04 | kpfleming | you need 'sendrpid' enabled to send any remote party identification information |
| 21:13.16 | Kobaz | you need sendrpid on the phone? |
| 21:13.16 | kpfleming | and then you can choose which type of header to send |
| 21:13.20 | kpfleming | of course! |
| 21:13.32 | Kobaz | ah, i only ever use that for 'trunk' peers |
| 21:13.54 | kpfleming | well, if it's not enabled for a phone, asterisk will not send remote party id to that phone... which is exactly what you are trying to do! |
| 21:14.01 | Kobaz | ah okay |
| 21:14.03 | Kobaz | hah makes sense |
| 21:14.59 | file | kpfleming is very good with logic |
| 21:15.15 | Kobaz | :P |
| 21:15.27 | *** join/#asterisk-dev schmidts (~sst@86.59.31.4) |
| 21:15.38 | schmidts | hi folks ;) |
| 21:15.51 | schmidts | i need some help with merge10trunk |
| 21:16.23 | Qwell | schmidts: merging something you merged from 1.8? |
| 21:16.30 | schmidts | yes |
| 21:16.45 | Qwell | you need to `svn resolved .` - I believe that's somewhere on the wiki where it talks about merging |
| 21:16.48 | Kobaz | what type of rpid should i use? |
| 21:16.58 | kpfleming | Kobaz: you'll have to test with your phones to find out what works |
| 21:17.02 | Kobaz | k |
| 21:17.23 | Qwell | schmidts: second note (green box) in 2.3 |
| 21:17.31 | Kobaz | oh crap it worked |
| 21:17.37 | Kobaz | hugs kpfleming |
| 21:18.10 | kpfleming | sorry, i know you weren't expecting that |
| 21:18.19 | schmidts | qwell found it allready thank you ;) |
| 21:18.24 | Kobaz | haha |
| 21:18.37 | Kobaz | kpfleming: well my initial experiments weren't going so well |
| 21:19.09 | kpfleming | enabling the feature will help, usually :-) |
| 21:19.13 | Kobaz | yeap |
| 21:19.37 | Kobaz | it's not totally obvious you need to do that, unless i missed something obvious |
| 21:20.02 | kpfleming | no, but patches are welcome |
| 21:20.13 | kpfleming | especially sample config/documentation patches |
| 21:20.17 | Kobaz | yeah |
| 21:20.23 | Kobaz | i'll come up with something |
| 21:20.44 | Kobaz | i need to get back on my asterisk development |
| 21:20.58 | Kobaz | i rewrote a few things, so i'm finally happy with the code |
| 21:21.08 | Qwell | Does it still make sense to not enable rpid by default? |
| 21:21.10 | Kobaz | and then i made suggested changes to the predial stuff, that's working nicely |
| 21:21.17 | schmidts | qwell a svn resolved . doesnt solve it, cause the corruption is on channel/chan_sip.c. i can do a svn resolved chan_sip.c but i am not sure about the svn diff output i can see then: http://pastebin.com/wPBngJVq |
| 21:21.29 | Qwell | schmidts: ahh, yeah that's a very different issue |
| 21:21.31 | kpfleming | Qwell: yes... quite a few phones will behave badly if they receive stuff they don't like |
| 21:21.37 | Qwell | it means the code changed in some significant way between 1.8 and 10 |
| 21:21.50 | Kobaz | is there anything in sip for feature negotiation? |
| 21:22.28 | schmidts | qwell ok so its ok to do a checkin without merge or should i try to resolve it on another way? |
| 21:22.48 | kpfleming | Kobaz: you'll have to define what you mean |
| 21:22.58 | Qwell | schmidts: You'll need to manually resolve that issue in the code, then once the code is correct, you need to `svn resolve channels/chan_sip.c` |
| 21:23.05 | Kobaz | like web browsers... with javascript you can check for features |
| 21:23.09 | Kobaz | instead of browser versions |
| 21:23.26 | Kobaz | instead of checking, is this ie 7, you check for, do i have support for border shadows |
| 21:23.29 | schmidts | ok thank you qwell! |
| 21:23.40 | Kobaz | so like, is there a method in sip, to ask the phone, do you accept connected line updates |
| 21:23.40 | Kobaz | etc |
| 21:24.02 | kpfleming | no |
| 21:24.20 | kpfleming | well, the phone will tell you whether it supports the UPDATE SIP request method, but that's only partially related |
| 21:24.40 | kpfleming | it may be able to tell you whether it supports P-Asserted-Identity or not... i can't remember |
| 21:29.22 | schmidts | Qwell thanks again, worked fine ;) |
| 21:30.20 | Qwell | I'm really surprised svn couldn't figure that one out. |
| 21:30.56 | schmidts | ;) |
| 21:31.02 | Qwell | BUT! |
| 21:31.16 | Qwell | It is a very very good example of why formatting changes for the sake of formatting changes are a terrible idea. |
| 21:33.50 | schmidts | sorry dont understand what you mean? |
| 21:35.05 | Qwell | I believe the lines above your change in trunk were updated during a formatting cleanup. |
| 21:35.19 | Qwell | If they had been left alone, your merge would have been successful. |
| 21:35.33 | schmidts | ahh ok yes it looks like this, just { } was added |
| 21:35.44 | Qwell | yep, exactly |
| 21:44.08 | *** join/#asterisk-dev mpe (~mpe@31.25.23.177) |
| 21:49.43 | kpfleming | schmidts: you also need to update your installed copy of repotools, so that it will generate nicer-looking commit messages when you merge changes between branches |
| 21:49.54 | kpfleming | apparently a lot of people missed richard's email to asterisk-dev about that... |
| 21:53.42 | schmidts | thanks kpfleming have done it ;) |
| 22:19.00 | *** join/#asterisk-dev ChrisInSydney (~Chris@110.93.22.138) |
| 22:33.56 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-hjfufcdnbkcjbrxa) |
| 22:40.09 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 23:12.07 | *** join/#asterisk-dev ChrisInSydney (~Chris@120.156.240.128) |
| 23:16.46 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 23:16.46 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:30.41 | *** join/#asterisk-dev Corydon76-home (eight@c-69-137-80-31.hsd1.tn.comcast.net) |
| 23:30.41 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 23:56.21 | *** join/#asterisk-dev ChrisInSydney (~Chris@110.93.22.141) |