Speaking time restriction

ss7

Re: ss7

Hello Ricky,

Im trying setup the sigtran too, but i cant found good samples too.

If you found something please tell me.

Thanks

R.Medeiros

2011/1/1 Ricky Keele <ricky.keele@...>:
> I have setup the sigtran using the new 3.0 version but cannot get the
> transport to come up.
>
>
>
> I have seen some questions about this but am not finding any good examples
> for the issues concerning ss7 sigtran.
>
>
>
> Any help would be appreciated.
>
>
>
> Initializing module Signalling Channel
>
> <sig/isup.decode:INFO> ISUP Call Controller pointcode-type=ITU format=alaw
> plan/type/pres/screen=unknown/unknown/allowed/user-provided
> caller-category=ordinary remote-pointcode=1-1-1 priority+SSF=128
> lockcircuits= userpartavail=false lockgroup=true outboundsls=last
> [0x2aaaac0324a0]
>
> <sig/isup.encode:INFO> ISUP Call Controller pointcode-type=ITU format=alaw
> plan/type/pres/screen=unknown/unknown/allowed/user-provided
> caller-category=ordinary remote-pointcode=1-1-1 priority+SSF=128
> lockcircuits= userpartavail=false lockgroup=true outboundsls=last
> [0x2aaaac032b30]
>
> <local-linkset:NOTE> Point code types are '' [0x2aaaac0330c0]
>
> <local-linkset:ALL> Destinations: [0x2aaaac0330c0]
>
> ITU     0-0-1 0
>
> ITU     0-0-2 0
>
> <local-linkset:ALL> Attached link (0x2aaaac033630,'local-link') with SLS=0
> [0x2aaaac0330c0]
>
> <local-link:ALL> Attached L2 user (0x2aaaac0331c0,'local-linkset')
> [0x2aaaac033630]
>
> <Transport:ALL> Transport created (0x2aaaac033900)
>
> Segmentation fault
>
>
>
> Ricky

MGCP CA Config

Hello to alls,

Im trying to use the MGCP-CA for voice channels in a Cisco gateway,
but i just receive this message:

-----
<mgcp_ca:ALL> YMGCPEngine::processEvent(0x2e45c00,0x2e45450,(nil))
wrap=(nil) span=(nil) circ=(nil) [0x2e06240]
<mgcp_ca:INFO> RSIP 'forced' from 's1/ds1-1/* <at> 189.X.X.X'
<mgcp_ca:MILD> Unhandled 'RSIP' from 's1/ds1-1/* <at> 189.X.X.X'
<mgcp_ca:INFO> Sending message from 0.0.0.0:2727 to 189.X.X.X:2427
-----
507 2159 Unsupported Functionality

I try manies times of config, but all dont works and receive this
error, someone have a mgcpca.conf that work correctly?

Im using the Yate 3

my mgcpca.conf :
==============
[general]
; priority: int: Priority of the chan.rtp message handler
;priority=80

[engine]
; enabled: bool: Enable the MGCP engine
enabled=yes

request_ack=no
send_provisional=no

[endpoint]
user=yate

[gw cisco1]
user=s1/d1-*
host=189.X.X.X
chans=30
range=1-31
voicechans=1-15.17-31
port=2427
offset=1
address=189.X.X.X

Thank to all for the help

R.Medeiros

Remote DOS by REGISTER Flood - how to protect?

Re: Remote DOS by REGISTER Flood - how to protect?

Hello

same here. It has became a nightmare. The tool is "friendly-scanner"
and people have started to use it on  a large scale.

perhaps its possible to set some trigger which would initiate yate
message, so it can be intercepted by external modules, and then passed
to iptables or whatever

regards
orama

2011/1/4 Mateusz Bartczak <netcentrica@...>:
> Hello
>
> I've discovered that some kind of bot is DOS'ing my server by performing a
> flood of REGISTER requests to Yate. It sends a lot of requests in short
> time. Yate eats 100% of one CPU core and becomes unresponsive to normally
> registered clients.
>
> How to protect against this kind of attack? Is there any possibility to
> limit number of REGISTER requests sent in given amount of time from single
> IP address?
>
> Regards,
> Mateusz
>
>

Re: Remote DOS by REGISTER Flood - how to protect?

