Hi Daniel!
just additional info about the nature of that "extra zero".
Vendor use them as a padding bytes
RFC http://www.ietf.org/rfc/rfc0894.txt says:
"If necessary, the data field should be padded
(with octets of zero) to meet the Ethernet minimum frame size. This
padding is not part of
Hello,
update on this -- I pushed last evening to master a slightly different
patch, to skip other white space characters before the method is started
to be parsed.
Not having much time, I didn't dig further in the code, but the position
of the patch suggests that these leading whitespaces are st
Hello,
good it was caught. I think it is good/safe to skip the '\0' together
with the white spaces at the beginning for the request. I will analyze
the impact and push the patch for it.
Cheers,
Daniel
On 09/12/15 12:05, Vasiliy Ganchev wrote:
> Hi Daniel!
>
> Thank you for the suggestion, after
Hi Daniel!
Thank you for the suggestion, after the deep investigation, looks like the
root of the problem found:
when device send TCP ACK (before INVITE), in this packet is incapsulated
"VSS-Monitoring ethernet trailer, Source Port: 0", example in file in
attachment.
Looks like kamailio parse it
Hello,
can you change the sources and replace:
DBG(" method: <%.*s>\n",fl->u.request.method.len,
ZSW(fl->u.request.method.s));
with:
DBG(" method: <%.*s> (%d)\n",fl->u.request.method.len,
ZSW(fl->u.request.method.s), fl->u.request.method
Hi folk!
Have a strange issue, and cannot understand what is wrong.
Test scheme UA(sip) -> INVITE -> Kamailio
The transport protocol used is TCP.
The issue is reproduced randomly, in case of wrong INVITE, Kamailio does not
parse Method from R-URI and answer "400 CSeq method does not match request
