FWIW - roadmap for 5.0...
Call Announce (aka Call Screening)
Phase 2 will also include the classic Call Announce functionality. If the PA
is front ending all calls then (based on user config), if the user chooses
the option to transfer to the user, the caller is prompted to record his/her
name. U
what firewall are you using?
2010/8/7 Matt White
> I've thought about it, but they also support remote workers on home cable
> modems.
>
> I've been thinking of moving them to vpn's.
>
> -M
>
> >>> "Todd Hodgen" 08/07/10 5:49 PM >>>
>
> How about a temporary fix by blocking all 5060 traffic tha
(Hint: Correct, you have to add the Package "Country Block". It blocks a
Country though, and is not port specific)
On Sun, Aug 8, 2010 at 7:11 PM, Rolland Hart wrote:
> If you happen to be running Pfsense Matt you can block a whole Countries
> CIDR with the country block package. Works rather we
If you happen to be running Pfsense Matt you can block a whole Countries
CIDR with the country block package. Works rather well.
Rolland
On Sun, Aug 8, 2010 at 2:12 PM, Michael Picher wrote:
> Agreed, this can be solved with a firewall or sip firewall.
>
> Block 5060 & RTP from all but US based
Agreed, this can be solved with a firewall or sip firewall.
Block 5060 & RTP from all but US based IP addresses for instance.
Mike
On Sat, Aug 7, 2010 at 7:06 PM, Michael Scheidell <
michael.scheid...@secnap.com> wrote:
> On 8/7/10 6:13 PM, Tony Graziano wrote:
>
> That seems actually hard to
On 8/7/10 6:13 PM, Tony Graziano wrote:
That seems actually hard to implement because it adds a layer to all
calls at the proxy. Have you looked at the sipvicious scripts yet that
allow it to be recognized and killed?
pfsense with the snort package could deal with these.
there is also a 'kill
I've thought about it, but they also support remote workers on home cable
modems.
I've been thinking of moving them to vpn's.
-M
>>> "Todd Hodgen" 08/07/10 5:49 PM >>>
That seems actually hard to implement because it adds a layer to all calls
at the proxy. Have you looked at the sipvicious scripts yet that allow it to
be recognized and killed?
On Sat, Aug 7, 2010 at 5:42 PM, Matt White wrote:
> Yes, that is exactly the scenario I'm describing.
>
> This custome
ummit-grp.com]
Sent: Saturday, August 07, 2010 2:43 PM
To: thod...@verizon.net
Cc: sipx-users@list.sipfoundry.org
Subject: RE: [sipx-users] Blocking SIP URI Calls from the innternet
Yes, that is exactly the scenario I'm describing.
This customer actually already has a call block feature
Yes, that is exactly the scenario I'm describing.
This customer actually already has a call block feature with their ITSP...ie to
block anonymous calls and a few others. But the calls did not cease. When we
looked into it the calls where not coming in via the SIP trunk but directly to
port 5
://www.myitdepartment.net/gethelp/
- Original Message -
From: Tony Graziano
To: 'thod...@verizon.net' ; 'mwh...@thesummit-grp.com'
Cc: 'sipx-users@list.sipfoundry.org'
Sent: Sat Aug 07 12:58:13 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
Hence w
mers:
http://www.myitdepartment.net/gethelp/
- Original Message -
From: sipx-users-boun...@list.sipfoundry.org
To: 'Matt White'
Cc: sipx-users@list.sipfoundry.org
Sent: Sat Aug 07 12:46:48 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
There is an analogy that wor
customer that they are getting prank
calls that they want to end. Geez.
From: sipx-users-boun...@list.sipfoundry.org
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Matt White
Sent: Saturday, August 07, 2010 8:11 AM
Cc: sipx-users@list.sipfoundry.org
Subject: Re: [sipx-users] Blocki
org
Sent: Sat Aug 07 11:10:53 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
I don't think any RFC changes are required at all. Invites are challenged
all the time.
Example,
Ext 345 sends invite to sipxproxy for ...@sip.com
sipxproxy responds "404
Right, which is why I wondered why more ITSP that send on port 5060 do not work
for inbound calls.
As a test, I just set my test vitelity.net account to not use registration and
forced it to use port 5060. Test call comes in and works has audio.
Transfer fails...which I assume is because they
//www.myitdepartment.net/gethelp/
- Original Message -
From: sipx-users-boun...@list.sipfoundry.org
Cc: sipx-users@list.sipfoundry.org
Sent: Sat Aug 07 10:04:02 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
Yeah, I knew that it would for remote workers by det
Sipxrelay anchors the media. Sipxbridge separates trunking from pure
sip and remote users and acts as a gateway out via carrier if the
proxy authorizes the call. Sipxproxy sends the call (or rejects it) if
there is validity to the invite to the user.
On 8/7/10, Matt White wrote:
> Yes, I could
undry.org
Sent: Sat Aug 07 10:04:02 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
Yeah, I knew that it would for remote workers by determine the SIPX-NONAT
status , I guess I didn't realize it would for non registered sip UA like an
inbound sip call.
Makes me
Yes, I could try and get the ip range from the itsp but I know they use
re-invited to select different upstream providers.
It would seem there should be a way to require authentication for the inbound
call. I dial plan in reverse.
I'm not saying to require authorization before the invite, I'
Yeah, I knew that it would for remote workers by determine the SIPX-NONAT
status , I guess I didn't realize it would for non registered sip UA like an
inbound sip call.
Makes me wonder how hard it would be to get SipXproxy to work with ITSP that
must send to port 5060 instead of port 5080. If
@list.sipfoundry.org
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
Yes, I was just surprised that the call had two way audio considering the
call was traversing a NAT and not going through sipxbridge which anchors the
media.
-M
>>> Tony Graziano 08/07/10 8:46 AM >>
Fax: 434.984.8427
Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/
- Original Message -
From: Tony Graziano
To: Matt White
Cc: sipx-users@list.sipfoundry.org
Sent: Sat Aug 07 08:36:47 2010
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
No. It&#x
Subject: Re: [sipx-users] Blocking SIP URI Calls from the innternet
No. It's a sip call. That's perfectly normal. ANY sip call from the Internet
to a user on the system would not be requiring permissions or even to pass
through a gateway. Only outgoing calls do that.
Probably a sipvicious v
No. It's a sip call. That's perfectly normal. ANY sip call from the Internet
to a user on the system would not be requiring permissions or even to pass
through a gateway. Only outgoing calls do that.
Probably a sipvicious variant. If your system is setup properly I'm not sure
I would worry. If you
I have a client that looks like its getting calls from Russia on port 5060. It
is not coming from the bridge.
The calls come in from various sources and seem to be sending invites to random
common extensions causing the phones to ring.
I would have expected the invite to be challenged as this
25 matches
Mail list logo
