Alexei | 1 Jan 18:28 2011

Speaking time restriction

Hi!
I have voip provider that gives 60 min of speaking every day for free. I want using it as gateway up to 60 min per day. If this limit exceeded the call should be routed thru another gateway. Is it possible to restrict daily speaking for a provider?

Alexei.

Ricky Keele | 1 Jan 20:58 2011

ss7

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

Romeu Medeiros | 1 Jan 22:35 2011
Picon

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

Romeu Medeiros | 2 Jan 05:01 2011
Picon

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

Mateusz Bartczak | 4 Jan 10:20 2011
Picon

Remote DOS by REGISTER Flood - how to protect?

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


Orama Avis | 4 Jan 11:10 2011
Picon

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
>
>

Milan Rukavina | 4 Jan 11:12 2011

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
>>
>>
>>     

Ionut Muntean | 4 Jan 11:20 2011
Picon

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

Stanisław Pitucha | 4 Jan 11:31 2011
Picon

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

Jan Willamowius | 4 Jan 16:17 2011
Picon

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


Gmane