| 01:35.32 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 04:53.22 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 05:07.48 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 05:37.36 | *** part/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 05:45.54 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 06:14.06 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:987c:ec:4a79:21a5) |
| 06:30.45 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 06:57.46 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:03.16 | *** join/#asterisk-dev tonyclewis (sid6025@gateway/web/irccloud.com/x-qutliolrbmufbqfv) |
| 08:10.02 | *** join/#asterisk-dev wanna (~wanna@194.183.244.5) |
| 08:39.13 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:39.14 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:59.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 08:59.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 09:36.54 | skrusty | in agi, is there any way to get variables after the callee hangsup? I.e. dialstatus, without getting 511? :/ |
| 10:08.46 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f93c:5e49:9994:3524) |
| 10:10.19 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f93c:5e49:9994:3524) |
| 10:11.15 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f93c:5e49:9994:3524) |
| 10:11.42 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:f93c:5e49:9994:3524) |
| 11:03.47 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 11:03.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 11:50.23 | *** join/#asterisk-dev drmessano^ (~nonya@pdpc/supporter/active/drmessano) |
| 11:50.37 | *** join/#asterisk-dev coreyf1513 (~coreyfarr@2001:4830:117f:2:d180:c88b:aa42:d3b9) |
| 11:54.35 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:08.07 | *** join/#asterisk-dev opticron (~opticron@75.76.148.219) |
| 12:08.07 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 12:09.25 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-kloonrutiuuuqtry) |
| 12:13.01 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-hlwjogowncwecywu) |
| 12:28.14 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:30.03 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:4c18:dbf6:e81f:dfb6) |
| 12:40.35 | *** join/#asterisk-dev goddva (~goddva@2001:840:4259:a53:224:d6ff:fe52:9b18) |
| 12:52.35 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:68af:1788:3c56:3a13) |
| 13:01.35 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:68af:1788:3c56:3a13) |
| 13:36.14 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:36.14 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:18.09 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-xjqtgfhvujstefcs) |
| 14:19.13 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:20.46 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 14:20.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:21.13 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:21.14 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:21.29 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:23.35 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-jascfcvfgopgtkoq) |
| 14:33.30 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 14:38.06 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-gctbtqrcnjlnwijp) |
| 14:38.07 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:47.26 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:d2e1:40ff:fe90:12d0) |
| 15:02.04 | *** join/#asterisk-dev dms1 (~dms1@75.sub-70-199-227.myvzw.com) |
| 15:28.06 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-208-112.hsd1.al.comcast.net) |
| 15:53.32 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-hqsiigqmcozxhxzw) |
| 16:07.56 | gtjoseph | i'm confused... Where does all the XMl documentation, specifically configInfo, that's stuffed in modules go? I can't seem to find the generated results anywhere. |
| 16:10.09 | mjordan | gtjoseph: by generated results, you mean what happens after you run 'make'? |
| 16:10.41 | gtjoseph | yeah. If I want to view the results, where do I go? It's not in the doxygen stuff. |
| 16:10.51 | mjordan | two things happen |
| 16:11.17 | mjordan | (1) doc/core-en_US.xml is generated. That's the "basic" set of XML documentation |
| 16:11.42 | mjordan | (2) However, doc/core-en_US.xml won't contain everything, because there are run-time type inferences that are made when Asterisk starts and loads modules |
| 16:12.04 | mjordan | each of the various aco_register_type calls updates the parsed documentation with the type information that they possess, along with default values, ranges, and other funness |
| 16:12.13 | mjordan | hence, there is a CLI command that will dump out the XML documentation as well |
| 16:12.31 | mjordan | appropriately named, 'xmldoc dump' |
| 16:12.55 | gtjoseph | gotcha...i'll look |
| 16:13.38 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 16:13.38 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 16:21.59 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:28.32 | gtjoseph | mjordan: somewhere i recall seeing guidlines for xmldoc authoring but I can't put my finger on them. Know where they are? |
| 16:40.26 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:f8be:1218:3353:1ec3) |
| 16:44.00 | *** join/#asterisk-dev jrose_atDigium (~jrose@nat/digium/x-ytuymhyvbeqdysax) |
| 16:52.02 | *** join/#asterisk-dev dms1 (~dms1@2600:1004:b02b:e00b:f8be:1218:3353:1ec3) |
| 17:12.52 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ddxdcljuxgwldfec) |
| 17:47.47 | *** join/#asterisk-dev jmls (~jmls@77.107.171.82) |
| 17:51.24 | jmls | ok, so how do I go about building a customized asterisk (I know how to do that ;) ) on ubuntu and creating a package for distribution to machines without compilers etc? |
| 17:54.12 | gtjoseph | compile asterisk on your build machine then do a "make DESTDIR=/some/staging/dir" install" then use your packaging builder to make the package. |
| 18:18.21 | *** join/#asterisk-dev dms1 (~dms1@75.sub-70-199-227.myvzw.com) |
| 18:18.34 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 18:19.50 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@2001:4830:117f:2:6da0:bc6b:6733:faa7) |
| 18:22.20 | jrose_atDigium | mjordan + rmudgett + putnopvut: So I noticed that the call ID behavior during transfers has regressed since we adopted the new bridging model... |
| 18:22.39 | putnopvut | booooooooo |
| 18:22.49 | jrose_atDigium | prior to Asterisk 12, a transfer would result in the transferred party taking on the call ID of the channel it was transferred to |
| 18:23.01 | jrose_atDigium | *at least, for SIP blind and attended transfers* |
| 18:23.40 | jrose_atDigium | In Asterisk 12 and up, the transferred channel keeps its call ID and... so does the new channel, so they end up having different call IDs in spite of being in the same call together |
| 18:24.07 | rmudgett | Well they were in different calls until bridged. |
| 18:24.12 | jrose_atDigium | Yes |
| 18:24.33 | jrose_atDigium | But once they are in the same call, they need to have the same call ID |
| 18:24.34 | jrose_atDigium | now... |
| 18:24.41 | jrose_atDigium | in Asterisk 12, they are still in the original bridge |
| 18:24.46 | jrose_atDigium | and the bridge has a call ID |
| 18:25.23 | jrose_atDigium | so I've been thinking on that whole concept and right now my thought is that if a channel joins a bridge, its call ID should be changed (almost unconditionally) to the call ID of the bridge. |
| 18:25.51 | jrose_atDigium | Bridge call IDs on the other hand should be static. They just get the call ID of the first channel that joins the bridge and then nothing can change that. |
| 18:26.22 | jrose_atDigium | In that case, we wouldn't be following the Asterisk 11 behavior for transfers, it'd be a new behavior where the original call ID is the final call ID for both the transfer target and the transferee |
| 18:27.15 | jrose_atDigium | My thoughts on local channels are similar, but slightly more complex |
| 18:27.41 | jrose_atDigium | if a local channel has one end in a bridge and the other isn't in a bridge, the bridge call ID wins and is the final call ID on both sides. |
| 18:27.57 | rmudgett | jrose_atDigium: bridge -- local;1-local;2 -- bridge The ends of the local are in different bridges |
| 18:28.12 | jrose_atDigium | I'm getting to that |
| 18:28.30 | jrose_atDigium | I still haven't fully committed to a behavior for when both of the ends of a local channel are in separate bridges... |
| 18:28.35 | jrose_atDigium | I have a few possible angles though |
| 18:28.48 | jrose_atDigium | 1. ;1 wins |
| 18:29.01 | jrose_atDigium | 2. First channel to be bridged wins |
| 18:29.12 | jrose_atDigium | 3. Lowest call ID wins |
| 18:29.44 | jrose_atDigium | They all have their pros and cons. |
| 18:35.31 | jrose_atDigium | One of the problems with having a winner approach like that though is that while I can use something like stasis to propogate a change from one end of a local channel to another, I can't prevent a change unless I either have a way to know that a channel is an unreal channel from the context of ast_channel_callid_set or else I'd need to be able to allow the channel technology to override the behavior (again, using a channel tech |
| 18:35.31 | jrose_atDigium | callback). It's not as simple as linked ID propagation. |
| 18:36.05 | jrose_atDigium | I could validate the rules after a change and then change it back, but that strikes me as suboptimal. |
| 18:51.54 | mjordan | Don't use Stasis. |
| 18:51.58 | mjordan | let's just nix that idea right now. |
| 18:52.14 | mjordan | The amount of processing you'd incur from passing Call-IDs around via Stasis messages is definitely not worth it |
| 18:53.05 | mjordan | If we view things as "this is a call and it propagates", then I think you (a) have to have a way to share a Call-ID across a Local channel, and (b) you have to not always treat Call-IDs in a bridge as static |
| 18:53.35 | mjordan | Your idea is good for most normal channels, but once you put a Local channel between two bridges, you now have to propagate the Call-ID |
| 18:53.53 | mjordan | Again, however, for now - don't worry about how you're going to get it done. |
| 18:53.59 | mjordan | Define the behavior. Forget the code. |
| 18:54.17 | mjordan | Trying to think about how you're going to do something is a mistake at this point: your implementation should not be dictating the requirements. |
| 18:54.27 | mjordan | We can negotiate our way out of things at a latter date :-) |
| 19:06.45 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.154.251) |
| 19:09.14 | *** join/#asterisk-dev terryw (~otherwise@69.76.152.163) |
| 19:21.55 | jrose_atDigium | mjordan: "(b) you have to not always treat Call-IDs in a bridge as static" -- can you elaborate on this? Are you saying the call ID on a bridge should be able to change? If so, what would the parameters for that be? I mean, right now I guess it follows that calls into a holding bridge should not all receive the same call ID and historically calling into confbridge still keeps the original call ID that was used before joining t |
| 19:21.56 | jrose_atDigium | he conference call... so all participants there have their own call ID. All these exceptions make the behavior really hard to define though :/ |
| 19:22.45 | jrose_atDigium | I suppose that if a bridge is empty, it probably shouldn't have a call ID. |
| 19:23.26 | jrose_atDigium | Or maybe just if someone joins an empty bridge, the bridge's call ID should change to that of the only active participant. |
| 19:23.47 | jrose_atDigium | Holding bridges probably shouldn't have any impact on call IDs of channels that enter them |
| 19:23.53 | jrose_atDigium | Conference bridges on the other hand... |
| 19:23.59 | jrose_atDigium | I'm not sure. |
| 19:26.15 | mjordan | jrose_atDigium: Again, define what a call is. |
| 19:26.41 | mjordan | If I have SIP/A <- B0 -> L;1 <-> L;2 <-> B1 <-> SIP/B, and the Local channel doesn't optimize, what is the Call ID? |
| 19:26.55 | mjordan | In the best possible scenario, you have two |
| 19:27.00 | mjordan | Ideally, you'd have one |
| 19:27.19 | mjordan | Otherwise, you don't really have a 'call identifier', you have a 'bridge identifier', which is useful but not as useful as propagating things for a call |
| 19:27.42 | mjordan | jrose_atDigium: take off your developer hat and put on your "I'm using Asterisk" hat. :-) |
| 19:28.03 | jrose_atDigium | Does anyone really know what a call is? |
| 19:28.49 | jrose_atDigium | I'm working on it :/ |
| 19:37.06 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 19:37.06 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 19:42.06 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 19:42.06 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 19:45.10 | file | I wonder why I'm bouncing |
| 19:45.24 | file | only on Freenode |
| 19:45.36 | Qwell | ping timeouts |
| 19:45.37 | Qwell | shrugs |
| 20:04.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.47) |
| 20:31.31 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:31.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:55.05 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-ukawpjlrjybzvrhu) |
| 20:59.55 | leifmadsen | file: it's because Bell Aliant got bought out |
| 21:02.52 | file | pfft |
| 22:07.17 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:56.25 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jascfcvfgopgtkoq) |