| 00:13.43 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 00:18.14 | *** join/#asterisk-dev ipengineer (~zconkle@108-206-120-218.lightspeed.mckntx.sbcglobal.net) |
| 00:37.12 | *** join/#asterisk-dev suneye (~atcmmi@119.139.62.75) |
| 00:46.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.151) |
| 01:10.59 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 01:49.16 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.151) |
| 02:08.09 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 02:29.04 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 02:29.04 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 02:51.07 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.125.124) |
| 03:02.41 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 03:05.20 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 03:35.53 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.164) |
| 03:49.18 | *** join/#asterisk-dev serafie (~erin@24.96.64.240) |
| 03:55.55 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.125.130) |
| 04:02.37 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 04:10.09 | *** part/#asterisk-dev coreyf1513 (~cfarrell@24-177-3-55.dhcp.nwtn.ct.charter.com) |
| 04:28.22 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.127.208) |
| 04:36.31 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 04:36.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 05:00.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 05:02.37 | *** join/#asterisk-dev atcmmi (~atcmmi@116.7.102.29) |
| 05:03.00 | *** join/#asterisk-dev coreyf1513 (~cfarrell@24-177-3-55.dhcp.nwtn.ct.charter.com) |
| 05:15.14 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.127.216) |
| 05:38.52 | *** join/#asterisk-dev Matt__4 (~Matt_@196-215-88-15.dynamic.isadsl.co.za) |
| 05:58.10 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:15.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.120) |
| 06:51.06 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:51.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:56.04 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 06:59.36 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.125.131) |
| 07:03.44 | *** join/#asterisk-dev suneye (~atcmmi@121.34.42.101) |
| 07:07.01 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.125.114) |
| 07:12.22 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:26.12 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 07:34.39 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.142) |
| 07:50.42 | *** join/#asterisk-dev zpotoloom (~tom@tom.data.ee) |
| 07:54.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:54.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:17.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.142) |
| 08:32.57 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:08.39 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 09:08.39 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 09:29.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.84) |
| 09:30.45 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 09:34.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.84) |
| 10:05.15 | *** join/#asterisk-dev barbosa2 (~juliano.b@177-069-248-123.static.ctbctelecom.com.br) |
| 10:25.55 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.124.11) |
| 10:29.06 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 10:30.15 | *** join/#asterisk-dev dronacid (~dronacid@vpn.openroot.de) |
| 10:35.32 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.11) |
| 10:59.14 | *** join/#asterisk-dev dms (~dms@c-68-58-240-113.hsd1.sc.comcast.net) |
| 10:59.14 | *** mode/#asterisk-dev [+o dms] by ChanServ |
| 11:24.30 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:24.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:27.35 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:21.02 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:21.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:26.42 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 12:28.46 | file | Friday. |
| 12:29.53 | dym | indeed. |
| 12:54.38 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187.76.181.102) |
| 12:57.04 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-sohkoqdvqohxgmbk) |
| 12:57.28 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 12:58.30 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 13:04.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:04.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:08.00 | anonymouz666 | leifmadsen: miss the presence state part in the 4th edition of the book |
| 13:11.42 | leifmadsen | anonymouz666: eh? |
| 13:18.18 | anonymouz666 | yeah, it's cool |
| 13:18.54 | file | this conversation is confusing |
| 13:22.22 | anonymouz666 | file: let's put some RTP stuff in this conversation to make things clearer :-P |
| 13:22.42 | anonymouz666 | cleaner |
| 13:39.25 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.124.67) |
| 13:45.24 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 13:50.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:50.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:58.28 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-feognqrxyxuxyrtg) |
| 13:58.28 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.59 | file | nods to the newly arrived |
| 14:06.24 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.3) |
| 14:07.53 | mjordan | waves |
| 14:11.53 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 14:20.25 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:23.11 | file | mjordan, this discussion is FUN! |
| 14:24.55 | mjordan | I know! |
| 14:25.07 | mjordan | it's like open and what not |
| 14:25.15 | file | I will fight you to the bitter end, though :P |
| 14:25.24 | mjordan | lawl |
| 14:25.34 | mjordan | BUT I AM RIGHT |
| 14:25.52 | mjordan | MY USE OF CAPS LOCK ADDS TO MY PERSUASIVENESS |
| 14:26.04 | file | MOAR CAPS!!! |
| 14:26.38 | mjordan | The one reason I do like your proposal is my hatred of Local channels, which your approach obviates |
| 14:27.10 | file | only one reason? |
| 14:27.23 | mjordan | Well, it's better than my initial description, obviously |
| 14:27.52 | mjordan | But I really like the idea of being able to call /channels/{id}/hook?channel=other_id from any channel |
| 14:28.19 | file | the only way I would be fine with having anything like that is if we explicitly didn't do any additional features and documented it heavily |
| 14:28.26 | mjordan | You can do some fun things with that. You can also create a pool of Local channels (ew) and keep em around just for the purpose of creating snoop/monitor/whatever paths |
| 14:28.35 | mjordan | file: agreed, it should do *nothing* but hook |
| 14:29.32 | mjordan | It does keep the lifetime of the hooker and hook target separate. I worry a bit about the "Local channel chain" phenomenon when someone has a bunch of Snoop channels in a chain with other bridges and what not and hangs up the Snoop target |
| 14:30.05 | mjordan | But I really do wish we didn't need Local channels for this |
| 14:30.09 | mjordan | They're clunky. |
| 14:32.07 | file | ugh - would you expect an ARI dev to do that? (Local channels, keep 'em around, etc) |
| 14:32.27 | file | or... further ugh... internal impl detail |
| 14:33.42 | mjordan | yes |
| 14:33.48 | mjordan | In fact, I guarantee I'll want to do that |
| 14:34.11 | mjordan | One of the use cases I've been thinking about was a conversation on asterisk-users, where someone wanted everyone in a Conference to have their own independent whispered MoH |
| 14:34.33 | mjordan | In other words, we're all in a waiting area, waiting for something to happen, but we each have our own music source, and we can all talk to each other |
| 14:34.38 | file | sure |
| 14:34.53 | mjordan | using a pool of Local channels is nice for that, as you can re-use the resources you've already created |
| 14:35.01 | mjordan | yes, you don't *have* to |
| 14:35.09 | mjordan | But it'd certainly be more performant |
| 14:35.51 | file | provided you stopped MOH when not in use, potentially |
| 14:38.17 | mjordan | well, you don't have to. But hilarity would ensue. |
| 14:38.44 | file | if you don't and they aren't connected to anything that's audio frames every 20ms |
| 14:38.46 | file | plus a timer |
| 14:39.15 | mjordan | YOU GET A FRAME |
| 14:39.25 | mjordan | (actually you don't, they just pile up) |
| 15:07.42 | *** join/#asterisk-dev gtjoseph (~gtj@unaffiliated/gtj) |
| 15:14.24 | file | nods to gtjoseph |
| 15:22.47 | *** join/#asterisk-dev hehol (~Adium@2a01:198:71d:0:7df9:9d0e:e6eb:c7f1) |
| 15:33.36 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:34.49 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 15:37.49 | *** join/#asterisk-dev skirmisha (~vk@46.47.82.189) |
| 15:37.56 | skirmisha | hi guys |
| 15:38.30 | skirmisha | in chan_sip.c there is funciont called check_auth_result check_peer_ok |
| 15:38.56 | skirmisha | could someone tell me whether this function is doing the actual auth or it just report or look in cache |
| 15:39.57 | mjordan | file: do you think any of your outbound proxy work would also address ASTERISK-22666? |
| 15:39.58 | LieutPants | [ASTERISK-22666] [Status: Waiting for Feedback] [Assigned: davidb66] Outbound proxy ignored after initial invite - https://issues.asterisk.org/jira/browse/ASTERISK-22666 |
| 15:41.55 | mjordan | skirmisha: from a very wide view, yes, it does eventually call the function that performs the actual auth check. It does a lot more than that too however. The function that actually performs the authentication checking is check_auth. |
| 15:43.13 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 15:44.30 | skirmisha | i see it sets peer = find_peer |
| 15:45.05 | file | mjordan, ummmm |
| 15:45.12 | file | no? |
| 15:45.18 | file | I haven't changed that aspect |
| 15:45.19 | skirmisha | and then it search based on IP |
| 15:46.19 | skirmisha | now does that mean if there is existing peer/username or IP it will just use it and replace registration with new/coming one |
| 15:47.40 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.3) |
| 15:49.17 | skirmisha | so setting the peer variable means that peer exist or it tries to auth or just treat it as auth user |
| 15:52.31 | skirmisha | or in other words does that peer set means that if there is a match we don't need to auth user |
| 15:53.20 | mjordan | in check_peer_ok, it will first look up the peer by username. If it fails to find it, it will attempt to look it up by IP address. It doesn't replace registrations or peers or anything else. This is going by the check_user/check_user_full functions. This logic is used for everything but REGISTER requests, which have a different path (because, of course, it's chan_sip). |
| 15:53.58 | mjordan | If it fails to find a peer, there's two things that can happen |
| 15:54.46 | mjordan | It will either bounce out of authorization checking if we allow guests |
| 15:55.02 | mjordan | If we don't allow guests and we perform alwaysauthreject, it will set the peer to the bogus_peer |
| 15:55.14 | mjordan | The bogus_peer is a fake peer that will never authenticate |
| 15:59.00 | *** join/#asterisk-dev jtrunecek_ (d9a9b6ce@gateway/web/freenode/ip.217.169.182.206) |
| 15:59.10 | *** part/#asterisk-dev jtrunecek_ (d9a9b6ce@gateway/web/freenode/ip.217.169.182.206) |
| 16:07.01 | skirmisha | the question is - if extension is registered and new register request comes - if one of the things match (username/IP) does it perform auth again or just replace the the data with new one that comes from latest register request? |
| 16:07.50 | mjordan | So, if you're talking about a REGISTER request, you're looking in the wrong place. |
| 16:08.07 | mjordan | register_verify is what you want. |
| 16:09.00 | mjordan | And - while this is easily verifiable - if IIRC, it will auth again. It doesn't know that the REGISTER request that just arrived for that peer is the same IP address or device that previously registered as that peer. |
| 16:16.40 | skirmisha | so from what i understand that function just look the peer and then perform the auth /check_user or check_user_full/ |
| 16:17.26 | mjordan | what function? |
| 16:17.33 | mjordan | register_verify? |
| 16:18.10 | mjordan | for better or worse, ti doesn't go through the logic in check_user or check_user_full. It does use the same authentication verification code that those functions use (check_auth) |
| 16:18.44 | mjordan | And there are some other differences with how it handles a peer, as it will also honor the incredibly silly auto create peer option |
| 16:18.54 | skirmisha | i am talking about check_auth_result |
| 16:19.26 | mjordan | that's not a function |
| 16:19.30 | mjordan | That's a return value enum |
| 16:19.52 | skirmisha | yes it returns the peer based on username or IP |
| 16:19.58 | skirmisha | am i correct? |
| 16:20.05 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-ggscjcgktobczvls) |
| 16:20.16 | mjordan | no |
| 16:20.43 | mjordan | I'm staring at Asterisk 11. check_auth_result is an enum value returned by various functions. Those functions do not return a pointer to a peer. |
| 16:24.25 | skirmisha | ok once again - it just check whether peer/user exist in asterisk database either based on username or IP |
| 16:25.09 | skirmisha | is this enum called from sip invites as well or only from sip registrations? |
| 16:25.48 | mjordan | an enum isn't called |
| 16:26.12 | skirmisha | ok whatever you call it |
| 16:27.00 | skirmisha | i am trying to figured out whether this function or whatever you called has relation with sip registrations |
| 16:27.11 | mjordan | All of the various authentication functions propagate the value of the enum to the callers so they know whether or not the request was authenticated and - if it was not - why it wasn't. |
| 16:27.29 | mjordan | register_verify is what verifies a REGISTER request. That includes calling check_auth, which performs the authentication bit. |
| 16:27.33 | mjordan | That's your code path. |
| 16:28.33 | mjordan | And, I'm not trying to be mean or anything, but you should probably brush up on C if you're going to go mucking around in chan_sip. Knowing the difference between an enum and a function is important, particularly if you change anything in there. Returning the wrong enum value can open up a *lot* of vulnerabilities |
| 16:29.29 | skirmisha | this is what i am trying to figure out |
| 16:29.41 | skirmisha | because we have some attacks recently |
| 16:30.04 | skirmisha | so i am wondering how those users register |
| 16:30.15 | mjordan | what version are you on? |
| 16:30.20 | skirmisha | 1.8 |
| 16:30.24 | mjordan | the full version :-) |
| 16:30.31 | skirmisha | 1.8.8.1 |
| 16:30.36 | file | oof |
| 16:30.41 | mjordan | yeah. There have been numerous security vulnerability reports since then. |
| 16:30.51 | skirmisha | the code is changed there |
| 16:30.53 | mjordan | Some that directly relate to aspects of registration. |
| 16:30.58 | mjordan | Yes. |
| 16:31.10 | skirmisha | by some programmer which left and i have to figured out what is exactly doing his code |
| 16:31.25 | mjordan | That's about 2 years old. |
| 16:31.28 | skirmisha | yes |
| 16:31.47 | skirmisha | but hackers are able to register somehow and i see that allowguest is on |
| 16:31.55 | skirmisha | so must be something with this code |
| 16:32.17 | skirmisha | i am checking the latest 1.8 ver 1.8.8.25 |
| 16:32.23 | skirmisha | code isn't changed much there |
| 16:32.43 | mjordan | bogus_peer was an addition that directly addressed security vulnerabilities in alwaysauthreject logic during inbound request processing. |
| 16:32.57 | mjordan | it doesn't take much to have a vulnerability :-) |
| 16:34.22 | skirmisha | is it related to this code? |
| 16:34.37 | skirmisha | in 1.8.8.1 there is no bogus peer in the code |
| 16:35.32 | mjordan | http://downloads.asterisk.org/pub/security/AST-2013-003.pdf |
| 16:37.19 | mjordan | skirmisha: unfortunately, there isn't much I can help you with other than to recommend that you upgrade to a more recent version, and to start at register_verify for tracing down the register request processing. |
| 16:38.18 | skirmisha | can you help me with finding the patch |
| 16:38.27 | skirmisha | to see the diff, the url in the file does not work |
| 16:38.28 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 16:38.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:39.44 | mjordan | http://downloads.asterisk.org/pub/security/AST-2013-003-1.8.diff |
| 16:42.14 | skirmisha | thanks a lot, i appreciate it |
| 16:44.45 | skirmisha | one question, is this bug in 1.4 version? |
| 16:44.52 | skirmisha | i mean exist |
| 16:45.41 | mjordan | possibly. Even probably. |
| 16:45.50 | mjordan | 1.4 is no longer a supported version. |
| 16:45.59 | skirmisha | and secondly - When authenticating via SIP with alwaysauthreject enabled, allowguest disabled, and autocreatepeer disabled - Meaning that config must be exactly same or? |
| 16:46.32 | skirmisha | with those options or it does not matter |
| 16:46.39 | mjordan | yes. If you have allowguest, you don't authenticate because you allow guest calls. If you have autocreatepeer enabled, then you create peers auto-magically so you're already letting them in that way. |
| 16:49.28 | skirmisha | i see that only allow guest is enabled |
| 16:49.35 | skirmisha | rest are set the no |
| 16:50.32 | skirmisha | anyway have to apply the patch |
| 16:50.46 | skirmisha | let me see if i can do it with no errors |
| 17:25.23 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-ujltuztmxfnxwwtx) |
| 17:25.37 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 17:34.37 | *** join/#asterisk-dev protocoldoug (~doug@unaffiliated/protocoldoug) |
| 17:37.16 | file | One does not simply compile chan_sip.c in 5 seconds... |
| 17:37.41 | pabelanger | ccache |
| 17:37.59 | pabelanger | okay, that is for the second time |
| 17:38.28 | pabelanger | we could setup up distcc and some super awesome cloud resource when ever somebody hits chan_sip.c |
| 17:38.48 | mjordan | I'd go another route. |
| 17:38.56 | mjordan | I'd make chan_sip compile longer each time you re-compile it. |
| 17:39.16 | mjordan | it's a subtle hint. |
| 17:39.57 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 17:39.58 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:46.26 | file | leedm777, what. |
| 17:47.06 | leedm777 | file: what, what? |
| 17:47.10 | file | leedm777, that was it? |
| 17:47.41 | leedm777 | for form processing. JSON will be a bit more. |
| 17:47.54 | file | aye |
| 17:47.54 | leedm777 | b/c we already had code for that, apparently. |
| 18:00.55 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.185) |
| 18:05.22 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 18:06.45 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 18:32.43 | *** join/#asterisk-dev tzanger (andrew@wallace.mixdown.ca) |
| 18:46.11 | *** part/#asterisk-dev tzanger (andrew@wallace.mixdown.ca) |
| 19:01.07 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.124.241) |
| 19:02.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-20-231.west.biz.rr.com) |
| 19:13.14 | *** part/#asterisk-dev hexanol (~bibi@modemcable094.94-70-69.static.videotron.ca) |
| 19:15.40 | skirmisha | guys what is strncmp doing? |
| 19:16.33 | sgriepentrog | compares two strings in a case insensitive manner |
| 19:16.37 | putnopvut | It performs a string comparison between two strings, using the length provided as the maximum amount of characters to check. I'd recommend reading the manpage on it. |
| 19:16.46 | putnopvut | sgriepentrog: it's case-sensitive |
| 19:17.05 | sgriepentrog | sorry- right. I'm apparently using too small a font. |
| 19:17.54 | skirmisha | ok but then !strncmp should give negative if there is no match? |
| 19:18.26 | putnopvut | skirmisha: I'd recommend reading the manpage. A 0 return from strncmp means there is a match. |
| 19:18.46 | sgriepentrog | think of strcmp family as giving you difference of the two strings, thus ! difference is match (but only up to the nth length) |
| 19:19.06 | sgriepentrog | he's right, seriously type man strncmp and you get all kinds of useful info |
| 19:22.46 | skirmisha | i think i got it |
| 19:23.13 | sgriepentrog | we expect to be credited on your next patch ;-) |
| 19:23.48 | skirmisha | if i have strlen==9 and i want to check first 3 digits of it then i use !strncmp(1234567,123,3) |
| 19:25.34 | pabelanger | Sounds like you really need to hire a programmer |
| 19:27.18 | skirmisha | !strncmp(peer->name,"111",3) would give ok if first 3 digits are 111 |
| 19:27.31 | skirmisha | correct? |
| 19:27.38 | pabelanger | test it |
| 19:27.41 | pabelanger | and let us know |
| 19:27.58 | putnopvut | skirmisha: That should return 0, indicating a match occurred. |
| 19:28.17 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 19:28.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:28.18 | skirmisha | lovely |
| 19:28.25 | anonymouz666 | https://www.linkedin.com/today/post/article/20131031003105-24171--googlewinseverything-part-1 -> good reading |
| 19:28.47 | anonymouz666 | wrong channel |
| 19:28.49 | anonymouz666 | sorry |
| 19:28.58 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.129) |
| 19:29.04 | skirmisha | by the way, where and how can i hire asterisk developer? |
| 19:29.38 | anonymouz666 | skirmisha: asterisk-biz list? |
| 19:30.36 | anonymouz666 | there are many in here, but I think is always a good choice to start a conversation about this using e-mail |
| 19:31.41 | anonymouz666 | Digium also offers this kind of service (someone correct me If I'm wrong) |
| 19:31.52 | pabelanger | not for a long time |
| 19:36.13 | anonymouz666 | skirmisha: (it seems you have doubts about C language, not Asterisk specific code, you could try the C channel in this network) |
| 19:37.47 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:43.58 | skirmisha | no i don't doubt i just checking the code of previous programmer that have made changes |
| 19:44.06 | skirmisha | as i am not programmer i need some help |
| 19:46.34 | mjordan | If you can't deploy stock Asterisk 1.8.x and have made custom modifications to chan_sip, your best route would be to look for a consultant. The asterisk-biz mailing list is the appropriate place to do that. |
| 19:52.20 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:08.39 | skirmisha | stock asterisk is not a problem |
| 20:09.03 | skirmisha | problem is with some hackers that use our client's accounts to make calls |
| 20:09.19 | skirmisha | and because code is changed i am digging now how those guys are able to do it |
| 20:15.56 | leifmadsen | I suspect it's not a code problem, but rather a standard configuration issue |
| 20:16.11 | leifmadsen | like devices in sip.conf setup with numbers and password that match the extension |
| 20:16.16 | leifmadsen | or something like that |
| 20:16.29 | leifmadsen | or guest access pointing at default context that also includes outbound dialing contexts |
| 20:16.59 | leifmadsen | I would recommend a consultant skilled in these things review your configuration as a security audit |
| 20:31.31 | skirmisha | its not the config for sure |
| 20:31.44 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 20:35.03 | *** join/#asterisk-dev terryw (~otherwise@2605:a601:2c2:c501:2677:3ff:fe8f:2730) |
| 20:47.40 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 20:47.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:53.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 20:53.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:57.34 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.129) |
| 21:07.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:29.12 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-feognqrxyxuxyrtg) |
| 21:33.33 | *** join/#asterisk-dev BarthezZ (~bart@monitoring.deheij-ict.nl) |
| 21:38.48 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:38.48 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 21:51.02 | *** join/#asterisk-dev vlad_starkov (~vlad_star@109.188.126.80) |
| 22:20.25 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 22:59.28 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-ggscjcgktobczvls) |
| 23:07.12 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.166) |
| 23:07.51 | *** join/#asterisk-dev vlad_sta_ (~vlad_star@109.188.126.166) |
| 23:19.27 | *** join/#asterisk-dev terryw (~otherwise@rrcs-173-197-20-231.west.biz.rr.com) |