We're tasting the same pain :(
> Hello
>
> same here. It has became a nightmare. The tool is "friendly-scanner"
> and people have started to use it on  a large scale.
>
> perhaps its possible to set some trigger which would initiate yate
> message, so it can be intercepted by external modules, and then passed
> to iptables or whatever
>
> regards
> orama
>
> 2011/1/4 Mateusz Bartczak <netcentrica@...>:
>   
>> Hello
>>
>> I've discovered that some kind of bot is DOS'ing my server by performing a
>> flood of REGISTER requests to Yate. It sends a lot of requests in short
>> time. Yate eats 100% of one CPU core and becomes unresponsive to normally
>> registered clients.
>>
>> How to protect against this kind of attack? Is there any possibility to
>> limit number of REGISTER requests sent in given amount of time from single
>> IP address?
>>
>> Regards,
>> Mateusz
>>
>>
>>     

Re: Remote DOS by REGISTER Flood - how to protect?

Same goes here. Some kind of joker that is trying and/or using the name
"ricardo" in the register message ... We cut the originating IP from the
firewall. Even so, it's using 300 kbps of our bandwidth.

On 1/4/11 12:12 PM, "Milan Rukavina" <milan@...> wrote:

> We're tasting the same pain :(
>> Hello
>> 
>> same here. It has became a nightmare. The tool is "friendly-scanner"
>> and people have started to use it on  a large scale.
>> 
>> perhaps its possible to set some trigger which would initiate yate
>> message, so it can be intercepted by external modules, and then passed
>> to iptables or whatever
>> 
>> regards
>> orama
>> 
>> 2011/1/4 Mateusz Bartczak <netcentrica@...>:
>>   
>>> Hello
>>> 
>>> I've discovered that some kind of bot is DOS'ing my server by performing a
>>> flood of REGISTER requests to Yate. It sends a lot of requests in short
>>> time. Yate eats 100% of one CPU core and becomes unresponsive to normally
>>> registered clients.
>>> 
>>> How to protect against this kind of attack? Is there any possibility to
>>> limit number of REGISTER requests sent in given amount of time from single
>>> IP address?
>>> 
>>> Regards,
>>> Mateusz
>>> 
>>> 
>>>     

--

-- 
Ionut Muntean

Re: Remote DOS by REGISTER Flood - how to protect?

On 04/01/11 10:10, Orama Avis wrote:
> same here. It has became a nightmare. The tool is "friendly-scanner"
> and people have started to use it on  a large scale.

You can try using this:
http://blog.sipvicious.org/2010/06/how-to-crash-sipvicious-introducing.html

If they're using an old version, you can crash it rather easily.
Otherwise, just write a (ngrep 'friendly-scanner' udp and port 5060 -->
get ip --> iptables -A -s ... -j DROP) - however that won't actually
stop the attack - it's still going to take your bandwidth.

To be honest, I've been pretty lucky with abuse reports lately - you can
cut people off rather quickly.

Regards,
Stan

GNU Gatekeeper release 2.3.4

Hi all,

the GNU Gatekeeper version 2.3.4 has been released.
http://www.gnugk.org/gnugk-2-3-4.html

This is mainly a bugfix release for proxy mode selection, H.460.18/.19
and bandwidth management.

Regards,
Jan

-- 
Jan Willamowius, Founder of the GNU Gatekeeper Project
EMail  : jan@...
Website: http://www.gnugk.org
Support: http://www.willamowius.de/gnugk-support.html

Changes from 2.3.3 to 2.3.4
===========================
- BUGFIX(Toolkit.cxx) fix handling of ModeSelection rules (sponsored by Charite, Berlin)
- BUGFIX(RasSrv.cxx) fix handling of BRQs reducing the bandwidth
- BUGFIX(ProxyChannel.cxx) fix H.239 from H.460.19 client (sponsored by Nanjing Southern Telecom)
- BUGFIX(ProxyChannel.cxx) fix H.245 IP in H.460.18 call
- BUGFIX(ProxyChannel.cxx) sourceCallSignalAddr rewrite and RemoveH235Call= were ignored
  when calling endpoint who uses H.460.18
- BUGFIX(gksql_mysql.cxx) set MySQL connect timeout to 10 seconds (was 10000 seconds)
- BUGFIX(RasTbl.cxx) add NULL pointer checks when searching for endpoints
- BUGFIX(yasocket.cxx) fix crash on Windows service shutdown
- BUGFIX rewrite memory mangement for routeToAlias
- BUGFIX(RasSrv.cxx) allow calls with zero bandwidth
- BUGFIX(ProxyChannel.cxx) fix crash when call being retried is deleted by another thread
- BUGFIX(ProxyChannel.cxx) fix crash in RTCP handling
- new switch: [Proxy]EnableRTCPStats=, must be enabled to send RTCP stats to Radius server
- new switch: [EP::...]AdditionalDestinationAlias=
- new switch: [RoutedMode]AlwaysRewriteSourceCallSignalAddress=, defaults to 2.3.2 behavior
- convert 2nd CallProceeding even if the first was sent through the status port