Hello Ovidiu,
Thanks for the fix. In regards to the pings from eyeBeam - how do you
want to reply to some dummy packages you do not understand ?
Best regards
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/30/2013 01:28 AM, Ovidiu Sas wrote:
I
The eyeBeam dummy packet is not that dummy.
It's a 4 byte packet: CRLFCRLF.
This is just like the TCP ping packet.
We could reply with CRLF, as Saul suggested.
See SIP outbound :http://tools.ietf.org/html/rfc5626#section-3.5.1
-ovidiu
On Wed, Oct 30, 2013 at 7:07 AM, Bogdan-Andrei Iancu
I see here:
This approach can only be used with connection-oriented transports
such as TCP or SCTP
So, maybe the package is not dummy, but it is wrongly used (over UDP) :)
Of course, technically can be done (to answer); the question is if it
make sense and if it is sane.
Regards,
That was my observation too (in one of my previous replies to Saul).
The thing is, if we reply to it, we can make the client's firewall
happy and we no longer need to perform server keep-alives.
I have mixed feelings about it :)
-ovidiu
On Wed, Oct 30, 2013 at 12:12 PM, Bogdan-Andrei Iancu
I also have mixed feelings on thisQuestion : is the practice of
using CRLF pinging via UDP a used one across UACs ?? or you just came
across a corner/isolated case ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/30/2013 06:18 PM, Ovidiu
I came across this one by accident while dealing with STUN packets.
The thing is that those CRLFCRLF packets are discarded silently and
therefor is difficult to evaluate how often are they used.
-ovidiu
On Wed, Oct 30, 2013 at 1:18 PM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
I also have
I checked the code before my initial post and I wasn't sure if the 20
was the length of the whole UDP packet or just the payload.
It turns out that it is the payload and those packets from eyeBeam
were indeed discarded.
The trouble packets were in fact sent by a Grandstream device and
those were
Hi guys,
The UDP stack in OpenSIPS silently discards any packages less than 20
bytes. See the MIN_UDP_PACKET in config.h .
Are your pings longer than 20 ?!?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/19/2013 02:47 AM, Saúl Ibarra
On Oct 16, 2013, at 12:22 PM, Ovidiu Sas o...@voipembedded.com wrote:
eyeBeam (release 1105z stamp 59030) is sending small packets to keep
the NAP pinhole open.
Those packets are short (4 bytes) with the following content: 0d0a0d0a.
In the logs, we have:
INFO:core:parse_first_line: empty
I forgot to mention in my previous e-mail that those ping packets are
over UDP, which seems like a bug in eyeBeam.
Anyway, the end result is that opensips logs are polluted.
Over TCP, it seems that those packets are properly handled by opensips.
It's UDP that is having issues.
Regards,
Ovidiu Sas
On Oct 18, 2013, at 11:14 AM, Ovidiu Sas o...@voipembedded.com wrote:
I forgot to mention in my previous e-mail that those ping packets are
over UDP, which seems like a bug in eyeBeam.
Anyway, the end result is that opensips logs are polluted.
Over TCP, it seems that those packets are
eyeBeam (release 1105z stamp 59030) is sending small packets to keep
the NAP pinhole open.
Those packets are short (4 bytes) with the following content: 0d0a0d0a.
In the logs, we have:
INFO:core:parse_first_line: empty or bad first line
INFO:core:parse_first_line: bad message
12 matches
Mail list logo
