| 01:45.53 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 01:45.53 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 02:36.46 | *** part/#asterisk-dev mjordan (~mjordan@adsl-98-81-83-165.hsv.bellsouth.net) |
| 04:33.36 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 05:17.47 | *** join/#asterisk-dev Skavin (~kevins@202-180-69-27.me.tranzpeer.net) |
| 06:02.47 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:02.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:43.02 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 06:49.26 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:49.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:30.59 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:2cd4:f5e1:467b:3f54) |
| 07:31.17 | oej | Morning |
| 07:36.44 | Skavin | or Evening as the case may be |
| 07:39.06 | Skavin | I have been looking at an issue with RFC2833 and direct media. Where would I get the codec identifier mappings that the incoming channel used when sending an outgoing invite |
| 07:41.13 | Skavin | I have devices sending 101, 99 and 109 as codec identifiers for telephone-event and asterisk is passing out 101 |
| 07:41.54 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f5fc:7d14:5b66:cba0) |
| 07:44.38 | Skavin | I see it copied into p->rtp->payloads in process_sdp |
| 07:45.25 | oej | What's your problem, really? |
| 07:45.34 | oej | What are you trying to resolve? |
| 07:46.49 | Skavin | I am using direct media an invite with "a=rtpmap:109 telephone-event/8000" comes in asterisk invites with "a=rtpmap:101 telephone-event/8000" |
| 07:47.39 | Skavin | the 2 clents do not understand each others dtmf because asterisk changed the identifiers |
| 07:51.24 | Skavin | I am running 1.8.20.1 |
| 07:53.59 | oej | Does asterisk do this in the re-invite or the initial invite? |
| 07:54.36 | Skavin | initial invite I have set directmedia=yes |
| 07:55.19 | oej | directmedia controls the re-invite. |
| 07:55.29 | oej | So the initial invite sets up an RTP stream between asterisk and the device |
| 07:55.37 | oej | Then asterisk re-invites so the devices talk directly |
| 07:55.59 | Skavin | and directrtpsetup=yes |
| 07:56.16 | oej | Oh, that's so buggy that you do NOT want to use it. It will certainly cause a lot of issues. |
| 07:57.14 | Skavin | I have patched my T38 issues and thought it should not be too bad to get this working |
| 07:57.56 | Skavin | asterisk as passing the correct IP but allocating a port and passing that |
| 07:57.57 | oej | Good luck. You are going deep into the bridging code in order to try to fix that. |
| 07:58.20 | oej | I would start with fixing it without directrtpsetup |
| 07:58.38 | oej | Then when that works with correct DTMF payloads, start trying with directrtpsetup |
| 07:59.02 | Skavin | OK I will have a go |
| 07:59.45 | Skavin | I will submit a bug and and initial patch for T38 when I get a chance |
| 08:00.11 | Skavin | will you accept patches vs 1.8 or do they have to be against trunk |
| 08:17.29 | oej | Depends if it is a bug fix or a new feature |
| 08:17.35 | oej | Bug fixes are committed to 1.8 |
| 08:17.40 | oej | New features in trunk |
| 08:17.59 | Skavin | thanks |
| 08:18.06 | oej | I tend to publish my 1.8 work on new features as an svn branch, since many people need it. |
| 08:18.28 | *** join/#asterisk-dev saghul (~saghul@ip3e830637.speed.planet.nl) |
| 10:57.42 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 11:10.10 | snuff-home | mm.. is there a way i can view / print a dump of what my config looks like after * has read it with the new 'ast config framework / sorcery' ? |
| 11:10.31 | snuff-home | aka i want to see how dud it is or how it might be wrongly mapped |
| 11:16.43 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 11:24.42 | file | there's no command to do it or anything, but the API allows it |
| 11:25.42 | snuff-home | i'm assuming that 'configObject name=blah' is the equiv of critera type=blah |
| 11:26.08 | file | I don't know that stuff |
| 11:26.17 | file | (the documentation aspect) |
| 11:27.39 | snuff-home | k.. looking at code.. ast_sorcery_apply_default(ast_sip_get_sorcery(), "identify", "config", "res_sip.conf,criteria=type=identify"); |
| 11:28.37 | file | yes, that adds a default configuration file sorcery wizard for the "identify" object type that requires a type=identify line to be present within the configuration entry for it to be considered a match |
| 11:29.20 | snuff-home | mm.. but that's what i'm getting at.. |
| 11:29.48 | snuff-home | if in my doco i have a 'configObject name=blah'.. i assume it gets mapped to type=blah |
| 11:30.11 | snuff-home | aka name=type when set at the configObject level |
| 11:30.40 | snuff-home | not that i should have to put type=something in every configOption line |
| 11:30.48 | file | the name as given to the configuration framework and thus the documentation is the second value in there, "identify" |
| 11:30.53 | file | so far afaik that matches the type=<name> |
| 11:30.55 | file | but it doesn't have to |
| 11:33.43 | snuff-home | is now confused gives up on making it work work and puts the info in the doco for someone else to figure out how to make it load properly |
| 11:34.07 | file | yeah mjordan knows that stuff, I don't |
| 11:34.39 | snuff-home | off to watch 'the following' then come back to code |
| 11:45.11 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:03.13 | *** join/#asterisk-dev [1]Jsa (~jsa@213.80.127.210) |
| 12:03.53 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:f5fc:7d14:5b66:cba0) |
| 12:09.43 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:09.43 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 12:49.30 | oej | I have a mild suspicion that the CDR disposition decision tree is flawed… I get FAILED calls with cause 19 which is NO ANSWER. They should propably have disposition NO ANSWER. |
| 12:52.36 | WIMPy | If it's only the CDR... |
| 12:53.06 | oej | Well, they should be logical. And I know that mjordan just loves CDR issues. |
| 12:53.43 | WIMPy | What the user gets displayed seems a lot more important to me and that can be pretty randome :-( |
| 12:54.15 | oej | How do you mean? User does not normally get CDRs displayed. Or do you have a more important issue? |
| 12:54.55 | WIMPy | No, but if I call someone and my phone displays "Service unavailable". What does it tell me? |
| 12:55.27 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-erfxqvtqkloporeg) |
| 12:55.33 | oej | Oh, phones should propably not present those messages. That's a 503. Means that this server is feeling pain and doesn't want to fulfill your wishes today. |
| 12:56.05 | WIMPy | No, it happens when the called user has DND activated. |
| 12:56.34 | WIMPy | But that's impossible to find out without tracing the call at the console. For the user it's just a gamble. |
| 12:57.33 | oej | DND activated where? |
| 12:57.43 | WIMPy | On the phone. |
| 12:58.04 | oej | So if I call your phone and you have DND, I get "Service unavailable" ? |
| 12:58.22 | WIMPy | And yes, I have more important issues with CDR as well, like the most important bit missing or the inability to get billsecs right with announcements. |
| 12:58.45 | oej | Yes, that's critical |
| 12:58.58 | oej | But isn't that DND stuff a dialplan issue? |
| 12:59.15 | WIMPy | Probably. That's what I get. And you can imagine that I thought somethig was broken. |
| 12:59.59 | oej | mmm |
| 13:00.24 | WIMPy | No it's the translatin of the causes. Somehow the DND is interpreted as circuit-busy -> CONGESTION. |
| 13:01.27 | WIMPy | You just cannot trust anything any more these days :-( |
| 13:13.45 | oej | I think you chan change that in the dialplan. What does the phone really send? |
| 13:15.19 | WIMPy | 480 Do Not Disturb |
| 13:15.20 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-144-164.user.veloxzone.com.br) |
| 13:16.15 | WIMPy | Same happens whan rejecting a call on a classic phone, BTW. |
| 13:16.21 | oej | That's hangupcause AST_CAUSE_NO_ANSWER |
| 13:17.29 | oej | Hard to separate from real NO ANSWERs, they should propably select some other code. |
| 13:17.53 | oej | You can anyway select which code you send to the phones |
| 13:18.10 | WIMPy | That does not look like NO ANSER at all. |
| 13:21.39 | WIMPy | Anyway I get 34 (no circuit/channel available), te IAX part should be pransparent, I think. |
| 13:22.29 | WIMPy | For the local test I get 19 (rejected) which is correct, but also results in a "Service unavailable" on the sip phone. |
| 13:22.45 | oej | Again, try changing the hangup cause in the dialplan |
| 13:22.56 | oej | hangup(xx) where xx is the cause code you want to use |
| 13:23.34 | WIMPy | Yes, but at least in the 2nd example it is correct. |
| 13:24.00 | WIMPy | And how do I know if the cause that was set is correct or not? How can I decide if I wat to change it? |
| 13:27.40 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:27.40 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:28.51 | WIMPy | Back to what I intended to look in to today: Has there been any changes to how chan_sip does dialplan matching recently? There seems to be an isse but I have been playing around with the dialplan |
| 13:29.17 | WIMPy | too much, attempting to make it always work, that I don;t know if that's possibly an regression. |
| 13:29.48 | WIMPy | But I can't remember seeing anything done that might have an influence. |
| 13:30.13 | file | nope |
| 13:38.54 | oej | I check 1.4 so there's no changes recently :-) |
| 13:40.41 | wdoekes | WIMPy: the '-' is ignored.. not very recently |
| 13:42.03 | WIMPy | No "-" involved. |
| 13:43.34 | WIMPy | But the whole "-" thing surely has been interesting... |
| 13:44.51 | WIMPy | Just like special extensions being case insensitive. |
| 13:51.47 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 13:51.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:53.06 | tzafrir | Qwell: if my certificate expired, should I ask you for a new one? |
| 13:56.55 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-mnukcofocwyfcprt) |
| 13:56.55 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:03.04 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-144-164.user.veloxzone.com.br) |
| 14:31.57 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:31.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:46.42 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 14:46.42 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:47.44 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:47.44 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:55.45 | mjordan | file: putnopvut: anyone else |
| 14:55.50 | mjordan | amaflags, accountcode |
| 14:56.00 | mjordan | should they be properties of a channel (as they are now), or properties of a CDR? |
| 14:56.16 | putnopvut | CDR imo |
| 14:56.17 | mjordan | the current state of 'both' is less then ideal |
| 14:56.35 | mjordan | only problem with CDR (at least for accountcode) is that CEL may want the info as well |
| 14:56.39 | mjordan | not sure about ama |
| 14:56.53 | putnopvut | doesn't even know what amaflags are |
| 14:57.15 | tzafrir | so, who should I ask for renewing my SVN certificate? |
| 14:57.17 | mjordan | fairly specific CDR concept that defines whether or not the record is used for billing, documentation, or should be ignored completely |
| 14:57.22 | mjordan | tzafrir: Qwell |
| 14:57.54 | mjordan | and of course, CEL duplicates the AMA flags :-( |
| 14:58.12 | file | how would you set an accountcode on CDRs without the channel having it as well, just do it at creation? |
| 14:58.51 | WIMPy | is pretty sure it should be on CEL as well. |
| 15:09.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:36.01 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 15:42.42 | file | mjordan, ^^^ |
| 15:45.20 | mjordan | file: you'd have to do it through the CDR function |
| 15:45.25 | mjordan | but yes, I'm not a fan of that. |
| 15:46.10 | mjordan | since we have multiple billing engines (CDR, CEL), it feels like keeping these things as properties of the channel - which is where they both are currently - would keep the code duplication down the most |
| 15:48.11 | oej | Accountcode is definitely primarily a property of the channel - the billing owner, the customer… There is no case that I know of where one channel has multiple accountcodes that are specific to individual cdrs - or? |
| 15:48.27 | oej | Arrgh. I should never get involved in CDR discussions. |
| 15:49.01 | putnopvut | That is a good policy :) |
| 15:49.05 | putnopvut | CDRs == pain |
| 15:49.24 | oej | Officially I don't even know what it means. |
| 15:49.34 | mjordan | oej: Call Detail Ruination |
| 15:49.36 | file | CDRs are a pain because of what we let people get away with calling bugs in the way we do stuff |
| 15:49.53 | mjordan | it's hard to say something isn't a bug when you haven't written anything down ;-) |
| 15:49.54 | file | rabbit hole of doom ;( |
| 15:50.24 | oej | Let's make a clear statement: Asterisk cdrs work as expected. It's your expectations that needs to be adjusted. |
| 15:50.37 | mjordan | +1 to that |
| 15:50.38 | oej | Problem solved. |
| 15:50.38 | file | mjordan, well... I agree to an extent |
| 15:51.10 | file | mjordan, but the views of what are to be delivered from the CDR functionality are what have differed |
| 15:51.31 | file | and thus bug for one, not a bug for the other |
| 15:52.12 | file | when all is said and done at the end of the CDR stuff there has to be a line and it can't be crossed... or it will happen again |
| 15:52.25 | file | (the mess that exists now and the history with it) |
| 15:52.37 | WIMPy | Are you trying to replace the bug vs missing feature thing by the next level of bug for me or bug for you? |
| 15:53.02 | oej | It's a missing bug feature. Follow the white bug. |
| 15:53.04 | oej | :-) |
| 15:53.27 | WIMPy | Missing bug is definitely a feature :-) |
| 15:53.34 | oej | Can we depreacte transfers? If we do, CDRs will be much easier. |
| 15:53.58 | file | WIMPy, more like "I need CDRs to do this" when "this" is not what they are written to do/supposed to be used for |
| 15:54.54 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 15:54.54 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 15:55.20 | WIMPy | Ok, so is "broken by desigen" a bug or a missing feature? |
| 15:55.39 | file | there is no design and in the past nobody has agreed on what that design should be like |
| 15:55.51 | oej | I think file hits the nail on the head. |
| 15:56.01 | file | in my mind CDRs should give you what you need to bill - but the actual act of processing and billing should NOT exist within Asterisk |
| 15:56.08 | WIMPy | Did someone say "historical reasons"? |
| 15:56.09 | oej | CDRs has just been there and been extended - much like realtime. Without design. |
| 15:56.44 | WIMPy | Ok, s/design/chance/ |
| 15:56.46 | oej | CDRs are also for logging call attempts and fraud detection and much more. Not just billing. |
| 15:57.13 | oej | The only way to solve this is to break "one cdr, one call" |
| 15:57.23 | file | I can rant about CDRs and such all day long >_> |
| 15:57.26 | oej | we need to be able to publish a set of cdrs for a call |
| 15:57.26 | file | and have |
| 15:57.56 | WIMPy | Who wants to define "a call"? |
| 15:58.43 | oej | qwell steps forward. |
| 15:59.11 | file | mjordan is working on the mess |
| 15:59.59 | file | https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification |
| 16:00.51 | WIMPy | Lets try something different. Will chan_gulp have better overlap support? |
| 16:01.05 | file | there's nothing to say it couldn't |
| 16:01.49 | oej | Is overlap really important in this age? |
| 16:02.32 | WIMPy | Do you think the user should assist the machine or should the machine assist the user? |
| 16:02.49 | oej | I have no installation that use overlap dialing in SIP |
| 16:03.28 | oej | Just curious on why it's needed any more. Users are used to cell-phone style dialing - enter number, press green button to call. |
| 16:04.44 | WIMPy | Not in my experience. Maybe they only use saved contacts on their cell phones, but that's been a big issue to me. |
| 16:05.03 | WIMPy | They complain about too much delay and not having enough time at the same time. |
| 16:05.29 | oej | Where are you based? Still curious. |
| 16:05.37 | WIMPy | de |
| 16:06.06 | oej | You have an interesting number plan then, much like us in SE |
| 16:06.13 | WIMPy | You know that strange area where a good 30% of phone lines used to be BRIs. |
| 16:06.25 | WIMPy | It's completely open, yes. |
| 16:07.42 | oej | So like us, a phone dialplan doesn't help much. |
| 16:07.59 | WIMPy | By completely I mean that neither areacodes nor subscriber numbers have fixed lengs and you can make DDIs as long as you like. |
| 16:08.03 | WIMPy | Not at all. |
| 16:08.05 | oej | I still haven't got a lot of demand for overlap. But the german market is very different. |
| 16:44.47 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:44.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:22.51 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:22.52 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:34.31 | *** join/#asterisk-dev kpfleming (4173e21c@gateway/web/freenode/ip.65.115.226.28) |
| 17:41.22 | file | kpfleming, you. |
| 17:41.37 | *** join/#asterisk-dev kpfleming_ (4173e21c@gateway/web/freenode/ip.65.115.226.28) |
| 17:43.55 | mjordan | and bye? |
| 17:44.37 | *** join/#asterisk-dev Gugge (gugge@kriminel.dk) |
| 17:44.56 | file | turns mjordan upside down |
| 17:49.50 | mjordan | 's blood runs to his head |
| 19:20.41 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 19:20.41 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 19:32.36 | *** join/#asterisk-dev GameGamer43_ (uid5533@gateway/web/irccloud.com/x-qynpmidpttjbzapu) |
| 19:48.35 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:38.40 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-mnukcofocwyfcprt) |
| 20:44.30 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 20:44.32 | rgagnon | w maybe? |
| 20:44.32 | rgagnon | http://wiki.centos.org/TipsAndTricks/ReinstallGRUB |
| 20:44.37 | rgagnon | oops wrong window |
| 20:44.40 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 20:55.16 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 21:24.10 | WIMPy | Does anyone have an idea why in chan_sip.c: get_destination at the very end the check for ALLOWOVERLAP and canmatch is not inside the else of the if(req->method==SIP_SUBSCRIBE)? |
| 21:26.23 | WIMPy | Looks like it would allow incomplete subscriptions, but that doesn't make any sense, or does it? |
| 21:45.07 | pabelanger | So, we implemented our own pubsub in asterisk 12 right? |
| 21:45.20 | pabelanger | s/we/you |
| 21:55.14 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:55.14 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:05.32 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-bpvfktzlfllxtuxz) |
| 22:11.28 | *** join/#asterisk-dev GameGamer43 (uid5533@gateway/web/irccloud.com/x-tgjcyvgnjoxehknc) |
| 22:34.44 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 22:34.44 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:37.45 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 22:37.46 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 22:45.18 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 23:02.34 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |