| 00:01.04 | *** join/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 00:16.24 | *** join/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 01:02.59 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 01:31.04 | *** join/#asterisk-dev wudles (~wudles@gateway.secureinstrument.com) |
| 01:38.19 | Kobaz | i rewrote my datastore/list stuff |
| 01:38.38 | Kobaz | and now i have a linked list with list_head->first is null, and list_lead->last is non-null |
| 01:38.45 | Kobaz | been working on this crap for like 6 hours |
| 02:10.00 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:10.00 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:10.03 | *** join/#asterisk-dev mealstrom (~mealstrom@46.63.71.254) |
| 02:54.38 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:27.39 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 04:27.39 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 05:23.27 | Kobaz | haha |
| 05:23.30 | Kobaz | i found my problem |
| 05:23.43 | Kobaz | cb_store = data_store ? (struct channel_hangup_callback_store *) &data_store->data : NULL; |
| 05:23.48 | Kobaz | which character doesn't belong |
| 05:43.23 | *** join/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 05:44.34 | *** part/#asterisk-dev mpe (~mpe@94.127.49.1) |
| 06:02.25 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 06:02.29 | schmidts | good morning |
| 06:04.15 | mealstrom | welcome |
| 06:05.29 | schmidts | oh an american guy still up at this time :D must be late at yours? |
| 06:05.43 | mealstrom | ukraine, gmt +2 :) |
| 06:05.50 | schmidts | ok :D |
| 06:06.11 | schmidts | then you choose not the nearest freenode server ;) |
| 06:10.45 | Kobaz | heh |
| 06:10.49 | Kobaz | 2am here |
| 06:11.09 | Kobaz | fixed my bug from 12pm about 20 minutes ago |
| 06:11.13 | Kobaz | need to crash |
| 06:12.54 | Kobaz | mm more like 30 minutes ago |
| 06:13.36 | schmidts | hehe i hate it when this happens: "only this small thing i am sure i will fix this soon" several hours later "now soon i will have it" ;) |
| 06:14.09 | Kobaz | haha |
| 06:14.10 | Kobaz | yeah |
| 06:14.11 | mealstrom | im using irc.freenode server. what dns says me - that im using :D |
| 06:14.30 | Kobaz | so... 12+ hours later |
| 06:14.32 | Kobaz | all fixed |
| 06:16.55 | schmidts | mealstrom whois says you are using niven.freenode.net in US :D |
| 06:17.10 | schmidts | Kobaz and how long did you thought it would take? |
| 06:18.04 | Kobaz | i thought it would take a while |
| 06:18.08 | Kobaz | but not that much of a while |
| 06:18.16 | Kobaz | i knew it was memory corruption |
| 06:18.23 | Kobaz | that was about it |
| 06:18.50 | Kobaz | cb_store = data_store ? (struct channel_hangup_callback_store *) &data_store->data : NULL; |
| 06:18.52 | Kobaz | that's a fun one |
| 06:20.27 | schmidts | hmm looks quite ok for me, or is this the result of your work? |
| 06:20.39 | Kobaz | looks okay |
| 06:20.42 | Kobaz | but is it okay |
| 06:20.48 | Kobaz | look closely |
| 06:21.21 | Kobaz | that line has my bug |
| 06:21.29 | mealstrom | schmidts: hehe,, bad, bad dns :D |
| 06:21.46 | schmidts | missing check of data_store->data comes to my mind like ((data_store) && (data_store->data)) ? ... |
| 06:21.52 | Kobaz | nope |
| 06:22.06 | Kobaz | strike 1! |
| 06:22.11 | schmidts | :D |
| 06:22.40 | Kobaz | the a ? x : y takes care of protecting the assignment |
| 06:23.27 | schmidts | what do you mean? |
| 06:23.41 | Kobaz | cb_store = data_store ? .... |
| 06:24.01 | Kobaz | it'll only take ->data if data_store has a true value |
| 06:24.22 | Kobaz | so that's not a problem |
| 06:24.36 | schmidts | ok, as i said first thing which comes to my mind ;) |
| 06:24.46 | schmidts | you said the problem is memory corruption, hmmm |
| 06:25.44 | schmidts | ok next try: isnt data_store->data allready the pointer address of the memory you want? did you need the & in front? |
| 06:25.50 | Kobaz | hah |
| 06:25.53 | Kobaz | yeah that's the problem |
| 06:26.03 | Kobaz | taking the address of the pointer rather than copy the pointer |
| 06:26.27 | schmidts | ouch |
| 06:26.46 | schmidts | nice catch Kobaz ;) |
| 06:27.09 | Kobaz | yeah |
| 06:27.13 | Kobaz | only took half the day |
| 06:27.30 | schmidts | but btw are you sure that data_store->data allways have a value when data_store != NULL? |
| 06:27.51 | Kobaz | it'll have a value of either null or non-null |
| 06:28.03 | Kobaz | but it's okay if it's null, you'll just have a pointer to null |
| 06:28.08 | schmidts | ok ;) |
| 06:28.10 | Kobaz | i check that later on |
| 06:28.15 | schmidts | or the address of a pointer to NULL :D |
| 06:28.46 | Kobaz | well yeah |
| 06:28.50 | Kobaz | in the case of & |
| 06:29.31 | schmidts | ;) |
| 06:30.11 | Kobaz | my reward is sleep now |
| 06:30.24 | schmidts | :D |
| 06:30.26 | schmidts | good n8 |
| 06:31.41 | Kobaz | night night |
| 06:36.31 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:38.03 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 06:38.03 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 06:47.27 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 07:05.57 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 07:17.15 | *** join/#asterisk-dev chazzam (~chazz@50-81-150-34.client.mchsi.com) |
| 07:25.12 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:25.12 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:04.11 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 08:04.12 | *** join/#asterisk-dev micols (~t@rlogin.dk) |
| 08:11.22 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 08:28.10 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 10:58.41 | *** join/#asterisk-dev mbrevda (u5500@gateway/web/irccloud.com/x-cuywtcxcolrvznvv) |
| 11:48.58 | *** join/#asterisk-dev snuff-work (~snuffy@203-219-29-182.tpgi.com.au) |
| 11:48.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:04.22 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:04.22 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:25.39 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 12:44.14 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 12:52.24 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 12:52.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:56.30 | *** join/#asterisk-dev Dovid (Dovid@office.mypbxmanager.net) |
| 13:16.05 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fspvuksdcwdkspjt) |
| 13:16.05 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:29.13 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:30.12 | *** join/#asterisk-dev Victor_Yure (~IceChat77@unaffiliated/victoryure/x-837844) |
| 13:34.02 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-lgutzllvhnkpdogb) |
| 13:43.00 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:43.00 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:47.15 | WIMPy | I'm just into the answered elsewhere thing and as it seems, sometimes it is flaged by AST_CAUSE_ANSWERED_ELSEWHERE and sometimes with AST_FLAG_ANSWERED_ELSEWHERE. |
| 14:47.34 | WIMPy | That seems like duplicated functionality. |
| 14:48.37 | WIMPy | Could it be that flag is left over from historic reasons and could be relpaced? |
| 15:16.17 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 15:16.17 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:28.47 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:28.47 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:29.07 | Qwell | otherwiseguy: there's already a way to check for support of flags in gcc. See configure.ac, where it looks for -Wdeclaration-after-statement |
| 15:30.50 | kpfleming | Qwell: you beat me to it :-) |
| 15:32.25 | otherwiseguy | Qwell: woots. thanks. I grepped configure.ac for GCC/gcc and didn't see anything. Should have grepped for CC. :-/ |
| 15:33.18 | Qwell | That next one bothers me... gcc -D_FORTIFY_SOURCE=2 -S -o /dev/null -xc /dev/null |
| 15:35.57 | Qwell | won't -D always work? O.o |
| 15:35.57 | Qwell | -D_FORTIFY_BACON=2 works just fine. and why wouldn't it? |
| 15:36.12 | kpfleming | yeah... i don't see how that could fail |
| 15:36.32 | otherwiseguy | Who wouldn't want fortified bacon? |
| 15:36.51 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:36.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:46.49 | Qwell | otherwiseguy: not quite :D |
| 15:46.53 | otherwiseguy | doh |
| 15:46.58 | otherwiseguy | It worked, though. :-) |
| 15:47.07 | Qwell | because you stole AST_DECLARATION_AFTER_STATEMENT :p |
| 15:47.20 | Qwell | You need to add your own, then set it somehow. I didn't check how |
| 15:47.37 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 15:47.37 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 15:47.46 | Qwell | I'm sure it's in the Makefile, somewhere |
| 15:47.57 | otherwiseguy | gah, I am a moron. |
| 15:48.18 | otherwiseguy | Which incidentaly is perfectly politically correct to say, even though it was the word that "retard" replaced. |
| 15:50.01 | kpfleming | Qwell: wcgrep AST_DECLARATION will tell you the places that need to be touched. there aren't many. |
| 16:01.42 | mjordan | otherwiseguy: ASTERISK-19827 |
| 16:02.12 | kpfleming | mjordan: you said "bumps the ref count, then derefs it a few lines later" |
| 16:02.21 | kpfleming | that sounds like normal behavior |
| 16:02.32 | kpfleming | unless by 'bump' you mean 'decrement' |
| 16:02.36 | mjordan | kpfleming: except that it expects the reference after the UNREF to be valid |
| 16:02.53 | kpfleming | that is never safe, with either ASTOBJ or ao2 |
| 16:02.56 | Qwell | well there's your problem |
| 16:03.01 | kpfleming | an unref could always cause the object to be destroyed |
| 16:03.49 | kpfleming | but unless you use the pattern 'ref = ao2_ref(ref, -1);' in your code, for an ao2 object if the unref causes the object to be destroyed, you'll still have a dangling pointer to it |
| 16:04.09 | otherwiseguy | ao2_ref doesn't return a pointer. |
| 16:04.19 | kpfleming | grr. /me hates that. |
| 16:04.21 | mjordan | otherwiseguy: people have wrappers in chan_sip for that pattern |
| 16:04.23 | otherwiseguy | it returns the refcount before the op |
| 16:05.00 | kpfleming | it should return what the refcount will be at 10:00AM next Tuesday |
| 16:05.54 | kpfleming | in any case, mjordan said 'bump', which i took to mean increasing the refcount, not decreasing it |
| 16:06.27 | mjordan | kpfleming: and that is what I meant. Code would probably help - line 12425 in 1.8/chan_sip |
| 16:07.15 | mjordan | we prematurely increase the ref count because we expect there to be a dnsmgr object put on the mwi instance. If that doesn't happen, we say 'oops', and we decrement the ref count. |
| 16:07.17 | kpfleming | that looks kosher to me |
| 16:07.28 | mjordan | if dnsmgr is not allocated, mwi is NULL |
| 16:07.38 | kpfleming | ouch |
| 16:07.41 | kpfleming | yes, badness |
| 16:07.49 | kpfleming | that's a bad pattern |
| 16:07.53 | mjordan | :-) |
| 16:08.03 | kpfleming | 'mwiref = ASTOBJ_REF(mwi);' would be acceptable |
| 16:08.46 | kpfleming | honestly, i really detest the pattern in ao2 where we just directly increment/decrement the refcount without making a copy of the pointer. making a copy of the pointer should be *necessary*, as that's your 'new reference' to the object. |
| 16:09.07 | mjordan | it may also cause a problem on line 30456. If the iterator has a dnsmgr, we would set it to NULL, then try to unlock it. |
| 16:09.07 | kpfleming | that keeps programmers from making this mistake right here |
| 16:09.44 | kpfleming | that must be the wrong line number... that's an ast_manager_register_xml() in my copy |
| 16:10.29 | mjordan | I'll find it, was looking at what it was in the review |
| 16:10.37 | kpfleming | ahh |
| 16:10.56 | otherwiseguy | I agree it is a bad pattern, but if it had been ao2 it would have worked. :-p |
| 16:11.05 | mjordan | line 30640 |
| 16:11.48 | otherwiseguy | That's what I get for making assumptions about what a macro does... |
| 16:12.24 | mjordan | otherwiseguy: do we really need to increase the reference count on the mwi object if dnsmgr exists? |
| 16:12.39 | kpfleming | yes, because we're handing it a reference to the object |
| 16:12.42 | otherwiseguy | Aren't we storing it? |
| 16:12.52 | kpfleming | that's why this is a terrible pattern |
| 16:14.01 | kpfleming | mjordan: at line 30636, the ASTOBJ_UNREF cannot drop the refcount of 'iterator' to zero, because the container holds refs to the objects as well |
| 16:14.47 | *** join/#asterisk-dev mpe (~mpe@mobile-80-62-116-164.broadband.tdc.dk) |
| 16:15.00 | mjordan | even if it doesn't drop the refcount of iterator to 0, iterator itself is still set to NULL, correct? |
| 16:15.11 | kpfleming | oh.. yes, good catch. |
| 16:19.00 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 16:19.14 | kpfleming | so in this case, since ASTOBJ_UNREF can't be called *directly* on the additional reference (it is stored inside a dnsmgr object), a local copy would have to be made to work around the behavior of the macro |
| 16:20.26 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:20.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:21.23 | *** join/#asterisk-dev mpe (~mpe@mobile-80-62-116-164.broadband.tdc.dk) |
| 16:22.21 | otherwiseguy | kpfleming: or we could convert the last two remnants of ASTOBJ in chan_sip to astobj2. |
| 16:22.42 | kpfleming | yes |
| 16:23.01 | kpfleming | that's more work than making a local copy of the pointer and a suitable comment, though |
| 16:23.14 | otherwiseguy | More work now. :-) |
| 16:23.34 | mjordan | kpfleming: we have that same pattern in a few places in the code - sip_send_all_mwi_subscriptions does the same thing on off nominal paths |
| 16:24.06 | kpfleming | bummer |
| 16:24.14 | kpfleming | this explains segfaulty crushing then |
| 16:24.26 | mjordan | crushed! |
| 16:26.14 | mjordan | otherwiseguy: we probably can't justify that as a bug fix for 1.8 |
| 16:26.16 | otherwiseguy | We should really stop crushing Asterisk. |
| 16:27.01 | otherwiseguy | mjordan: Obviously we should hire one of Oracle's lawyers to try to make the case for us. |
| 16:27.15 | mjordan | heh |
| 16:34.17 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 16:34.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:57.24 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-pjbkpghbagztzyop) |
| 17:16.50 | *** join/#asterisk-dev oej (~olle@h87-96-134-129.dynamic.se.alltele.net) |
| 17:16.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:21.33 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 18:28.21 | sruffell | russellb: FYI, It's long, but if you haven't already seen it this conversation about pull requests / commit messages (or more specifically, Linus' comments) are worth a read. |
| 18:29.45 | sruffell | https://github.com/torvalds/linux/pull/17#issuecomment-5654674 |
| 18:37.40 | Qwell | sruffell: Linus really doesn't hold in his thoughts, does he? |
| 18:38.01 | Qwell | "The fact that I have higher standards then makes people like you make snarky comments, thinking that you are cool. You're a moron." |
| 18:38.11 | sruffell | :) nah…but I can see the argument that it's more efficient for him... |
| 18:38.52 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 18:38.52 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 18:51.03 | mjordan | sruffell: that conversation quickly degenerated into internet memes. I stopped when I hit the Dos Equis guy. |
| 18:51.35 | sruffell | heh..yeah…and I only read Linus' comments anyway |
| 18:52.21 | Qwell | newtonr: that nick is all...official |
| 18:52.42 | sruffell | rnewton was already taken? |
| 18:52.58 | Qwell | it's been unused for > 6 months, I think you can get it purged |
| 18:58.07 | newtonr | Qwell: sruffell: i didn't even look for rnewton, also a lot of people think it's mewton because of some fonts |
| 18:58.23 | kpfleming | you could go with newton-inator |
| 18:58.24 | newtonr | I guess I could have done Rnewton |
| 18:58.37 | sruffell | ahh..makes sense. …and made me chuckle. |
| 18:58.45 | file | kpfleming: my inator-inator is broken :( |
| 18:59.33 | newtonr | kpfleming: not sure I could pull that one off |
| 19:24.13 | seanbright | is there ever a case where asterisk would send a 100 Trying in the middle of a call? |
| 19:24.31 | seanbright | it's possible that this pcap is just jacked up |
| 19:24.45 | kpfleming | it should not be possible for that to happen |
| 19:25.10 | kpfleming | well... wait. we might send a 100 Trying in response to re-INVITE, i suppose. |
| 19:25.14 | seanbright | i believe there is a reinvite happening, but the packet is fragmented |
| 19:25.27 | kpfleming | too large for a single datagram? |
| 19:25.48 | seanbright | not entirely sure, wireshark is just reporting it as fragmented |
| 19:25.59 | kpfleming | yep, that's what it would be |
| 19:26.08 | seanbright | is there something in a re-invite that explicitly marks it as a re-invite? |
| 19:26.12 | kpfleming | that is unlikely to work well |
| 19:26.22 | kpfleming | yes, the presence of a to-tag would indicate a re-INVITE |
| 19:26.55 | seanbright | 1514 bytes |
| 19:27.03 | seanbright | that's too big for a datagram? |
| 19:27.16 | kpfleming | that's the maximum size of an ethernet frame, so yes |
| 19:27.20 | seanbright | a ha |
| 19:27.26 | seanbright | kpfleming to the rescue |
| 19:27.51 | kpfleming | one of the hazards of using UDP... fragmentation and reassembly are boogers to deal with. |
| 19:29.35 | seanbright | kpfleming: when you say to-tag you mean 'To:'? |
| 19:29.41 | seanbright | oh |
| 19:29.41 | seanbright | nevermind |
| 19:29.43 | seanbright | ;tag=... |
| 19:29.48 | kpfleming | yep |
| 19:31.37 | *** join/#asterisk-dev vipkilla (~chatzilla@unaffiliated/t-dot-zilla/x-2830497) |
| 19:33.13 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fspvuksdcwdkspjt) |
| 19:33.21 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fspvuksdcwdkspjt) |
| 19:33.22 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:44.12 | *** join/#asterisk-dev b3nt_pin (~b3ntpin@142.162.47.99) |
| 19:48.42 | kpfleming | otherwiseguy: that list of things that are not included in r366739 is non-exhaustive. please correct. |
| 19:49.15 | otherwiseguy | kpfleming: Will digium continue to pay me indefinitely to work on that list? :-D |
| 19:49.22 | kpfleming | undetermined. |
| 19:49.26 | otherwiseguy | hmmm. |
| 19:49.44 | otherwiseguy | Because I think I could write a script that ran for a very long time to do that work. :-) |
| 19:51.07 | otherwiseguy | Alas, i found a quicker fix. |
| 20:07.06 | seanbright | kpfleming: does asterisk handle the fragmentation? |
| 20:08.28 | seanbright | that may be a dumb question, i'm going to re-think it before asking again |
| 20:14.43 | russellb | lol. |
| 20:14.56 | russellb | it's handled before getting up to asterisk :-) |
| 20:15.23 | putnopvut | Fun situation here, somehow the initial INVITE going out to the transfer target on a SIP blind transfer has a P-Asserted-Identity display name of "-> (via sipp@127.0.1.1:5061)" |
| 20:15.24 | putnopvut | wtf |
| 20:16.15 | vipkilla | cool |
| 20:16.15 | russellb | putnopvut: that doesn't seem ideal |
| 20:17.01 | putnopvut | yep, no clue why that's happening. It doesn't cause a failure for what I'm trying, but it does make me wonder where the hell that value comes from. It just screams corruption of some sort. |
| 20:21.46 | putnopvut | Wait, this is actually a reinvite to the transferee that has that, not the initial invite to the transfer target. |
| 20:30.58 | *** join/#asterisk-dev mpe (~mpe@mobile-80-62-116-164.broadband.tdc.dk) |
| 20:51.35 | kpfleming | seanbright: it is handled by monkeys |
| 21:10.26 | russellb | kpfleming: your answer does not conflict with mine either. excellent. |
| 21:17.30 | putnopvut | sipp is great but it annoys the crap out of me sometimes. There is a handy keyword you can use called [peer_tag_param] you can add to To and From headers to automatically fill in the remote tag. Unfortunately, SIPp does not fill this in with anything useful unless the SIPp scenario receives a response. |
| 21:26.55 | *** join/#asterisk-dev mpe (~mpe@mobile-80-62-116-164.broadband.tdc.dk) |
| 22:11.04 | WIMPy | Does anyone feel like commenting on the AST_FLAG_ANSWERED_ELSEWHERE thing? |
| 22:14.14 | jsmith | What about it? |
| 22:15.27 | WIMPy | ... answered elsewhere is usually flaged by AST_CAUSE_ANSWERED_ELSEWHERE, but local channels and queues use AST_FLAG_ANSWERED_ELSEWHERE. |
| 22:15.37 | WIMPy | That seems like duplicated functionality. |
| 22:15.49 | WIMPy | Could it be that flag is left over from historic reasons and could be relpaced? |
| 22:16.43 | mjordan | WIMPy: not ignoring your questions, but without digging into it I'm not sure. I'll try to take a peek at it tomorrow, if no on else has answered |
| 22:17.59 | WIMPy | A short grep -r ANSWERED_ElSEWHERE doesn't give many results. |
| 22:18.20 | WIMPy | To me it looks like the flag could be replaced by the cause. |
| 22:18.32 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fspvuksdcwdkspjt) |
| 22:50.52 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 23:00.58 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-todopjnmpmwfiybq) |
| 23:44.42 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 23:44.42 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |