| 00:41.09 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 00:48.27 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 00:48.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 00:53.36 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.154.87.dsl.dyn.forthnet.gr) |
| 02:20.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 02:33.57 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 02:33.57 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 02:49.50 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 04:58.47 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-rwmhyufqdotxbyzz) |
| 06:24.42 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:25.12 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:25.41 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:26.11 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:27.12 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:28.11 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 06:37.58 | *** join/#asterisk-dev Freeaqingme (~Freeaqing@91.214.168.110) |
| 06:40.16 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 07:37.47 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 07:37.47 | *** mode/#asterisk-dev [+o snuff-home] by calvino.freenode.net |
| 07:58.35 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 07:58.37 | schmidts | good morning |
| 08:07.48 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 09:01.40 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:01.40 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 09:30.18 | *** join/#asterisk-dev frawd (~francois@221.red-80-28-139.adsl.static.ccgg.telefonica.net) |
| 09:46.00 | *** join/#asterisk-dev Freeaqingme_ (~Freeaqing@91.214.168.110) |
| 09:55.23 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-rwmhyufqdotxbyzz) |
| 09:55.23 | *** join/#asterisk-dev Tim_Toady (~fuzzy@178.128.154.87.dsl.dyn.forthnet.gr) |
| 09:55.23 | *** join/#asterisk-dev acidfoo (~nib@modemcable094.94-70-69.static.videotron.ca) |
| 11:25.13 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:25.13 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:39.45 | *** join/#asterisk-dev w9sh (~chatzilla@64.238.96.125) |
| 11:54.16 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 11:54.16 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 11:58.28 | *** part/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 13:03.39 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 13:15.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-ncdgfxunqmlqzqlw) |
| 13:15.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:47.01 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:47.01 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 13:56.18 | pabelanger | Friendly reminder, looking for some feedback about reworking our 'skip' option for the testsuite. https://reviewboard.asterisk.org/r/1796/ |
| 14:02.19 | *** join/#asterisk-dev matsk (~matsk@83.172.89.35) |
| 14:12.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:12.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:20.38 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 14:23.18 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:23.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:29.08 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:29.08 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:34.37 | mjordan | pabelanger: is there anything to be done with ASTERISK-19492? |
| 14:35.59 | pabelanger | mjordan: If we want to fix it, the Makefile with have to check if the existing directory exists if so, skip calling 'install -d' for it |
| 14:36.22 | pabelanger | EG: https://reviewboard.asterisk.org/r/654/#review2370 |
| 14:38.22 | mjordan | okay. In that case I'll poke the issue along. |
| 14:38.55 | kpfleming | lol |
| 14:39.16 | pabelanger | mjordan: If it's a matter of getting a patch, I can do it today |
| 14:39.23 | pabelanger | shouldn't take too long |
| 14:40.25 | mjordan | pabelanger: no need to do it today. |
| 14:40.41 | mjordan | it needs to be go through the workflow, same as everything else :-) |
| 14:40.53 | pabelanger | ack'd |
| 14:41.42 | pabelanger | FWIW: it does create the opportunity to add some upgrade testing to asterisk. Something that we don't do right now. |
| 14:42.10 | pabelanger | EG: Adding tests from one LTS branch to another would be worth it, from a users POV |
| 15:42.50 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:42.50 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:48.07 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 16:01.06 | mjordan | Is anyone aware of an open source contributor who has in the past maintained chan_mgcp? Would anyone like to? :-) |
| 16:02.19 | seanbright | what is mgcp? |
| 16:02.30 | file | mjordan: no! |
| 16:02.41 | seanbright | send me an mgcp and i will consider it |
| 16:02.42 | seanbright | :-) |
| 16:02.45 | seanbright | err |
| 16:02.53 | seanbright | send me an mg and i will consider it |
| 16:03.07 | mjordan | seanbright: not a cp? |
| 16:03.18 | seanbright | yes. |
| 16:03.47 | mjordan | seanbright: alas, I don't have one lying around |
| 16:04.19 | seanbright | oh well |
| 16:11.53 | russellb | mjordan: as opposed to a closed source contributor? :-p |
| 16:12.39 | mjordan | russellb: touche |
| 16:13.08 | seanbright | russellb: sponsor me |
| 16:13.25 | seanbright | i require sponsorship |
| 16:13.25 | russellb | seanbright: only if you sponsor me for more $ first |
| 16:13.25 | mjordan | seanbright: I can put your name on the list and assign everything to you in JIRA. That's free |
| 16:13.27 | file | trolls! |
| 16:13.31 | russellb | listen seanbright, code doesn't come free |
| 16:13.40 | mjordan | 5 bucks a character? |
| 16:13.50 | russellb | i'm game with that rate |
| 16:13.51 | seanbright | russellb: with mgcp we're talking about hundreds of millions of dollars of business |
| 16:13.52 | mjordan | I'm gonna go unroll me some loops |
| 16:13.56 | seanbright | i've done the necessary research |
| 16:14.06 | russellb | seanbright: trololol |
| 16:14.17 | seanbright | an mgcp to HAM gateway would literally blow the roof off this thing |
| 16:14.22 | seanbright | gazillions of dollars |
| 16:14.25 | mjordan | seanbright: +1 |
| 16:14.29 | russellb | i've got it in production in iraq, ok?! |
| 16:14.39 | seanbright | but as it stands, asterisk and dahdi are broken |
| 16:14.51 | mjordan | whatever. You just put an IP stack on top of everything and all your apps just work magically awesome |
| 16:14.52 | russellb | and it's all digium's fault |
| 16:14.53 | seanbright | it's ok to be wrong |
| 16:14.58 | seanbright | i've been at thjis much longer than you |
| 16:15.02 | mjordan | even if your underlying network is 2400 baud |
| 16:15.03 | seanbright | russellb: correct |
| 16:15.21 | seanbright | that is exhausting |
| 16:15.28 | seanbright | my abs hurt |
| 16:15.34 | russellb | i've got a new chan_sip in my local git repo |
| 16:15.38 | russellb | but i need a sponsor |
| 16:15.44 | seanbright | chan_pjsip? |
| 16:15.46 | file | russellb, $5? |
| 16:15.46 | seanbright | i'd pay for that |
| 16:16.04 | russellb | i dunno, but i've given it a cute fruit related name |
| 16:16.08 | seanbright | hah |
| 16:16.09 | seanbright | now now |
| 16:16.38 | russellb | the troll knob has been turned up to 11 |
| 16:16.41 | seanbright | throw in an amphibian's name and we'll have something to talk about |
| 16:16.59 | seanbright | i now need a grinectomy |
| 16:17.18 | file | seanbright, does your health insurance cover those? |
| 16:17.33 | seanbright | file: i have no health insurance |
| 16:17.50 | file | good to know... good to know... |
| 16:17.52 | seanbright | this is america |
| 16:17.57 | seanbright | aMERican |
| 16:18.15 | seanbright | said in a southern accent |
| 16:18.38 | mjordan | seanbright: just make sure you get a super sized value meal for lunch |
| 16:18.47 | seanbright | mjordan: naturally |
| 16:18.48 | mjordan | those calories are preventive... for something. |
| 16:18.58 | seanbright | while chain smoking |
| 16:19.16 | seanbright | nothing goes better with honey mustard dipping sauce than a winston 100 |
| 16:36.49 | mjordan | Corydon76-home: ping |
| 16:39.13 | Corydon76-home | pong |
| 16:41.01 | mjordan | Since STACK_PEEK got added as part of your patch, do you mind updating CHANGES with the new function? |
| 16:42.03 | Corydon76-home | Sure |
| 16:43.00 | mjordan | I'm not sure if UPGRADE needs to be updated with the AEL behavior changes, particularly since it restored 1.4 behavior. Up to you |
| 16:43.35 | Corydon76-home | Since it's fixing a bug, I thought that a change to UPGRADE.txt was not needed |
| 16:44.09 | mjordan | I wouldn't think so either, but I wasn't sure if the behavior change would break earlier 1.8 configurations |
| 16:55.01 | philipp64|laptop | mjordan: the previous incarnation of 19515 (13833) was previously discussed extensively via email between Mark, Olle, Tzafrir, Qwell, and myself. |
| 16:55.40 | philipp64|laptop | If I remember, Tilghman also was involved at some time. |
| 16:55.47 | Qwell | I don't remember that |
| 16:56.51 | philipp64|laptop | you should. :-) you were called out by name in the first message of the thread: http://lists.digium.com/pipermail/asterisk-dev/2008-November/035099.html |
| 16:57.02 | Qwell | that was like 3 years ago :p |
| 16:57.17 | philipp64|laptop | I didn't say it was recent. I just said it happened. ;-) |
| 16:57.22 | russellb | what's chan_rtp |
| 16:58.08 | mjordan | in that case, the next step would be for someone to update the patch to apply to trunk. When the patch has been written and a license agreement signed, the issue can be reopened and the patch attached. |
| 16:58.25 | mjordan | having open issues with no code associated with them doesn't do anyone any favors |
| 16:59.29 | philipp64|laptop | there is no patch. |
| 16:59.51 | philipp64|laptop | I'm trying to reinvigorate interest in the feature. |
| 17:00.01 | Qwell | What problem does it solve? |
| 17:00.18 | mjordan | the dev list (or this channel) would be the appropriate place then - JIRA is useful for tracking, but terrible at generating interest :-) |
| 17:00.31 | philipp64|laptop | simplifying using SIP handsets behind NAT where Asterisk is running on the GW. |
| 17:00.41 | russellb | I need a sponsor, then maybe i could do it |
| 17:00.49 | russellb | sorry, ignore me. |
| 17:01.13 | philipp64|laptop | and we were, but there was feature creep. the bug is a placekeeper for what we can all agree on, and to keep the feature within a reasonable scope. |
| 17:02.05 | philipp64|laptop | that is, we were discussing it on email... but the discussion degenerated into, "you know what else would be cool?" |
| 17:02.12 | mjordan | That isn't really how JIRA should be used. Its not meant to have "placeholders" - either there is work to be done associated with an issue, or there isn't. |
| 17:02.40 | philipp64|laptop | right. it's the record of what the feature entails. |
| 17:02.42 | mjordan | As soon as there is something that constitutes a new feature - that contributes to Asterisk - I'd be more then happy to have an issue in JIRA tracking it |
| 17:02.52 | mjordan | That would be better documented on a wiki |
| 17:02.57 | mjordan | https://wiki.asterisk.org |
| 17:03.06 | Corydon76-home | I think this proposal evolved into the security event framework, yes? |
| 17:03.13 | mjordan | Which is where things like specifications, and initial design are usually put |
| 17:03.18 | philipp64|laptop | yeah, total feature creep. |
| 17:03.22 | mjordan | Corydon76-home: looks like it, based on the mailing list I'm reading |
| 17:03.50 | Corydon76-home | philipp64|laptop: so go look at the security event framework. It's in Asterisk, right now |
| 17:04.05 | philipp64|laptop | I just need 3 hooks in SIP (and eventually MGCP, H.323, skinny) that can be used to indicate the need for a NAT hole. |
| 17:04.21 | Corydon76-home | Not hooks. Events. |
| 17:04.28 | philipp64|laptop | that works too. |
| 17:04.50 | Corydon76-home | The events can trigger an external log watcher to do what you want |
| 17:05.10 | mjordan | https://wiki.asterisk.org/wiki/display/AST/Asterisk+Security+Framework |
| 17:05.18 | philipp64|laptop | can you point me at it? I've not hacked ASterisk since 1.6.2. |
| 17:05.27 | philipp64|laptop | I'm a little out of touch. |
| 17:06.44 | mjordan | The framework was added in Asterisk 1.8. elguero added initial support for SIP security events in Asterisk 10. |
| 17:07.03 | mjordan | But since its a framework, additional events can be added to cover other scenarios |
| 17:07.39 | russellb | and if it's not really security related, you can use the event API directly .. |
| 17:08.24 | russellb | (doesn't sound like this really fits) |
| 17:11.12 | philipp64|laptop | I just read the document... seems like a roundabout way to go about things. |
| 17:11.53 | philipp64|laptop | or maybe I'm just overlooking something. |
| 17:12.45 | russellb | see include/asterisk/event.h ... search around for AST_EVENT_MWI |
| 17:12.56 | russellb | that should give you an idea of how that API can be used |
| 17:12.57 | philipp64|laptop | also, it's not clear that the feature would be entirely passive. |
| 17:13.33 | russellb | well i'm not clear on what the feature is |
| 17:13.42 | philipp64|laptop | it might be responsible (for instance) for generating the part of the address remapping that then would get re-written in the SDP section, etc. |
| 17:13.43 | russellb | just providing some pointers based on comments i saw in here :-p |
| 17:14.17 | Qwell | Why would there need to be remapping? chan_sip already supports NAT. |
| 17:15.01 | Corydon76-home | and supports it in really intelligent ways |
| 17:18.51 | philipp64|laptop | Qwell: I'm thinking of the case where * is running on the NATting GW... also, not all handsets implement rport, etc. correctly. |
| 17:19.30 | Qwell | I think you need to re-read the NAT options in sip.conf |
| 17:19.41 | philipp64|laptop | I'm thinking it might be possible to get Asterisk to interact with the underlying GW so that the handsets aren't even aware that they're being NATted. |
| 17:28.57 | Corydon76-home | philipp64|laptop: I think you'd be better off getting handsets that implement rport. On this side, we're interested in cross-platform compatibility, and that just isn't meshing with your requested functionality. |
| 17:36.39 | philipp64|laptop | there are commands to plumb NAT holes for other OSes, like QNX and OpenBSD. |
| 17:37.16 | philipp64|laptop | I'm offering a reference implementation for Linux. |
| 17:37.40 | philipp64|laptop | there's no reason that it can't be used as a template for other OSes, and similar implementations be done for those. |
| 18:15.40 | leifmadsen | http://iseeahappyface.com/upload/from-the-internet.jpg |
| 18:18.37 | Corydon76-home | philipp64|laptop: no, you're offering an _idea_ for a reference implementation. Not quite the same. |
| 18:20.39 | philipp64|laptop | when the appropriate hooks for notifications are in place, I'll deliver a working module. that's more than an "idea". |
| 18:21.23 | kpfleming | this has been done before, a long long time ago, in the 1.2-netsec branch which used MIDCOM to control the NAT/router/firewall device |
| 18:21.42 | kpfleming | but then most people learned that this was of little value, as the endpoints and Asterisk already handle NAT traversal quite well |
| 18:22.13 | kpfleming | if you really are interested in going this direction, i'd encourage you to investigate the Port Control Protocol currently under development in the IETF |
| 18:22.30 | philipp64|laptop | I filed the bug in 2008. |
| 18:22.51 | philipp64|laptop | I'm not sure I want to wait any longer for a protocol that could take a year or more to finalize. |
| 18:24.09 | kpfleming | well, there's a significant lack of interest from the remainder of the community for such a solution at this point, it seems :-) |
| 18:24.20 | kpfleming | but you are certainly welcome to build something and post it for people to try |
| 18:25.17 | philipp64|laptop | which community? |
| 18:25.31 | philipp64|laptop | there are people in OpenWRT who would like to see this. |
| 18:25.33 | kpfleming | the asterisk community. i haven't seen discussion of this sort of idea for ages. |
| 18:25.51 | kpfleming | well, that's good then, you have an interested user base. |
| 18:26.15 | philipp64|laptop | as I said, I can do the NAT portion, but I'm looking for someone familiar with the SIP stack to collaborate with. |
| 18:26.48 | philipp64|laptop | Olle said he was interested but had no time... that was a couple of years ago... |
| 18:27.04 | kpfleming | well, i personally believe you are underestimating the work required, but that's another issue |
| 18:27.23 | philipp64|laptop | ok, I'm listening. |
| 18:27.27 | kpfleming | the more important issue is that it sounds like you are wanting to change the way that chan_sip behaves in some significant ways |
| 18:27.34 | Corydon76-home | Someone who has the time and possibly even the inclination is Brian Capouch. You could try him. |
| 18:27.51 | Corydon76-home | College professors tend to have time flexibility |
| 18:28.12 | philipp64|laptop | is he ever on this channel? |
| 18:28.39 | kpfleming | i don't think so |
| 18:28.43 | Corydon76-home | Haven't seen him in awhile. I know he's around, though |
| 18:30.00 | philipp64|laptop | ok. will try him. thanks. |
| 19:52.11 | tzafrir_laptop | sruffell, looks like the ktime.h was added in 2.6.16 . So this looks like a good time to commit the pre_2.6.18 changes |
| 20:02.05 | sruffell | tzafrir_laptop: I agree….anyone on users who wanted to object had their chance... |
| 20:02.16 | tzafrir_laptop | nope |
| 20:02.34 | sruffell | I mean..they had their chance to object…and nobody did. |
| 20:04.51 | kpfleming | prepares his post-commit objection diatribe |
| 20:05.18 | sruffell | heh |
| 20:10.20 | tzafrir_laptop | minor nit: in patch 4: do you really need the extra ifdef CONFIG_MODULE_UNLOAD ? |
| 20:10.22 | russellb | prepares his +1 to kpfleming's diatribe |
| 20:10.47 | sruffell | eh…not really…I added that in when I originally had that string defined as a const int... |
| 20:11.03 | sruffell | so..good point |
| 20:19.58 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-dajbovqorrkhydqt) |
| 20:41.43 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 20:41.43 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:55.19 | Qwell | kpfleming: 302ing the discussion about 302s. |
| 20:55.20 | putnopvut | I predict kpfleming is about to talk about some weird issue with Qwell .... now! |
| 20:55.26 | putnopvut | dangit, 1 second too late |
| 20:55.33 | kpfleming | so here's an odd issue: normally, when chan_sip creates a channel due to receiving an INVITE, the SIP_HEADER() dialplan function can be used to extract headers from that request |
| 20:56.18 | kpfleming | when chan_sip creates a channel due to receiving a 302, that created channel is a *Local* channel (which replaces the original SIP channel) and thus SIP headers included in the channel-creating 302 response are not available |
| 20:56.48 | Qwell | kpfleming: I suspect that it's not chan_sip actually creating the channel directly. It feels like app_dial's forward stuff is handling it. |
| 20:56.54 | putnopvut | Point of order: is it chan_sip that creates the local channel or the dialing app? |
| 20:57.04 | kpfleming | promiscuous jinx |
| 20:57.23 | Qwell | <PROTECTED> |
| 20:57.26 | kpfleming | yes, it's the forwarding logic in app_dial/app_queue/app_followme/dialing API/etc. |
| 20:57.37 | putnopvut | Okay, cool. |
| 20:58.34 | putnopvut | I don't know of any situation in which SIP_HEADER() can be used to extract details from a SIP response. |
| 20:58.38 | kpfleming | so here we have a situation where a SIP message (albeit a response, not a request) resulted in channel creation, but any special headers from that message are not accessible |
| 20:58.55 | kpfleming | that's right, it cannot be used for that normally |
| 20:59.23 | kpfleming | although i'd say that in fact the real reason is that it is supposed to extract headers from the 'thing' that created the channel, it's not specific to requests or responses |
| 20:59.31 | putnopvut | I'm not really sure how you're supposed to be able to get data for a response on a channel that no longer exists. |
| 20:59.39 | kpfleming | magic? |
| 20:59.56 | putnopvut | I just disagree with your assessment of what SIP_HEADER is supposed to do. |
| 20:59.59 | kpfleming | i can envision ways |
| 21:00.20 | putnopvut | As far as I'm concerned, it is only applicable to SIP channels, and only can be used to get headers from an INVITE. |
| 21:00.33 | kpfleming | do the docs say that anywhere? |
| 21:00.47 | Qwell | actually yes |
| 21:00.52 | Qwell | Gets the specified SIP header from an incoming INVITE message. |
| 21:00.56 | kpfleming | well then |
| 21:01.31 | kpfleming | ponders |
| 21:02.47 | putnopvut | btw, what is the issue you guys are talking about? |
| 21:02.54 | kpfleming | it's a phone related thing |
| 21:03.03 | putnopvut | Much of Asterisk is phone-related |
| 21:03.08 | kpfleming | we want to enable 302 redirect on an incoming call to voicemail |
| 21:03.36 | putnopvut | ick |
| 21:03.52 | putnopvut | So I'm guessing that there's some X-??? header in the 302 that has the extension and context to dial for Voicemail? |
| 21:04.01 | kpfleming | no, just an indication that the call should be sent to voicemail |
| 21:04.35 | putnopvut | Okay, assuming you're talking about Digium phones, then there's a "Msgs" button on the phone. |
| 21:04.44 | putnopvut | THat means the phone knows what to dial to get to voicemail. |
| 21:04.50 | kpfleming | nope |
| 21:04.56 | kpfleming | not when visual voicemail is in use |
| 21:04.57 | putnopvut | dang |
| 21:09.22 | kpfleming | i was thinking maybe Reason: could be used for this purpose, then chan_sip could generically capture that and pass it to whoever created the outbound channel... but I don't see any RFC stating that Reason can be used in a 302 response |
| 21:11.33 | kpfleming | it could be done with Diversion, i suppose |
| 21:16.18 | putnopvut | Yeah, there's a "reason" parameter for Diversion that can be populated with whatever you want. |
| 21:16.39 | putnopvut | There are predefined values, but I believe any quoted string is valid. |
| 21:17.14 | putnopvut | Indeed I am correct. |
| 21:20.22 | seanbright | miracles do happen |
| 21:20.31 | seanbright | that was shitty. i apologize. |
| 21:23.42 | putnopvut | I'm probably wrong more than I am right |
| 21:23.54 | leifmadsen | putnopvut: at least you're right about that |
| 21:23.55 | putnopvut | Now I just have to hope that applies to my previous sentence |
| 21:24.36 | Qwell | leifmadsen: what if that sentence being true caused his ratio to go past the 50% line? |
| 21:24.50 | leifmadsen | Qwell: I'm not concerned about that |
| 21:24.55 | Qwell | touche |
| 21:25.45 | *** join/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 21:29.58 | alecdavis | where is channel_internal.h in trunk |
| 21:30.00 | alecdavis | <PROTECTED> |
| 21:30.01 | alecdavis | channel.c:70:39: error: asterisk/channel_internal.h: No such file or directory |
| 21:32.41 | alecdavis | its back. |
| 21:34.02 | alecdavis | thanks terry |
| 21:38.13 | kpfleming | putnopvut: Qwell: sorry, had someone in my office. so... chan_sip could collect the reason string from the Diversion header (it may already do that), but then getting it back to app_dial could end up requiring an API change. that's not good. |
| 21:38.42 | Qwell | kpfleming: fwiw, this same scenario holds true for REFER, for existing calls |
| 21:39.05 | kpfleming | for a blind transfer, yes |
| 21:39.12 | Qwell | and chan_sip appears to set a diversion reason variable in that case |
| 21:39.17 | Qwell | dialplan variable, that is |
| 21:39.26 | kpfleming | ahh, so we're getting somewhere now |
| 21:39.52 | file | returns to an interesting conversation |
| 21:40.34 | Qwell | __SIPREDIRECTREASON |
| 21:41.03 | kpfleming | which is then inherited into the local channel through black magic |
| 21:41.06 | Qwell | right |
| 21:41.14 | kpfleming | so... if a 302 set the same variable, then we'd be golden |
| 21:41.20 | Qwell | it should |
| 21:41.24 | kpfleming | if a 302 that contained a Diversion header, i mean |
| 21:41.27 | Qwell | right :) |
| 21:41.58 | kpfleming | any chance the code already does this? |
| 21:42.03 | kpfleming | in 1.8, i mean |
| 21:42.16 | Qwell | set the variable, you mean? |
| 21:42.41 | Qwell | It's done in get_rdnis in 1.8 |
| 21:42.46 | kpfleming | for 302 responses? |
| 21:42.49 | Qwell | called from change_redirecting_information() |
| 21:42.53 | Qwell | which is called for 302 |
| 21:42.58 | kpfleming | score! |
| 21:43.06 | Qwell | well, appears to. It is chan_sip, after all |
| 21:57.14 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-zxxxxffawgjnprom) |
| 22:37.34 | tzanger | hm |
| 22:38.27 | tzanger | has anyone ever needed to use container_of() to get at a dahdi_span()'s parent's parent? |
| 22:38.28 | tzanger | (bear with me, I'm sure it's a stupid question) |
| 22:38.42 | tzanger | dahdi_chan has a pvt I can use, but dahdi_span has no such thing |
| 22:39.08 | tzanger | I have a device struct that has a dahdi_device *ddev member which is populated by dahdi_create_device() |
| 22:39.41 | tzanger | dahdi_spans have a parent member which points back to that dahdi_device struct created with dahdi_create_device() |
| 22:40.19 | tzanger | I was originally thinking I could just use struct my_dev *d = container_of(dahdi_span->parent, struct my_dev, ddev) |
| 22:40.54 | tzanger | but ddev is a pointer, and container_of() doesn't expand properly with pointers |
| 22:41.29 | kpfleming | doesn't container_of need a type as its third argument? |
| 22:41.54 | kpfleming | no... it needs a struct member name |
| 22:42.18 | tzanger | correct |
| 22:42.29 | tzanger | ddev is a struct member, but it's a pointe type (struct dahdi_device *) |
| 22:43.23 | tzanger | what usually occurs in dahdi drivers is that the dahdi_span struct is a member of the device structure |
| 22:43.35 | kpfleming | right, that's what container_of is intended to use |
| 22:43.35 | tzanger | that presents no problems at all since container_of() likes members that aren't pointers |
| 22:43.38 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-ncdgfxunqmlqzqlw) |
| 22:44.01 | tzanger | I have to look at the drivers that implement dynamic or multiple spans I think |
| 22:44.28 | tzanger | since you can't use container_of() with an dahdi_span array (since you dn't know which array element you are) |
| 22:45.06 | kpfleming | i don't see any container_of() calls in the drivers that implement dynamic spans |
| 22:46.08 | tzanger | the wct4xxp uses it, I'm just looking at it now |
| 22:46.25 | tzanger | it's using it to find t4_span though which isn't difficult |
| 22:46.29 | tzanger | and then yeah there it is |
| 22:46.43 | tzanger | it just has an owner member poitning back to t4 |
| 22:46.45 | tzanger | that's what I was trying to avoid doing |
| 22:46.54 | tzanger | I'm getting tripped up in early optimization again :-) |
| 22:47.04 | kpfleming | wct4xxp is not dynamic spans though |
| 22:47.08 | tzanger | no |
| 22:47.18 | tzanger | wct24xxp woudl be |
| 22:47.23 | kpfleming | nope |
| 22:47.36 | tzanger | no? it can have up to 8 digital spans and 1 analog span |
| 22:48.04 | kpfleming | right, but they are not dynamic, they are instantiated at module load time and then never touched |
| 22:48.18 | tzanger | oh I see what you're saying |
| 22:48.29 | kpfleming | it's not a fixed-configuration, if that's what you mean |
| 22:48.30 | tzanger | that was what i was meaning by dynamic as in they weren't a fixed number of spans for the card |
| 22:48.36 | tzanger | yeah |
| 22:48.38 | kpfleming | but neither is wct4xxp |
| 22:48.53 | tzanger | no, wct4xxp is fixed-config |
| 22:49.06 | kpfleming | no, it can support 2 span cards and 4 span cards |
| 22:49.26 | tzanger | actually a question for you.. would you consider a four wire analog channel to be E&M signalled? or is E&M something more specific? |
| 22:49.41 | tzanger | (sorry for the quick topic change, I just remembered I had that question as well) |
| 22:49.46 | kpfleming | that depends on how the wires are being used |
| 22:50.11 | kpfleming | there are multiple varieties of E&M as well |
| 22:50.45 | tzanger | it's a literal earpiece and mic (pilot headset), four wires all the way to the chip that samples and generates audio |
| 22:51.40 | kpfleming | so one pair for each direction |
| 22:51.58 | tzanger | correct |
| 22:52.14 | kpfleming | the only analog E&M i ever personally used was six wires: two for 'ear', two for 'mouth', and two for signalling |
| 22:52.48 | tzanger | ah well yes there are another three signals too: ring indication, offhook indication and push to talk |
| 22:53.05 | tzanger | well ring indication, offhook detect and ptt |
| 22:53.33 | kpfleming | what about the 250VAC 'alert' signal :-) |
| 22:53.53 | tzanger | hahaha |
| 22:54.23 | tzanger | that's handled separately by the aircraft seat interface |
| 22:54.31 | tzanger | the heater gets a little warm if it detects that you're not paying attention :-) |
| 22:56.55 | kpfleming | ok, so there is 2-wire E&M, which is misnamed. it uses two wires for audio (using hybrids), and two wires for signaling. |
| 22:57.03 | kpfleming | but that still doesn't match what you are talking about. |
| 22:58.56 | tzanger | not at all... and it really doesn't matter what the correct signalling is called |
| 22:59.15 | tzanger | as long as asterisk passes the right information to dahdi and I grab the ioctl |
| 23:08.43 | *** part/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 23:42.31 | russellb | seanbright: it is done. |
