| 00:21.26 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 02:12.47 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 06:49.17 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:04.15 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:04.15 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:59.56 | coreyfarrell | wdoekes: thanks for the tip on flake8 and thanks for all the reviews you've done lately |
| 08:06.10 | snuff-work | still must get around to looking into if confbridge actually writes out 16khz recordings.. last time i swear it downmixed to 8khz |
| 08:13.17 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 08:15.22 | wdoekes | coreyfarrell: np. thanks yourself for all the fixes. b.t.w. beware that the vim F7 key will save/overwrite the current file |
| 08:16.33 | coreyfarrell | honestly I don't use vim that often. I've found myself using geany a lot lately.. unless you tell me there is a way to enable code block folding in vim :) |
| 08:16.56 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:18.00 | skrusty | morning all |
| 08:18.08 | coreyfarrell | but flake8 works great on command-line, I'll just use it before posting any python code (since PEP is ridiculous) |
| 08:24.13 | TazzNZ | hey skrusty |
| 08:28.18 | jameswf | I ♡ geany |
| 08:31.46 | wdoekes | coreyfarrell: folding? sure there is. I never use it though, so I don't know if it works conveniently |
| 08:33.53 | coreyfarrell | yeah I'll stick with my light-weight GUI editor :) |
| 08:41.49 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 08:46.37 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-sreiwhglwhiougfe) |
| 09:45.18 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 10:50.14 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 11:05.30 | file | la la la |
| 11:06.50 | skrusty | that was nice! |
| 11:53.07 | *** join/#asterisk-dev newtonr (~newtonr@173-17-135-67.client.mchsi.com) |
| 11:53.07 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 12:09.49 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:17.59 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:52.35 | *** join/#asterisk-dev benasse (~benasse@cicogna.fr) |
| 12:56.44 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-82-76.user.veloxzone.com.br) |
| 13:17.38 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:20.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:34.45 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:34.45 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:39.00 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-zqofnmkiidpivqdw) |
| 13:52.50 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvqgfyvaqxdlitk) |
| 13:59.51 | file | coreyfarrell, what's the dealio on r3603? |
| 14:19.14 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:25.49 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-nbwtbpbhkvjatptu) |
| 14:25.49 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:28.36 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:28.37 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:39.10 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-uiospdcbdedxvmst) |
| 14:47.57 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-sybruhkeccebmhtt) |
| 14:47.57 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:08.05 | pabelanger | tm1000, I see |
| 15:08.31 | pabelanger | we've don't ubuntu 10.04 and 12.04 in production for as long as both live. Never had any issues with the OS |
| 15:15.03 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-xoajvukdqadimrok) |
| 15:19.02 | opticron | advocates for a review on https://reviewboard.asterisk.org/r/3560/ since it's code review thursday |
| 15:39.44 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 15:45.44 | pabelanger | pjproject doesn't support webrtc I take it? |
| 15:46.25 | file | if you clarify what "support webrtc" means then that can be answered |
| 15:46.53 | pabelanger | call control for webrtc? |
| 15:47.00 | opticron | not directly, but chan_pjsip does via res_pjsip_transport_websocket |
| 15:47.07 | Qwell | shudders |
| 15:47.13 | pabelanger | okay, so nothing in the core of pjproject. |
| 15:47.26 | pabelanger | If asterisk was to add webrtc, we'd have to write more code for it? |
| 15:47.28 | file | Qwell, I rewrote it |
| 15:47.34 | Qwell | file: good |
| 15:47.52 | pabelanger | I only ask because I see file code review only touches chan_sip.c |
| 15:48.00 | file | it's against 11 |
| 15:48.22 | pabelanger | Oh |
| 15:48.29 | file | the impact on the PJSIP functionality in 12 is minor to support the changes I have in the code review |
| 15:48.35 | pabelanger | odd, the branch field is not populated |
| 15:49.05 | file | I didn't populate it, I was coordinating it against 3 things :P |
| 15:49.12 | file | even then it's in a branch branched off 11 |
| 15:49.17 | pabelanger | okay, I guess what I'm trying to figure out, is are we going to support both chan_sip and chan_pjsip for webrtc. Or are we limiting it to one |
| 15:49.26 | pabelanger | Looks like both for now? |
| 15:49.40 | file | both. |
| 15:49.47 | file | what you are REALLY asking is: |
| 15:50.00 | file | "are we going to support SIP over Websockets for both chan_sip and chan_pjsip?" |
| 15:50.15 | pabelanger | what I am really asking is, which one should I use |
| 15:50.21 | pabelanger | chan_sip or chan_pjsip |
| 15:51.47 | file | that's not something I'll answer because it depends on what you are trying to achieve, what you've tested, and which you are comfortable deploying |
| 15:52.23 | pabelanger | are they both considered core support? |
| 15:52.41 | file | they both have core support level. |
| 15:52.42 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-zfjcjbjlshuqbeip) |
| 16:02.08 | file | BANANAS FOR ALL |
| 16:04.54 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:21.18 | mjordan | ...and just to chime in here... |
| 16:21.25 | mjordan | "are we going to support both chan_sip and chan_pjsip for webrtc. Or are we limiting it to one" |
| 16:21.51 | mjordan | Keep in mind that 'core' support is a Digium thing. It just means what Digium is going to throw its developers behind. The community can, and does, support lots of other things. |
| 16:22.07 | mjordan | If something is in extended support and it works for you, then by all means, please use it |
| 16:22.58 | mjordan | (And, in a strange fit of irony, while chan_sip and chan_pjsip are both core support, res_http_websocket is not. It is extended. But that's really a fluke.) |
| 16:37.59 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 16:47.54 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-uonlkjlxtgaeiyeo) |
| 16:47.54 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:48.35 | file | mjordan, welcome back! I missed you! |
| 16:59.51 | mjordan | file: and now I leave again. Shortly. |
| 17:00.25 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-edmwiqkyblzwnteq) |
| 17:00.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:00.36 | mjordan | and now I have returned |
| 17:00.38 | mjordan | VPN! |
| 17:00.56 | file | mjordan, and here I thought you simply hated me |
| 17:16.20 | file | chan_pjsip and I aren't on the same wavelength today |
| 17:25.00 | mjordan | file: that's ... odd |
| 17:25.51 | file | every day is pon, every time is pon |
| 17:40.27 | mjordan | doobie doobie doooo |
| 17:40.32 | mjordan | doin' reviews |
| 17:43.04 | file | mjordan, do you have suitable review music? |
| 17:43.06 | *** join/#asterisk-dev danjenkins_ (~dan@nat/digium/x-fwmnrmbaclrgfvyb) |
| 17:43.44 | mjordan | no |
| 17:44.07 | mjordan | I have people arguing about whether or not the U.S. will ever score a goal, or if we're going to continue to fold like a bunch of cheese eating surrender monkeys |
| 17:44.17 | mjordan | my vote is surrender monkeys |
| 17:44.29 | file | mmm monkeys |
| 17:46.23 | *** join/#asterisk-dev danjenkins__ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 18:04.25 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-omqutxqjczwmqexz) |
| 18:04.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 18:17.40 | seanbright | mjordan: hi |
| 18:18.15 | seanbright | re: r417310 |
| 18:18.32 | seanbright | you forgot to add ast_websocket_set_timeout to res/res_http_websocket.exports.in |
| 18:19.50 | mjordan | er |
| 18:19.52 | mjordan | crap. |
| 18:20.00 | seanbright | agreed |
| 18:46.42 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-xoajvukdqadimrok) |
| 18:46.42 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-sybruhkeccebmhtt) |
| 18:46.42 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-uiospdcbdedxvmst) |
| 18:46.42 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvqgfyvaqxdlitk) |
| 18:46.42 | *** join/#asterisk-dev benasse (~benasse@cicogna.fr) |
| 18:46.43 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 18:46.43 | *** join/#asterisk-dev GameGamer43 (sid5533@gateway/web/irccloud.com/x-upvtuwhwkkwerjge) |
| 18:46.43 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-cjprbuhpqksjdypo) |
| 18:46.43 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 18:46.43 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 18:46.43 | *** join/#asterisk-dev TazzNZ (~pieter@office-nat1.ytechops.co.nz) |
| 18:46.43 | *** join/#asterisk-dev coreyfarrell (~cfarrell@2001:4830:117f:2:809f:5ee3:4f4d:85d9) |
| 18:46.43 | *** join/#asterisk-dev mvanbaak (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 18:46.43 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 18:46.43 | *** mode/#asterisk-dev [+oooo newtonr Qwell mvanbaak Corydon76-home] by wilhelm.freenode.net |
| 18:46.43 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:e1c1:4917:44c0:2f0e) |
| 18:46.43 | *** join/#asterisk-dev heise2k (~rheise@static-96-245-76-214.phlapa.fios.verizon.net) |
| 18:46.43 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 18:46.43 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 18:46.43 | *** mode/#asterisk-dev [+oo russellb seanbright] by wilhelm.freenode.net |
| 18:49.00 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 18:51.43 | *** join/#asterisk-dev mvanbaak_ (~michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 18:51.43 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 18:59.21 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 18:59.21 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 19:00.20 | coreyfarrell | file: on r3603 I don't know what to do about scenario 1. honestly haven't been motivated to look at scenario 3 again, partly since scenario 1 is my use case and you want me to fix the bug by stopping JB on masquerade |
| 19:01.47 | coreyfarrell | file: also the media_format stuff and some refcounting bugs have taken the front burner |
| 19:02.09 | file | nods |
| 19:03.56 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:03.56 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:11.19 | coreyfarrell | file / mjordan: all my media_formats code is now committed. I have to run for about an hour, maybe after we can talk about what's next |
| 19:12.00 | file | I'll be around then, mjordan is gone right now but he'll probably be back then too |
| 19:12.55 | coreyfarrell | cool.. also once my latest astobj2.c patch is committed I think I'd like to merge the current trunk into media_formats-reviewed-trunk |
| 19:13.05 | coreyfarrell | but anyways I'll be back |
| 19:13.15 | *** join/#asterisk-dev heise2k (~rheise@static-96-245-76-214.phlapa.fios.verizon.net) |
| 19:14.59 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-ubrjusrjasizdbhw) |
| 19:19.10 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-xoajvukdqadimrok) |
| 19:19.10 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-sybruhkeccebmhtt) |
| 19:19.10 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-uiospdcbdedxvmst) |
| 19:19.10 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvqgfyvaqxdlitk) |
| 19:19.10 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 19:19.10 | *** mode/#asterisk-dev [+o newtonr] by wilhelm.freenode.net |
| 19:23.01 | mjordan | file: so, what I'm working through right now is an issue for format attributes |
| 19:23.10 | mjordan | I am, however, a bit confused on how this is supposed to work |
| 19:23.16 | mjordan | formats are immutable |
| 19:23.41 | mjordan | However, attributes are negotiated on a per channel basis, and hence need to be stored in ... something. Currently, that storage is not really well defined |
| 19:23.55 | mjordan | there is a void * on a format that points to its attributes, but since a format is immutable, I'm not sure how that should be set up |
| 19:24.22 | mjordan | yes, the format interface is what should actually do this 'setting', but I'm not sure how we guarantee that a format on a channel doesn't end up with multiple sets of formats |
| 19:24.26 | mjordan | er, sets of attributes |
| 19:31.19 | gtjoseph | rmudgett: are you aware of any pre-existing multi threded container issues? |
| 19:34.56 | mjordan | gtjoseph: on ao2_containers? |
| 19:35.04 | gtjoseph | yep |
| 19:35.23 | mjordan | Hm. I'm not. |
| 19:35.28 | mjordan | Are you seeing a corruption of the nodes? |
| 19:35.37 | mjordan | or of the object count? |
| 19:35.38 | gtjoseph | i wrote a multi-threaded torture test for weak ref but neither hash nor rbtree will pass. |
| 19:36.10 | gtjoseph | i'm seeing a heap corruption. I.E SEGV on malloc |
| 19:36.12 | mjordan | interesting. |
| 19:36.28 | mjordan | what all does the test do? |
| 19:37.15 | gtjoseph | stripped down... it created a container, adds 100 objects, then spawns 2 threads each doing 50000 finds on random objects. |
| 19:37.15 | mjordan | and the one thing I would say is that there are heap containers (in particular) that get hit a lot in a multi-threaded fashion |
| 19:37.49 | gtjoseph | the tests pass but on every few runs i get VERY weird craches. |
| 19:38.01 | mjordan | have you run with MALLOC_DEBUG enabled? |
| 19:38.13 | gtjoseph | that's next |
| 19:46.18 | tm1000 | mjordan: file getting this error when sending sms to pjsip: “Error processing 657 bytes packet from UDP 192.159.66.3:5080 : PJSIP syntax error exception when parsing '' header on line 4 col 8” |
| 19:47.12 | tm1000 | http://pastebin.com/ab0qan7u |
| 19:48.04 | mjordan | huh |
| 19:48.47 | tm1000 | mjordan: I am sending a text message to my server from freeswitch and thats what PJSIP is telling me, also PJSIP doesnt send an OK back |
| 19:49.50 | mjordan | ah |
| 19:50.12 | mjordan | I need to double check |
| 19:50.20 | mjordan | but I'm pretty sure your custom header can't occur after the Content-Length |
| 19:50.59 | mjordan | yup |
| 19:51.04 | mjordan | Section 7.5 of RFC 3261 |
| 19:51.33 | mjordan | The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. |
| 19:52.05 | mjordan | The error message coming out of the PJSIP stack is probably occurring because it saw that you had another header, kept going, and eventually hit the blank line after the custom FreeSwitch header |
| 19:52.12 | mjordan | it then barfed, as that is an 'empty' header. |
| 19:52.14 | mjordan | (Guessing a bit there) |
| 19:52.40 | mjordan | If you can make FreeSwitch do it (and no idea here, because I don't know), add the header before the Content-Length |
| 19:52.46 | mjordan | and see what happens |
| 19:52.47 | TazzNZ | mjordan: I would read that as the end of the Data, not the header ? |
| 19:53.09 | mjordan | TazzNZ: The Content-Length frames the SIP request. |
| 19:53.11 | TazzNZ | ...each SIP message in a stream.... |
| 19:53.29 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 19:53.47 | *** join/#asterisk-dev philippel (uid10480@gateway/web/irccloud.com/x-sfawlirpufwqvgwf) |
| 19:53.58 | TazzNZ | isn't that normally done with the "double \n" |
| 19:54.15 | TazzNZ | so after the headers are done, you have an empty line starting the content |
| 19:55.13 | tm1000 | mjordan: in chan_sip it does not break though :-) |
| 19:55.18 | tm1000 | but we agree with you overall |
| 19:55.20 | mjordan | tm1000: don't care |
| 19:55.21 | mjordan | :-P |
| 19:57.21 | TazzNZ | I don't agree - not to be funny or anything, but I think the RFC would have stated that the header ends with "Content-Length" if that was the case |
| 19:57.22 | mjordan | TazzNZ: in Section 7, it does not explicitly state that a CRLF frames the end of the message. It does state that in both Section 7.5 and continues in 18.3 on how messages are framed. In both sections, it references Content-Length, not a double crlf |
| 19:58.06 | mjordan | Specifically with framing, the content-length describes how much further the message continues (as a number of bytes). |
| 19:58.27 | mjordan | shrugs. |
| 19:58.47 | mjordan | I'm guessing that this is what occurred in the PJSIP stack. I'd be interested to see what happens if the header is moved. I may be wrong about what is occurring. |
| 19:58.51 | TazzNZ | ok - so in tm1000 case, it would have been "\nOkkk" and not "Okkkk" ? |
| 19:59.30 | philippel | mjordan: question, if the Content-Type: header came after the Content-Length: header, would the same problem be created? |
| 19:59.37 | mjordan | no, that doesn't frame the SIP message. That is part of the body of the SIP request, but the actual SIP message itself is framed by the presence of the Content-Length header. |
| 19:59.54 | mjordan | philippel: I'm not sure. |
| 20:00.21 | philippel | it seems from what you are saying it would because you are depending on the Content-Length to frame the message? |
| 20:02.25 | mjordan | philippel: Based on my reading, and what it looks like PJSIP did, it would frame the header portion of the SIP message with Content-Length. I'm looking at PJSIP right now to see what it actually does. |
| 20:02.59 | TazzNZ | yeah - I always treated the "double\n\n" or a single empty "line" as the "We are done processing the header/message, now for the body" |
| 20:03.23 | TazzNZ | but I am happy to be corrected :D |
| 20:03.26 | mjordan | tm1000: is there a space in the message on line 16? |
| 20:04.02 | TazzNZ | (or perhaps a \r\n and it should be only \n ?) |
| 20:04.23 | mjordan | PJSIP doesn't care about that. It will treat either \r or \n as a new line indication. |
| 20:05.35 | mjordan | so, I stand corrected - at least with PJSIP's behavior. It doesn't care where Content-Length occurs. |
| 20:06.11 | mjordan | As for RFC semantics, no idea. The RFC seems to imply that Content-Length header should be used for framing, but it may also be implying that the byte count in there creates the framing (which is sort of obvious if you have the body). |
| 20:06.55 | mjordan | tm1000: philippel: so, new theory: if there's a space on the line that should contain only a \r\n, it may continue to process the next line in the request as a header. |
| 20:07.10 | mjordan | Looking at the PB, there may be a space there, but I can't tell |
| 20:07.18 | tm1000 | I cant tell if there is a space from asterisk |
| 20:07.27 | mjordan | wireshark would probably should it for sure |
| 20:07.40 | tm1000 | there’s no space there (from asterisk) |
| 20:07.43 | philippel | mjordan: so a space where again, I'm looking at the output of ngrep |
| 20:07.55 | mjordan | between the freeswitch header and the body |
| 20:08.19 | philippel | no according to ngrep |
| 20:08.36 | TazzNZ | that might shed some light on the issue - if PJSIP treats \r and \n "as the same" and FreeSwitch send \r\n it will "see" 2 lines and might treat the \r as the empty header ? |
| 20:08.56 | philippel | https://www.irccloud.com/pastebin/3oq2VSXi |
| 20:09.16 | philippel | that's from ngrep in a terminal window, it sure doesn't look like there is a space |
| 20:09.19 | TazzNZ | there goes that theory :) |
| 20:09.45 | mjordan | TazzNZ: no |
| 20:09.54 | TazzNZ | mine does |
| 20:10.04 | TazzNZ | it would have shown .. for \r\n |
| 20:10.33 | mjordan | hm. |
| 20:11.06 | file | watches |
| 20:11.16 | mjordan | let me got test something out real quick. |
| 20:12.16 | mjordan | er, go test. |
| 20:12.26 | mjordan | (1) PJSIP does not care where Content-Length appears. Yay. |
| 20:13.16 | philippel | (1) is a very good thing |
| 20:13.19 | mjordan | (2) Adding a bunch of spaces between the Headers and body does not appear to matter. |
| 20:13.34 | mjordan | philippel: Yeah, pretty sure my initial theory was just way wrong :-P |
| 20:13.53 | mjordan | the parsing code in PJSIP looks for a new line (indicated by either a \r or \n) or the end of the buffer |
| 20:14.08 | mjordan | if it has a content-type, it then looks at the content-length and parses out the rest of the buffer as the body |
| 20:15.31 | tm1000 | hmmmm |
| 20:15.40 | tm1000 | mjordan: do I file a bug orrrrr? |
| 20:15.43 | mjordan | well |
| 20:15.55 | mjordan | I just slapped your MESSAGE request with different from/to into a sipp scenario |
| 20:15.57 | mjordan | and it worked |
| 20:16.17 | philippel | what does that mean? |
| 20:16.17 | mjordan | So, perhaps it wasn't lying and it really doesn't like something in line 4, column 8 |
| 20:16.31 | tm1000 | line 4 col 8 IS the from line |
| 20:16.33 | tm1000 | sooo |
| 20:17.00 | tm1000 | <1951259XXXX@synsms.bandwidth.com>;tag=12X60XtSBvjDm |
| 20:17.03 | mjordan | or the To. Depends on your indexigin. |
| 20:17.06 | tm1000 | philippel: ^^ |
| 20:17.06 | mjordan | er, indexing. |
| 20:17.33 | tm1000 | From: <1951259XXXX@synsms.bandwidth.com>;tag=12X60XtSBvjDm |
| 20:17.37 | mjordan | tm1000: go ahead and open a bug report. If you want, lock it down temporarily, and if you don't mind, provide the unsanitized request |
| 20:17.44 | tm1000 | To: <sip:1714922XXXX@199.102.239.103:5060>;did=17149223196 |
| 20:17.46 | mjordan | just so I can make sure that we've got the exact same data |
| 20:18.34 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 20:18.34 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 20:18.47 | tm1000 | so its not the TO line |
| 20:18.55 | tm1000 | because that would but it: si<here>p |
| 20:18.59 | tm1000 | which doesnt make sense |
| 20:20.24 | tm1000 | lol this time asterisk segfaulted hahahaah |
| 20:20.35 | mjordan | hrm. |
| 20:20.43 | mjordan | (please file the bug report) |
| 20:20.53 | tm1000 | well let me see….waiting for philippel |
| 20:21.33 | mjordan | tm1000: and get a backtrace please for the crash. That's kind of serious. |
| 20:21.35 | mjordan | :-P |
| 20:22.20 | mjordan | tm1000: oh, and what version of pjproject are you running? Not that I'm sure it will matter, but for making sure we're reproducing the right thing, it'll help to know what is running locally |
| 20:22.21 | tm1000 | yeah I see why it’s crashing though not really an asterisk bug |
| 20:22.33 | tm1000 | mjordan: Asterisk is accepting the message and then routing it like a phone call |
| 20:22.43 | philippel | mjordan: ok tm1000 is trying to figure out why something crashed, but from a SIP perspective, when we fixed and added sip: to the from pjsip is sending back a 202 this time so that's an improvement :) |
| 20:22.44 | tm1000 | so then it goes to spanDSP and spanDSP is like what the hell? |
| 20:22.46 | tm1000 | and craches |
| 20:23.04 | tm1000 | mjordan: ^ |
| 20:23.10 | mjordan | tm1000: well, file a bug report for that, because we probably shouldn't treat it like a fax |
| 20:23.11 | file | wait - there wasn't a URI scheme in the From? |
| 20:23.16 | mjordan | file: nope |
| 20:23.33 | mjordan | file: I missed that :-P |
| 20:23.47 | philippel | so ... what we found is a DoS crash Asterisk ability by sending a properly formed SMS message :) |
| 20:23.56 | mjordan | next time I look more closely at the line number PJSIP spits out (which is apparently 1 based for easy reading) |
| 20:24.26 | tm1000 | [2014-06-26 16:24:07] WARNING[16742][C-00000002]: channel.c:5334 set_format: Unable to find a codec translation path from (nothing) to (slin) |
| 20:24.27 | tm1000 | [2014-06-26 16:24:07] ERROR[16742][C-00000002]: res_fax.c:1397 generic_fax_exec: channel 'Message/ast_msg_queue' failed to set write format to signed linear'. |
| 20:24.29 | tm1000 | haha :-) |
| 20:24.53 | mjordan | Why are you sending your message channel into an extension that sets up fax? |
| 20:25.02 | tm1000 | mjordan: you should ask ASTERISK that |
| 20:25.14 | tm1000 | I ahve out of band set to a context but PJSIP doesnt think its out of band :-) |
| 20:25.15 | mjordan | what extension did it execute? |
| 20:25.25 | philippel | mjordan: no idea, but ... none the less, I'm sure you would agree that crashing Asterisk is a bit extreme ;) |
| 20:25.36 | mjordan | yup, I'd expect res_fax to bail |
| 20:25.43 | mjordan | so please do file an issue for the crash |
| 20:26.00 | philippel | yeah that would be the nice thing to do |
| 20:26.02 | mjordan | so, when a MESSAGE request is received, Asterisk assigns it to a special channel driver, Message, to process the message. That gets punted out to the dialplan for processing |
| 20:26.22 | mjordan | there's some configuration parameters that you can set to have that get put into a particular place in the dialplan |
| 20:26.43 | mjordan | generally, it will route it to the extension specified by the request line (IIRC) |
| 20:26.45 | tm1000 | http://pastebin.com/H1geWShc |
| 20:26.49 | tm1000 | dialplan cli log |
| 20:27.07 | mjordan | yay, I think I was right |
| 20:27.17 | mjordan | so, for text messages, you probably don't want it dropping into your from-pstn context |
| 20:27.29 | mjordan | since that will want to handle it like a normal basic call, and this definitely is not a normal basic call |
| 20:27.31 | tm1000 | these are in sip.conf: accept_outofcall_message=yes |
| 20:27.31 | tm1000 | outofcall_message_context=sms-incoming |
| 20:27.37 | mjordan | right |
| 20:27.42 | tm1000 | and so no it’s not hitting that said context |
| 20:27.47 | mjordan | in pjsip.conf, there's an equivalent setting |
| 20:27.55 | tm1000 | mjordan: OH MAAAANNNN |
| 20:27.56 | tm1000 | :-) |
| 20:27.58 | file | grins |
| 20:28.09 | tm1000 | slaps file with a large trout |
| 20:28.26 | philippel | well that does make sense, but it's a nice catch because that's definitely a DoS attach vector :) |
| 20:28.28 | file | tm1000, the trout could survive in the large amount of water outside |
| 20:29.05 | tm1000 | file: so do we have these settings listed :-) |
| 20:29.20 | file | NO CLUE |
| 20:29.32 | mjordan | tm1000: yup, give me a sec |
| 20:29.44 | philippel | mjordan: so it would seem we should stop discussing that one here and open up a ticket as a security issue? |
| 20:30.17 | rmudgett | It's sounding like a config issue causing a crash. |
| 20:31.58 | philippel | rmudgett: well my simplistic view (that tm1000 could correct me on) is that he has PJSIP setup with nothing to tell it to accept outofcall messages, and thus it crashes the system, which would be a common 'configuration' that a script could go out there scanning the network just sending unsolicited SMS messages, and in this case, it seems like the malformed |
| 20:31.58 | philippel | message did not crash Asterisk but the well formed message did. Or am I missing something? |
| 20:31.59 | mjordan | philippel: I'd say stopping discussing it is just fine |
| 20:31.59 | tm1000 | rmudgett: technically yes I am just waiting to hear what the outofcall settings would look like for pjsip |
| 20:32.09 | mjordan | just in case |
| 20:32.32 | philippel | ok ... no more from me then :) |
| 20:32.34 | mjordan | philippel: let's go ahead and make a locked down issue for the crash |
| 20:32.48 | tm1000 | mjordan: ok… do you know the magical settings :-) |
| 20:33.17 | mjordan | working on it |
| 20:33.18 | mjordan | :-P |
| 20:34.24 | mjordan | yay |
| 20:34.30 | mjordan | it was actually well named: message_context |
| 20:34.42 | mjordan | in your CLI: config show help res_pjsip endpoint message_context |
| 20:34.54 | tm1000 | will theres going to be two types right? |
| 20:35.02 | tm1000 | accept_outofcall_message && outofcall_message_context |
| 20:35.24 | mjordan | or: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+Configuration_res_pjsip#Asterisk12Configuration_res_pjsip-endpoint_message_context |
| 20:35.31 | mjordan | nope, we nixed some of that |
| 20:35.32 | tm1000 | well looks like just one setting is needed :-) |
| 20:35.36 | mjordan | just the one setting is needed |
| 20:35.47 | tm1000 | http://pastebin.com/0uTftZ7g |
| 20:35.52 | mjordan | the 'accept this' option wasn't needed. A large part of why that was added was when it was added to chan_sip |
| 20:36.57 | tm1000 | that still doesnt work, asterisk seems to ignore it |
| 20:37.02 | mjordan | hm |
| 20:37.05 | mjordan | pb the config? |
| 20:37.06 | tm1000 | and stil routes it to the default |
| 20:37.08 | tm1000 | k |
| 20:37.30 | tm1000 | http://pastebin.com/HFcsM2NG |
| 20:38.01 | mjordan | it's an endpoint setting |
| 20:38.13 | mjordan | so you have to set it on whatever endpoints are going to receive MESSAGE requests |
| 20:39.06 | tm1000 | oh so thats very different than before |
| 20:40.16 | mjordan | there's actually only very few [global] options. Most things are set up on endpoints, using templates if you want them to apply to multiple endpoints |
| 20:41.40 | tm1000 | yup yup. It definately makes more sense now trust me :-) |
| 20:41.50 | tm1000 | just different, and I wish you chould just give up on chan_sip |
| 20:41.55 | mjordan | \o/ |
| 20:42.01 | file | never gonna give you up |
| 20:42.06 | mjordan | I'm guessing it routed to the right place in the dialplan? |
| 20:42.17 | malcolmd | never gonna give, never gonna give |
| 20:42.24 | tm1000 | yay!!!! |
| 20:42.27 | tm1000 | mjordan: <3 |
| 20:42.28 | tm1000 | it worked |
| 20:42.39 | tm1000 | ok now I have a lot of documentation to write up |
| 20:42.49 | mjordan | doing what we must because we can: http://www.youtube.com/watch?v=QWq0bSvc31A |
| 20:42.57 | mjordan | tm1000: sorry for the confusion earlier |
| 20:43.53 | TazzNZ | *shudder* Rick Asheighly..... |
| 20:44.09 | tm1000 | ack doctors appointment!! |
| 20:44.18 | tm1000 | mjordan: I will send you the bug later today |
| 20:48.21 | mjordan | cool, thanks |
| 20:50.11 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:02.20 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-lvuwbisubsciqtgr) |
| 21:19.51 | *** join/#asterisk-dev otherwiseguy (otherwiseg@nat/redhat/x-mlkbginxdohovejr) |
| 21:44.53 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:44.53 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:57.44 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-qnmebwsbvopkkbjq) |
| 22:03.30 | coreyfarrell | mjordan / file: so one thing we need to look into is in frame.c / __frame_free(), if we use ao2_replace(fr->subclass.format, NULL); instead of just ao2_cleanup, we get a segfault. |
| 22:03.42 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 22:04.13 | coreyfarrell | this is what we need to change to fix the fracking though.. __frame_free is running ao2_cleanup(fr->subclass.format) multiple times in certain situations |
| 22:05.19 | coreyfarrell | or to rephrase __frame_free is being called on frames that are fr->mallocd==0, the frame is later reused without being reinitialized |
| 22:07.23 | coreyfarrell | first segfault I hit is from fr->src = "pcm".. http://paste.ubuntu.com/7708192/ |
| 22:07.43 | mjordan | coreyfarrell: NULL format |
| 22:07.45 | mjordan | hm. |
| 22:08.40 | coreyfarrell | this backtrace is with ao2_replace in __frame_free to NULL fr->subclass.format since we're removing the ref count |
| 22:08.41 | mjordan | I kind of don't want to immediately say "let's be null tolerant" |
| 22:08.47 | mjordan | right |
| 22:09.26 | mjordan | coreyfarrell: maybe frame_free - as a start - should memset the frame to 0 if malloc == 0 |
| 22:10.06 | coreyfarrell | that would actually cause a crash and also leak the reference held by fr->subclass.format |
| 22:11.24 | mjordan | hm. |
| 22:11.50 | mjordan | If you free a frame, I woudl expect that the reference to the format would be released first |
| 22:12.09 | mjordan | there are a lot of places where frames get reused, as frames are often thread locally stored |
| 22:12.35 | mjordan | but ast_frdup should already be taking care of that properly |
| 22:12.41 | coreyfarrell | see file.c: get_filestream |
| 22:12.55 | coreyfarrell | I think this is where the frame in my segfault was originally initialized |
| 22:13.42 | mjordan | hm. Which frame? |
| 22:14.27 | mjordan | s->fr? |
| 22:14.43 | coreyfarrell | I think |
| 22:15.02 | coreyfarrell | based on s->fr.src = fmt->name; (and the segfault being on fr->src=="pcm") |
| 22:16.56 | mjordan | correct. read_frame will call into the format_* module, providing it the file stream. They are to populate the frame on the filestream |
| 22:17.32 | mjordan | see pcm_read in format_pcm |
| 22:17.40 | coreyfarrell | yup it's returning &s->fr |
| 22:17.57 | mjordan | my guess is that s->fmt->format wasn't set properly (guess) |
| 22:18.28 | coreyfarrell | what about the ast_frfree(fr) in read_frame ? |
| 22:18.56 | mjordan | ast_frisolate can (but may not) duplicate the frame by malloc'ing it |
| 22:19.15 | coreyfarrell | s->fr.mallocd == 0 so I think it will ast_frdup |
| 22:19.19 | mjordan | right |
| 22:20.22 | coreyfarrell | so this means that ast_frfree is being called on s->fr |
| 22:21.03 | coreyfarrell | and when we get to the next frame s->fr.subclass.format == NULL (with my fix to __frame_free, without it we end up with an extra ao2_cleanup for every playback frame) |
| 22:21.51 | mjordan | on the next read, however, the format module was supposed to copy the format back onto s->fr |
| 22:22.18 | mjordan | so it should have been re-constructed before that point (theoretically, anyway) |
| 22:23.13 | coreyfarrell | I think s->fr is only setup during get_filestream (allocation of s) |
| 22:24.18 | mjordan | true, but read_frame (called from ast_readaudio_callback before ast_write) should call into read_pcm. That should rebuild the frame on the filestream * (in read_pcm). That should be copying the format from s->fmt->format back onto the frame (line 87 of format_pcm) |
| 22:24.33 | file | gah frfree |
| 22:25.07 | mjordan | so that's why I'm a bit confused - while the frame on the filestream does get frdup'd into the heap, which then blows away the static variant on the filestream *, each subsequent read uses the filestream *'s static frame to build the next read frame of audio |
| 22:25.18 | mjordan | something seems to have gotten broken down in that chain :-) |
| 22:25.33 | mjordan | anywho, I concur with file that pizza sounds good, so I shall go procure some |
| 22:25.48 | coreyfarrell | I don't follow what you are talking about in line 87 of format_pcm |
| 22:26.15 | file | thinks he knows what is going on |
| 22:26.45 | file | or I may in a sec |
| 22:27.17 | *** join/#asterisk-dev danjenkins__ (~dan@nat/digium/x-epunsdwttovsochn) |
| 22:28.52 | file | so when I was mucking in that area I made an effort to reduce the amount of times we set up frame parameters when they get reused, that's why this is happening |
| 22:29.31 | file | so we can make it re set up the frame or make it so it doesn't have to |
| 22:29.37 | mjordan | just realizes he was looking at an older version of format_pcm |
| 22:30.10 | file | at this point I'm fine either way, it's something that can be done in the future |
| 22:30.15 | file | (optimizing it more) |
| 22:30.49 | coreyfarrell | one of the things I was thinking of was to add a new flag for fr->mallocd to indicate that the frame is ref'ed |
| 22:31.24 | coreyfarrell | or rather that the format is ref'ed and should be cleaned by ast_frfree |
| 22:31.51 | coreyfarrell | some cases where it's ref'ed but should not be touched by ast_frfree (like the frame in s->fr) |
| 22:31.53 | file | that'd be quite a bit of auditing |
| 22:33.15 | coreyfarrell | well if we just make the changes to frame.h/frame.c, then we will have reference leaks instead of fracks/crashes |
| 22:33.27 | coreyfarrell | then we can just track the stuff with REF_DEBUG |
| 22:34.03 | coreyfarrell | in addition to code auditing.. but I think reference leaks are better than fracks or segfaults |
| 22:34.28 | coreyfarrell | and I don't often advocate that leaking is the better way to go :) |
| 22:34.35 | file | neither are acceptable, you're just trading ^_^ |
| 22:35.32 | file | if only they could be traded for bitcoin... |
| 22:36.23 | file | I'm out of mentalness for today I'm afraid |
| 22:36.34 | coreyfarrell | I'm also thinking that __frame_free could clear format if (fr->malloc & (AST_MALLOCD_HDR | AST_MALLOCD_FMT)).. |
| 22:36.39 | TazzNZ | more music file ! :D |
| 22:38.11 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-mzvqgfyvaqxdlitk) |
| 22:39.34 | *** join/#asterisk-dev terryw (otherwiseg@nat/redhat/x-kggoffaxhopqasab) |
| 22:44.41 | file | cool, my hold/unhold with Firefox is a sipml5 problem |
| 22:45.03 | file | thanks Google for NOT EMAILING ME even though I selected that option when posting to their Google Group |
| 22:55.02 | *** join/#asterisk-dev SGjunior (~sgjunior@host49-101-static.58-79-b.business.telecomitalia.it) |
| 23:08.04 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |