On 12/04/16 17:33, Marrold wrote:
> Hi,
>
> >>On 06/04/16 01:57, Marrold wrote:
> >> Hi Charles,
> >>
> >> I can confirm that t_any_timeout(), and t_branch_timeout() return true
> >> when these un-ACKd transactions occur.
>
> > by un-ACKed, do you mean they didn't receive any response or they did
Hi,
>>On 06/04/16 01:57, Marrold wrote:
>> Hi Charles,
>>
>> I can confirm that t_any_timeout(), and t_branch_timeout() return true
>> when these un-ACKd transactions occur.
> by un-ACKed, do you mean they didn't receive any response or they didn't
> receive the ACK following a response to an INV
On 10/04/16 21:57, Marrold wrote:
> I've been doing some experimentation with t_any_timeout()
> and t_branch_timeout(), and I've observed they return true if either
> the initial invite receives no response, or if the 200 OK is not
> acknowledged by the UAC.
>
> Is there any way of differentiatin
Hello
On 06/04/16 01:57, Marrold wrote:
> Hi Charles,
>
> I can confirm that t_any_timeout(), and t_branch_timeout() return true
> when these un-ACKd transactions occur.
by un-ACKed, do you mean they didn't receive any response or they didn't
receive the ACK following a response to an INVITE?
Ch
I've been doing some experimentation with t_any_timeout()
and t_branch_timeout(), and I've observed they return true if either the
initial invite receives no response, or if the 200 OK is not acknowledged
by the UAC.
Is there any way of differentiating between these scenarios?
Thanks
On Wed, Ap
Hi Charles,
I can confirm that t_any_timeout(), and t_branch_timeout() return true when
these un-ACKd transactions occur.
I just needed to make sure that I set a failure route, in my reply route.
Thanks for the tip.
On Tue, Apr 5, 2016 at 1:56 PM, Charles Chance <
charles.cha...@sipcentric.com>
Hi,
You should probably check out TM docs - specifically failure route (
http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_on_failure)
and t_is_expired (
http://kamailio.org/docs/modules/stable/modules/tm.html#tm.f.t_is_expired).
>From there you can do what you like.
Cheers,
Charle
I am interested in 'fingerprinting' various SIP scanner attacks and using
them to intelligently block attacks, rather than just blindly black listing
any SIP message to a honey pot.
Additionally I think it would be wise to detect these missing ACKs and/or
incomplete transactions from a legitimatel
On Tue, Apr 05, 2016 at 12:09:29AM +0100, Marrold wrote:
> I have been running a couple of Asterisk honey pots to get a better
> understanding of the tools and methods potential hackers are using to
> exploit SIP servers.
>
> I have observed many attacks from the 'sipcli' user agent that don't sen
Thanks for the speedy response as always.
The current scenarios are taken from Asterisk only, Kamailio is not yet in
front of it - so no record route headers.
I imagine the ACKs aren't being sent due to it being a waste of resources
as you suggest, but I'm interested in detecting these in Kamaili
I am assuming you're adding Record-Route to your initial INVITEs?
If so, in the case of the answered call, it might be a defective UA that
doesn't follow Record-Route for in-dialog messages (which include e2e ACK).
In the case of the negative replies, a scanner might not waste
additional reso
Hi,
I have been running a couple of Asterisk honey pots to get a better
understanding of the tools and methods potential hackers are using to
exploit SIP servers.
I have observed many attacks from the 'sipcli' user agent that don't send
ACKs.
At this stage I'm not sure what they're trying to ach
12 matches
Mail list logo
