| 00:17.23 | *** join/#asterisk-dev sgriepentrog (~sgriepent@2602:306:bdc4:84e0:ae72:89ff:fe28:f9ba) |
| 01:53.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:27.38 | *** join/#asterisk-dev infobot (~infobot@rikers.org) |
| 02:27.38 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 07:40.47 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 07:40.47 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 07:53.32 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 10:11.53 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 10:11.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:26.30 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:26.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:01.58 | *** join/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 12:09.00 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:15.44 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:26.16 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 12:30.01 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 12:30.01 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:31.53 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:31.53 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 12:42.13 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 12:43.28 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 12:49.42 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 12:57.38 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:31.06 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:31.06 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:34.59 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-prqwpwilcuwvfygw) |
| 13:52.48 | skrusty | anyone about? got a user of asternet that's raised an interesting question to do with FastAGI and Encoding. AsterNET sends everythig as ASCII by default, but he's wanting to pass an option via Exec that's in Russian (using googletts.agi). This seems to cause a problem however in that Asterisk just seems '?'s Any suggestions? |
| 13:53.18 | skrusty | when he changes the encoding to UTF8, asterisk rejects the commands (Answer etc) |
| 13:55.29 | WIMPy | (Something like) "Answer" in UTF-8 is the same as in ASCII. That's the point of UTF-8. |
| 13:56.21 | skrusty | http://i.snag.gy/4XVUS.jpg |
| 13:57.44 | WIMPy | I'd check what's really being sent. |
| 13:57.59 | skrusty | i'll ask him to wireshark it |
| 13:59.04 | WIMPy | EBCDIC and UTF-16/32 are the only encodings that I know of where anything ASCII would not stay the same. |
| 13:59.27 | skrusty | yeah, 8 is backwards compat with ascii :/ |
| 13:59.40 | skrusty | thanks anyway WIMPy - thought i would throw that one out there :) |
| 14:00.13 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jgzbgzxbmkniqpyj) |
| 14:00.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.06 | file | falls over |
| 14:02.02 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-wrikefyepbacmgde) |
| 14:02.02 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:14.00 | skrusty | picks up file |
| 14:21.30 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-rynnreifqvpokhtz) |
| 14:29.56 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 14:29.57 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 14:30.37 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:30.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:31.45 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:44.35 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 14:59.19 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-wchjestchhvgsolg) |
| 15:18.39 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-lthxqmjuxlgmiyol) |
| 15:38.11 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-braacxsaqggcxver) |
| 15:41.16 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 16:01.52 | mjordan | file: I think I'm going to need your format attribute work in order to fix the unit tests |
| 16:02.07 | mjordan | do you want me to take over that review? |
| 16:03.44 | file | sure |
| 16:15.23 | mjordan | k. |
| 16:27.34 | mjordan | compiles |
| 16:32.03 | otherwiseguy | mjordan: well, did it compile? don't leave us hanging. :p |
| 16:34.10 | mjordan | it did! After I disabled stuff :-P |
| 16:34.18 | mjordan | also: create_addr initializes RTP. |
| 16:34.27 | mjordan | because that name *clearly* implies that action. |
| 16:34.35 | mjordan | is pretty sure he had something to do with that at some point in time |
| 16:34.48 | otherwiseguy | badly named functions in Asterisk code? never! |
| 16:35.27 | file | glares at otherwiseguy |
| 16:35.30 | file | who said you could speak? |
| 16:35.43 | mjordan | meh, he's past the statute of limitations |
| 16:35.49 | otherwiseguy | redirects files glare to putnopvut |
| 16:36.15 | otherwiseguy | now wants to design a Statue of Limitations |
| 16:39.22 | mjordan | http://fc05.deviantart.net/fs70/i/2012/030/1/f/statue_of_limitations_by_frostglade-d4o6d5j.jpg |
| 16:40.43 | mjordan | go go internet |
| 16:40.59 | file | they have the internet on computers these days, I hear |
| 16:43.58 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 16:45.25 | mjordan | any key? Where's the any key? |
| 16:46.46 | tzafrir | git-svn fails for asterisk: sgalarneau not defined in AUTHORS file |
| 16:47.05 | tzafrir | who's sgalarneau? |
| 16:47.14 | rmudgett | mjordan: All the keys on your keyboard are any keys. None of them are labeled so they could be any key. |
| 16:48.03 | Qwell | rmudgett: I pressed shift and the error didn't go away! |
| 16:48.42 | mjordan | tzafrir: Sam! I'll add him. Sorry about that. |
| 17:08.50 | mjordan | file: I'm going to go out on a limb and guess that having the same format reproduced in a compatibility structure isn't going to end well |
| 17:09.01 | mjordan | [Jul 7 12:05:11] VERBOSE[13279][C-00000000] chan_sip.c: Capabilities: us - (ulaw|alaw|gsm|h263|ulaw|h263|h264|speex), peer - audio=(ulaw)/video=(h263)/text=(nothing), combined - (ulaw|h263|ulaw|h263) |
| 17:10.58 | file | actually, it will work |
| 17:11.29 | file | (if you are referring to media formats format caps) |
| 17:11.43 | mjordan | well, yes |
| 17:11.48 | mjordan | I am referring to that |
| 17:11.55 | mjordan | except what are we supposed to do with two ulaw/two h263? |
| 17:12.05 | mjordan | what actually gets produced, for example, on a generated SDP? |
| 17:12.08 | file | two ulaw is silly, two h263 is possible because the underlying attributes may differ |
| 17:12.19 | mjordan | which one has preference? |
| 17:12.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 17:12.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:13.14 | file | right now that's not really expressed in a manner that can be controlled - configuration assumes one h263, but I purposely made format caps not limit it for the future |
| 17:13.49 | file | (when it comes to video it is valid, and it does happen in the wild - that's why) |
| 17:14.06 | mjordan | hm. |
| 17:14.13 | mjordan | We're going to have to have some mechanism for that however. |
| 17:15.21 | file | for what? |
| 17:15.40 | file | configuration? |
| 17:18.53 | mjordan | no, attribute pass through |
| 17:19.19 | mjordan | if I have h263 with some set of attributes, and I need it passed through, then I need the version of it from my capabilities structure to be used, not the one for the outgoing INVITE's peer |
| 17:19.48 | file | correct |
| 17:20.01 | file | previously that would "just happen" |
| 17:20.08 | file | dark magic in outbound dialing |
| 17:24.30 | gtjoseph | thinks a cli command to truncate the refs file would be handy. |
| 17:24.44 | mjordan | which means our theoretical case is trumping the actual :-P |
| 17:25.24 | file | I don't understand what you mean |
| 17:27.45 | mjordan | I mean that right now, it is non-trivial to compute a joint capabilities structure with only the version with attributes |
| 17:28.00 | mjordan | or at least, I'm banging away through it trying to find out why I have two ulaw/h263 in my joint capabilities |
| 17:28.24 | mjordan | having duplicates is theoretically nice, but we have nothing that can make sense of it |
| 17:28.47 | file | internally no but if you call from one video device to another you get a better chance of having better quality video streams |
| 17:28.49 | coreyfarrell | gtjoseph: many objects are created at startup/shutdown, you'd have hundreds of leaked or skewed objects |
| 17:28.59 | file | if we can't achieve that, then ok |
| 17:29.52 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 17:29.52 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Asterisk 12 now released. Do the release dance! -=- Follow on Twitter at @AsteriskDev |
| 17:34.39 | mjordan | file: Actually, I think what is happening here is that the media formats negotiated by the INVITE request (inbound) is not replacing the ones on the SIP pvt structure. They just get appended to it, which is why there's duplicates |
| 17:34.55 | mjordan | this works "okay" when there's no attributes, since voila, having two ulaw doesn't matter |
| 17:35.01 | file | ah yeah |
| 17:35.10 | mjordan | but really, when we get an inbound INVITE request with media formats that we support, we should be replacing, not appending |
| 17:35.41 | file | out with the old and in with the new |
| 17:40.50 | coreyfarrell | gtjoseph: I can see what you mean, rotate the refs log after startup, then again after running a test. I see that as limited usefulness, it just makes it easier to ignore startup/shutdown leaks. also the media_indexer continues running in the background for a bit after startup, so this would likely give you inaccurate information. |
| 17:41.42 | gtjoseph | yeah... |
| 17:42.11 | gtjoseph | makes it hard to test specific functionality though. |
| 17:43.29 | mjordan | shakes his fist at the media indexer |
| 17:44.23 | file | mjordan, BURN IT |
| 17:44.54 | coreyfarrell | gtjoseph: I haven't done much testing with PJSIP yet since some of the modules cannot be unloaded - this makes it difficult to test for leaks. If you test without any modules that can't unload, the refs log only has a few entries for a couple things in stasis (plus whatever test you did). |
| 17:45.26 | gtjoseph | coreyfarrell: ah, good point. |
| 17:45.53 | coreyfarrell | gtjoseph: I briefly looked at providing the ability for res_pjsip to either unload or use ast_register_cleanup, but I couldn't find a safe way to do so. |
| 17:48.09 | mjordan | Hm. I think if a format is appended to a cap structure, and that format has an equal format structure already in the cap structure (equal being same framing, same attributes, etc.) - then we should NoOp it |
| 17:48.59 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-bqqceolfedpswgte) |
| 17:49.30 | file | mjordan, agreed |
| 17:59.57 | mjordan | file: heh, figured it out. We append to a dialog's capabilities from the global sip_cfg, then we append later from the peer's. We don't blow away the global however when we find a peer |
| 18:00.08 | file | yay. |
| 18:05.40 | mjordan | heh: chan_sip.c: Done building SDP. Settling with this capability: (h263|ulaw|ulaw|alaw|gsm|h263|ulaw|h263) |
| 18:14.46 | file | MOAR |
| 18:16.07 | mjordan | ALL THE ULAW |
| 18:17.15 | file | OBEY THE LAW, ULAW! |
| 18:19.35 | mjordan | wow. |
| 18:19.40 | mjordan | this is really, really broken :-( |
| 18:24.02 | mjordan | (chan_sip, that is) |
| 18:24.07 | mjordan | it's rather append-happy. |
| 18:27.44 | *** join/#asterisk-dev SGjunior (~sgjunior@96.127.222.20) |
| 18:28.24 | mjordan | progress! down to only four [Jul 7 13:27:14] DEBUG[11528][C-00000000] chan_sip.c: Done building SDP. Settling with this capability: (h263|ulaw|ulaw|h263) |
| 18:28.39 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 18:28.39 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:32.28 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-jpmuyrvdnqstvaxe) |
| 18:32.49 | Qwell | mjordan: you lost gsm! |
| 18:36.57 | mjordan | and no one cares! |
| 18:45.35 | mjordan | Hm. |
| 18:45.39 | mjordan | I'm not sure what the purpose of ast_rtp_instance_available_formats really is |
| 18:45.55 | mjordan | and only chan_sip seems to use it... |
| 18:46.01 | mjordan | and it is blowing away my darn joint capabilities |
| 19:01.39 | mjordan | Heh, this is a good one too: |
| 19:01.39 | mjordan | [Jul 7 13:57:50] DEBUG[27522][C-00000000] chan_sip.c: *** Our native formats are (h263(0x1fef908)|h263(0x1fef908)) |
| 19:01.48 | mjordan | hey dawg, I heard you like H263 |
| 19:10.15 | mjordan | btw, that double video choice happened because we assume that the codec in slot 0 is always audio |
| 19:10.24 | mjordan | apparently, there are ways in which that isn't the case |
| 19:10.32 | mjordan | so I'm going to add a ast_format_cap_get_best_by_type to format_cap.h |
| 19:20.38 | mjordan | note to self: format attributes are generated better when the module are compiled |
| 19:27.33 | mjordan | file: so here's an interesting question - the h263_cmp callback isn't implemented (whoops). What would we require for two H.263 format attribute structures to be considered equivalent? |
| 19:28.18 | file | uhhhhh |
| 19:29.13 | file | that is a question. |
| 19:30.08 | mjordan | looking at H.263... that's not easy to figure out. |
| 19:31.11 | mjordan | and by 'comparison for equality', are we trying to say that the two formats are strictly equal? Or merely that they could talk to each other? |
| 19:31.33 | mjordan | interesting, the other format attribute modules consider something without formats to be 'okay' |
| 19:31.44 | mjordan | (which makes some sense, if you didn't tell me what you wanted, you get nothing) |
| 19:31.49 | mjordan | or everything. |
| 19:31.52 | file | equal is strictly equal, subset is can talk to eachother |
| 19:33.47 | mjordan | hm |
| 19:35.07 | mjordan | that doesn't seem quite like how it is used in practice |
| 19:35.24 | mjordan | for example, in CELT, I could have an attribute with no sample rate and one with a sample rate, and we'd return equal |
| 19:35.39 | mjordan | er |
| 19:35.41 | mjordan | not quite! |
| 19:35.49 | mjordan | rather, one with a sample rate and one without any attributes |
| 19:36.51 | TazzNZ | Hey everyone |
| 19:38.24 | mjordan | file: memcmp ftw |
| 19:38.37 | file | nicely done |
| 19:38.44 | mjordan | that's a lot of attributes |
| 19:41.14 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-novqxnmisxjnprjz) |
| 19:55.14 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-uatjgfcuvrlnwbhg) |
| 19:57.03 | mjordan | \o/ got an outbound invite with attributes |
| 20:25.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.152.163) |
| 20:25.25 | mjordan | am I on crazy pills, or did we negotiate speex attributes in some hard coded fashion previously? |
| 20:27.34 | file | you aren't on crazy pills, I believe we locked it to some specific version |
| 20:29.47 | mjordan | I think I'm going to have to write one |
| 20:30.02 | mjordan | we actually have tests for the bloody things. Somehow they're getting generated currently - not quite sure how |
| 20:32.40 | mjordan | I seriously can't see how it ever passed however |
| 20:48.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:48.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:31.11 | mjordan | goes looking for a missing codex_speex |
| 21:31.34 | mjordan | huh |
| 21:33.12 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:38.31 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 21:38.40 | *** join/#asterisk-dev terryw (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 21:44.54 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 22:19.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:37.00 | *** join/#asterisk-dev oron (~oron@line25-214.adsl.actcom.co.il) |
| 22:37.29 | *** part/#asterisk-dev oron (~oron@line25-214.adsl.actcom.co.il) |
| 22:46.07 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-prqwpwilcuwvfygw) |
| 23:34.22 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 23:34.22 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
