On Thu, Oct 2, 2014 at 10:18 AM, Olli Heiskanen
ohjelmistoarkkite...@gmail.com wrote:
Hi,
Thanks Eric for your reply, yes I know Asterisk replaces the sdp, however it
should create ice lines when calling to a webrtc client, which it is
currently not doing.
To recap my problem (check
On Wed, Oct 1, 2014 at 8:00 AM, Gabriel Ortiz Lour
ortiz.ad...@gmail.com wrote:
Hello,
A question on channel originating (call files and AMI Originate):
How can I change the CALLERID(num) var (because of the E1 provider needs),
but having another númber (the original one) stored on the
Hello,
I'm preparing a setup before installing it within the next few days.
In this setup, I'm using a SPA112 as an ATA for an analog phone.
The target phone is a Gigaset A400 DECT handset.
In my lab, I've got another A400 handset and an old Matracom 46 handset.
When I connect my Matracom 46
the attacking server changed the destination Number at 18:53 CEST and
he is still blocked ... LOL
972597438354 callto:00972597438354
Oct 3 18:53:17 server /sbin/kamailio[3977]: NOTICE: script: blocking IP 62.210.149.136
sipcli/v1.8 rm=INVITE aU=null rU=00972597438354
We set up our servers to allowguest=yes and autocreatepeer=yes and use a global
context setting to point any of those calls to an IVR jail.Attempts stop
reasonably quickly.
An empty room with an unlocked door is far less interesting than a room
with the door locked.
From:
On 3/10/14 6:52 pm, Rainer Piper wrote:
the attacking server changed the destination Number at 18:53 CEST and
he is still blocked ... LOL
972597438354 callto:00972597438354
It's pretty much an everyday occurrence for any internet-connected SIP
system these days...
Oct 3 19:46:20
Hi Eric
I like your approach.
I think about stateless redirect the bad boy to the NSA- or Pentagon-IVR
LOL
Am 03.10.2014 um 20:01 schrieb Eric Wieling:
We set up our servers to allowguest=yes and autocreatepeer=yes and use
a global context setting to point any of those calls to an IVR
Hi Chris,
yes ... it is boring ...
I stop posting ...
;-)
Am 03.10.2014 um 20:11 schrieb Chris Bagnall:
On 3/10/14 6:52 pm, Rainer Piper wrote:
the attacking server changed the destination Number at 18:53 CEST and
he is still blocked ... LOL
972597438354 callto:00972597438354
It's
just one more ;-)
the source IP just changed to
142.0.41.179
OrgName:VolumeDrive
OrgId: VOLUM-2
Address:1143 Northern Blvd
City: Clarks Summit
StateProv: PA
PostalCode: 18411
Country:US
and the destination Number to
972595632276
There are lots of ways to solve this, and NOT to solve this. Don't start
adding lots of rules to iptables (or deep per packet inspection requirements)
as this will hurt capacity...and it doesn't really solve the problem
Take a look at
http://www.voip-info.org/wiki/view/Asterisk+security
If
OK, been messing with Asterisk for a long time and I have my opinion on where
the issues lies but sometimes it's just nice to see what others think that can
relate :-)
Here goes..
Inbound calls flow like this:Tier 1 Provider (SIP) Asterisk 1.8 Name Brand
PBX - Calls work fine
Outbound calls
Asterisk does not need to care. Is it SIP all the way through?
Thanks,
Steve T
On Fri, Oct 3, 2014 at 3:12 PM, Todd R. tjrl...@live.com wrote:
OK, been messing with Asterisk for a long time and I have my opinion on
where the issues lies but sometimes it's just nice to see what others think
Any chance this is a simple directmedia and/or NAT issue?
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Steve Totaro
Sent: Friday, October 03, 2014 4:14 PM
To: tjrl...@live.com; Asterisk Users Mailing List - Non-Commercial Discussion
13 matches
Mail list logo
