| 00:00.00 | skirmisha | so therefore i have to pass it from chan_sip.c to ast_chan |
| 00:00.19 | skirmisha | and have it like c->ip |
| 00:00.27 | skirmisha | is there easy way to do it? |
| 00:02.25 | putnopvut | You're never going to have c->ip because not all channel types use IP addresses. Your best bet is to put what you want in chan_sip instead. In handle_request_invite() in chan_sip.c, there is a call to get_destination(). It can return several different error types. For instance, if it returns SIP_GET_DEST_EXTEN_NOT_FOUND, you could print the IP address at that point instead. |
| 00:04.30 | skirmisha | let me dig it |
| 00:05.40 | putnopvut | I'm about to head out for the evening. Good luck getting what you need done :) |
| 00:06.55 | skirmisha | thanks a lot |
| 00:12.24 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:12.25 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 00:24.41 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 00:24.42 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 02:03.04 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 02:03.05 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 03:31.59 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 04:08.31 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe93:fa45) |
| 05:06.05 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@66-232-82-250.ctcweb.net) |
| 06:38.34 | wedhorn | snuff-work: you still around |
| 06:39.05 | snuff-work | yep |
| 06:39.27 | snuff-work | going to add that named group to ur original review for callgroups ? |
| 06:39.45 | wedhorn | I'm heading off to Fiji for a couple of weeks, so I'll leave the commits til I get back |
| 06:39.56 | snuff-work | oh nice :) |
| 06:40.43 | snuff-work | well.. not really awesome.. hope stuff is still 'in-place' after the cyclone that just went through |
| 06:44.16 | snuff-work | but yer before u go.. update the group pickup to have the 'named group' we fixed up yest :) |
| 06:50.09 | wedhorn | will try |
| 06:50.21 | wedhorn | sort of dealing with other last minute stuff at the moment |
| 06:50.42 | wedhorn | can you send it to me as a patch (make it a bit easier) |
| 06:50.45 | snuff-work | k |
| 06:53.05 | snuff-work | sent |
| 07:01.13 | wedhorn | got it |
| 07:04.50 | wedhorn | snuff-work: any reason you moved the ast_module_ref (about line 4950) |
| 07:05.05 | snuff-work | nope.. probably could have left it where it was |
| 07:07.24 | wedhorn | okay, moved it back, waiting for compile |
| 07:11.43 | wedhorn | okay, namedgroup added to the patch |
| 07:12.16 | *** join/#asterisk-dev capnkooc (~capnkooc@186.96.91.222) |
| 07:15.28 | snuff-work | i commented on ur other patch with something petty.. aka moving 'len' inside scope its used.. even though i'm sure the compiler will optimise it in the same way ;) |
| 07:17.25 | wedhorn | yep, but for readability I prefer my approach ;) |
| 07:19.48 | snuff-work | but u use the other method further down |
| 07:19.53 | snuff-work | which is the funny bit |
| 07:20.08 | snuff-work | one instance its inside.. other its outside :) |
| 07:20.49 | snuff-work | see 6534 |
| 07:21.19 | snuff-work | anyway.. train waits for no man.. unless it gets delayed |
| 07:21.42 | wedhorn | yeah, but that's a switch and really is only for the SOFTKEY_BKSPC part |
| 07:21.47 | wedhorn | sort of a sub sub |
| 07:22.08 | wedhorn | generally we try to get them to the beginning |
| 07:31.13 | *** join/#asterisk-dev zerohalo (~zerohalo@74.61.196.236) |
| 08:10.30 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 08:27.41 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 08:28.32 | bombev | good morning |
| 09:55.52 | *** join/#asterisk-dev Tim_Toady (~fuzzy@194.50.55.200) |
| 10:08.51 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 11:24.15 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 11:24.15 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 11:52.24 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 11:52.25 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 13:33.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 13:33.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:55.17 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-xwvphzfqsybtvhek) |
| 13:56.34 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:56.35 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:30.45 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:30.46 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:49.50 | seanbright | so let's say for MoH i have a custom class that takes audio in slinear from an external process |
| 14:50.20 | seanbright | and then 10 calls come in and hit MusicOnHold(mycustomclass) |
| 14:50.28 | seanbright | and those 10 calls are natively g729 |
| 14:50.47 | seanbright | do 10 translation paths get set up? 1 for each call? |
| 14:51.10 | file | probably |
| 14:51.17 | seanbright | interesting. |
| 14:51.21 | russellb | hrm, i know it would be 10 for files based MOH |
| 14:51.38 | russellb | yeah, probably |
| 14:51.46 | seanbright | well file based starts "from the beginning" for each call |
| 14:51.48 | russellb | probably doesn't get transcoded until it hits the channel |
| 14:52.01 | russellb | it's one stream, but written to each channel in slinear |
| 14:52.02 | seanbright | 'application' based "shares" the data |
| 14:52.07 | seanbright | right |
| 14:53.25 | seanbright | during translation, new frames are created with the translated audio, correct? the original frames are untouched? |
| 15:03.39 | russellb | seanbright: yah |
| 15:07.30 | seanbright | alrighty |
| 15:31.59 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:31.59 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:43.26 | Juggie | can moh play from a stream? |
| 15:43.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:44.55 | seanbright | yes |
| 15:45.00 | seanbright | mode=custom |
| 15:45.11 | seanbright | application=something-that-spits-out-audio-to-stdout |
| 15:45.32 | Juggie | if you did something that spit out g729, would it not be possible to avoid the translation? |
| 15:45.45 | seanbright | correct |
| 15:45.52 | seanbright | you'd have to add: |
| 15:45.55 | seanbright | format=g729 |
| 15:45.59 | seanbright | but yes, that would work |
| 15:46.49 | seanbright | i just need something that will "spit out g729" |
| 15:46.58 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 15:46.58 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:47.00 | bombev | have a good one |
| 15:47.03 | seanbright | and won't make me want to turn myself into the authorities |
| 15:47.36 | Juggie | hmmmm |
| 15:47.56 | seanbright | actually, that's a question... |
| 15:48.08 | Juggie | i'm thinking. |
| 15:48.19 | seanbright | let's say i buy 10 g729 software licenses from digium |
| 15:48.23 | seanbright | or whoever |
| 15:48.42 | file | buy them from Digium, I like to eat |
| 15:48.45 | Juggie | you would need to be able to provide a playlist and get g729 output. |
| 15:48.48 | seanbright | but i never install them on to a server |
| 15:49.00 | seanbright | instead i use one of the "free" g729 implementations |
| 15:49.27 | file | if I remember right the license is only valid while using our module |
| 15:49.28 | seanbright | i think i could argue that i am properly licensed |
| 15:49.34 | seanbright | son of a bitch |
| 15:49.35 | seanbright | heh |
| 15:49.38 | Juggie | possibly |
| 15:49.41 | Juggie | but how would that benefit you |
| 15:50.04 | seanbright | because i could write a program to do my transcoding of the stream outside of asterisk |
| 15:50.24 | seanbright | application=something-that-spits-out-SLINEAR-audio-to-stdout | something-to-convert-to-g729 |
| 15:50.41 | Juggie | your smart. |
| 15:50.49 | Juggie | just write smoething that loads the digium module :P |
| 15:50.50 | seanbright | you're |
| 15:50.57 | seanbright | eh |
| 15:51.25 | Juggie | should be doable |
| 15:51.29 | seanbright | now what would be cool is something like this |
| 15:51.44 | seanbright | MusicOnHold(some-custom-class) |
| 15:51.53 | seanbright | GenerateMusicOnHold(some-custom-class) |
| 15:52.05 | seanbright | so i could delegate a single channel's audio stream as an MoH souce |
| 15:52.07 | seanbright | source* |
| 15:52.25 | Juggie | that is sometimes how it works in pots/pbx world. |
| 15:52.31 | Juggie | we have call centers with ipods doing moh |
| 15:52.57 | Juggie | the analog audio is fed back into the pbx/co |
| 15:53.03 | seanbright | yeah, we use shoutcast |
| 15:53.07 | Juggie | right. |
| 15:53.11 | seanbright | only because i don't want to install sound cards in servers |
| 15:54.09 | Juggie | lots of ways to do it... if you don't use the moh application you can do some other trickery |
| 15:54.27 | seanbright | i know that |
| 15:54.28 | Juggie | eg join the client into a meetme with an audio player |
| 15:54.35 | seanbright | meetme does mixing |
| 15:54.47 | Juggie | even if the clients are muted? |
| 15:54.59 | seanbright | i would guess yes, although i haven't looked at the code |
| 15:55.20 | Juggie | you know |
| 15:55.23 | seanbright | it would need to at minimum make the channels compatible |
| 15:55.45 | Juggie | perhaps there is a sip moh device of some sort on the market |
| 15:56.02 | Juggie | eg transfer to it and pull call back when done |
| 15:56.10 | Juggie | but in any case custom would be your best bet |
| 15:56.15 | Juggie | if you can generate g729 |
| 15:56.57 | Juggie | lets say you use asterisk to transcode ulaw -> g729 |
| 15:57.07 | Juggie | there is a cli command for that if i remember right. |
| 15:57.13 | Juggie | but i could be wrong :) |
| 15:57.31 | Juggie | if you then have g729 callers and g729 moh |
| 15:57.39 | Juggie | you dont even need a license |
| 15:58.00 | Juggie | its only when transcoding comes into play isnt it that the codec is required |
| 16:07.33 | seanbright | yes |
| 16:07.59 | seanbright | you aren't saying anything i don't know |
| 16:08.23 | seanbright | i just need something to convert my audio to g729 before it gets to asterisk |
| 16:08.39 | seanbright | so that is what i am in the process of figuring out |
| 16:09.56 | Juggie | ok, what i was asking is why not do regular moh with g729 as the source files |
| 16:10.00 | Juggie | or will * not do that |
| 16:10.07 | seanbright | because my audio is streaming |
| 16:10.12 | Juggie | ah k. |
| 16:10.15 | Juggie | it has to be streaming. |
| 16:10.21 | seanbright | correct |
| 16:10.26 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 16:10.45 | seanbright | we have ~50 files that have we converted to g729 (with asterisk) that provides MoH to our agents |
| 16:10.49 | seanbright | and that works fine |
| 16:11.00 | Juggie | right, its the live source. |
| 16:11.01 | seanbright | they are tired of listening to the same 50 songs over and over again |
| 16:11.15 | seanbright | so i introduced a shoutcast stream |
| 16:11.25 | seanbright | that eats up g729 licenses |
| 16:11.35 | seanbright | and we've come full circle |
| 16:11.46 | Juggie | well i dont know of anything that can do shoutcast -> g729 and output the way you want |
| 16:12.13 | seanbright | i will have to author something |
| 16:12.23 | Juggie | ya it seems that way |
| 16:13.00 | seanbright | since this is happening on a machine that has the transcoder cards in it, it makes the most sense to use /dev/dahdi/transcode directly |
| 16:13.24 | seanbright | i just need sruffell to add some code so that i can reserve channels so that codec_dahdi won't see them |
| 16:13.27 | seanbright | heh |
| 16:35.02 | sruffell | wakes up... |
| 16:35.44 | sruffell | for real? for in jest? |
| 16:35.53 | sruffell | s/for/or/ |
| 16:36.00 | sruffell | arghh |
| 16:36.04 | sruffell | 2013…no typose |
| 16:36.07 | sruffell | !!!! |
| 16:36.14 | Qwell | sruffell: You need a redbull. |
| 16:36.24 | sruffell | good idea..omw |
| 16:44.35 | seanbright | sruffell: what i would like to do it basically "reserve" an encoder/decoder pair that codec_dahdi wouldn't use, so that something external could use it instead |
| 16:44.48 | seanbright | i don't expect you to write it, but your guidance would certainly be appreciated |
| 16:45.48 | sruffell | hmm… /me thinks |
| 16:46.34 | file | what would the difference be between that and pre-allocating what you need before starting Asterisk? |
| 16:46.52 | *** join/#asterisk-dev marv (~Adium@173-14-206-193-huntsville.hfc.comcastbusiness.net) |
| 16:47.00 | seanbright | i don't know what you mean be pre-allocating |
| 16:47.04 | seanbright | by* |
| 16:47.14 | file | allocating the pairs in your custom application |
| 16:47.38 | seanbright | because would the driver then tell codec_dahdi that only 119 channels are available? |
| 16:47.56 | file | ah I understand now |
| 16:48.56 | Corydon76-home | You could write an Asterisk module that set up a pipe and pre-allocated the channels from codec_dahdi... then your application connects to that pipe to do the codec translation |
| 16:49.58 | seanbright | sruffell: does asterisk just ask the driver for an available encoder? or does it do it by passing a channel number in? |
| 16:50.34 | seanbright | if the former, than just using a encoder outside asterisk would work the same as running out of encoders in asterisk |
| 16:50.35 | sruffell | just asks for one…and dahdi_transcode is reponsible for finding one from any registered encoder that has the available formats. |
| 16:50.45 | seanbright | ahh |
| 16:51.06 | seanbright | so if an encoder is in use outside of asterisk, nothing in asterisk will be negatively affected |
| 16:51.12 | seanbright | other than having 1 less encoder |
| 16:51.13 | sruffell | but…you could in codec_dahdi just limit the total number of encoders/decoders you use..guaranteeing that there are always a few available for non-asterisk applications. |
| 16:51.47 | sruffell | except that now we get back to you other feature request…in that codec_dahdi tracks what's available. So I guess what's needed is to fix that /me looks up your issue... |
| 16:52.31 | seanbright | so here is my actual question... two scenarios |
| 16:52.55 | seanbright | 1) there are 120 encoders in use in asterisk, and another is requested |
| 16:53.11 | seanbright | 2) there are 119 encoders in use in asterisk, 1 by an external process, and another is requested |
| 16:53.32 | seanbright | is there any behavior difference within asterisk? |
| 16:53.46 | seanbright | if the answer is no, then nothing is required and i can just write my external process |
| 16:55.03 | sruffell | no…nothing different. Although, you can get into a strange state where codec_dahdi is failing to allocate a transcoder but thinks that more are available than are. |
| 16:55.16 | seanbright | right |
| 16:55.27 | sruffell | so, if you're fine with that..then….nothing to do. |
| 16:55.30 | seanbright | but either way you're dropping calls |
| 16:55.41 | sruffell | but I know you had asked for the tracking to be moved into the kernel as opposed to handled by codec_dahdi. |
| 16:55.56 | sruffell | (but I fail to find a DAHLIN issue for that..I thought I made one for you...) |
| 17:04.38 | sruffell | seanbright: codec_dahdi doesn't even use the count on allocation: https://github.com/sruffell/asterisk-working/blob/for-trunk/codecs/codec_dahdi.c#L419-L456 so you're right. |
| 17:06.17 | *** join/#asterisk-dev rgagnon (~rgagnon@71.42.183.54) |
| 17:06.20 | *** part/#asterisk-dev rgagnon (~rgagnon@71.42.183.54) |
| 17:31.12 | seanbright | sruffell: the count is used purely for reporting purposes |
| 17:31.23 | sruffell | nods |
| 17:31.28 | seanbright | well super duper |
| 18:13.57 | seanbright | sruffell: does the TC400 support slinear natively? |
| 18:14.10 | sruffell | negative unfortunately. |
| 18:14.14 | seanbright | k |
| 18:16.07 | sruffell | although DAHDI does in general, so there was a thought about pushing that slinear buffer down into the kernel. But probably not worth doing that until the interface is changed to return a list of frames. Then Silence detection and all that can be enabled in the firmware. |
| 18:16.10 | sruffell | but.... |
| 18:16.13 | sruffell | ….later. |
| 18:17.09 | seanbright | heh, right. |
| 18:40.22 | *** join/#asterisk-dev moy_ (~textual@CPE185933fe7837-CM185933fe7834.cpe.net.cable.rogers.com) |
| 18:45.44 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-81-244.user.veloxzone.com.br) |
| 19:03.14 | *** join/#asterisk-dev igcewieling (~igcewieli@user-24-214-153-32.knology.net) |
| 19:04.30 | igcewieling | Asterisk 1.8 tries to populate ${RDNIS} from the Diversion header on SIP channels. It seems to choke on Diversion headers with <tel:2125551212>, but is happy with <sip:2125551212>. Can anyone tell me if this is deliberate or if I should send in a bug report. |
| 19:05.18 | putnopvut | I'm pretty sure the code specifically expects SIP URIs. |
| 19:06.00 | igcewieling | putnopvut: I'll open a bug report then. |
| 19:06.12 | igcewieling | thaks. |
| 19:06.31 | igcewieling | or more correctly, I guess, a feature request |
| 19:07.53 | Juggie | the question is, is tel: valid. |
| 19:08.35 | igcewieling | Juggie: I've seen tel: RUIs before. Polycom phones, for example. |
| 19:08.44 | igcewieling | URIs, that is. I can't type today. |
| 19:22.38 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-qzaszhhqwldoizhe) |
| 20:13.51 | sruffell | reviewboard question. Is there a way to "close" a review without committing? I don't see where on the interface I can do that. Looks like all I can do is click "ship it" or comment. |
| 20:17.41 | russellb | should be able to if it's your own |
| 20:17.43 | russellb | or if you're an admin |
| 20:19.14 | file | you want to discard |
| 20:20.43 | *** join/#asterisk-dev msteed68 (~Michael_S@67.214.225.82) |
| 22:39.00 | snuff-work | wedhorn: ping ? |
| 22:58.20 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:58.20 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |