On 3/11/13 10:30 AM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
that should be ok, I will push a patch soon, it
is related to the fact
the maxfwd header is added by presence module in this case.
after the patch,
notify from presence server works in 4.0. thanks.
looks like i was the only one that had tried presence in 4.0.
I have enabled
presence in my testbeds. This case was a bit more
special, not being a bug from sip point of view in the next hop.
So what happened was that the content length value was still ok (length
of body), so a parsers that obey it are fine. The actual problem was
that after the body, there was some garbage. From the logs, NOTIFY was
handled ok, the next part throw error. Because of tcp being a stream
oriented transfer, it is expected to be another SIP message, the error
being thrown by first line parser, not being able to match the patter of
the start of a new sip message:
ERROR:parse_first_line: method not followed by SP
INFO: <core> [parser/parse_fline.c:242]: ERROR:parse_first_line: bad message
For UDP case, the rest is just discarded without notice, because it is
not parsed at all, being being the message body limit in the frame. You
sent to another kamailio instance the notify, if it would have been sent
to end device, all should have been unnoticeable, as the NOTIFY requests
itself was ok.
Hope now is more clear. Definitely not really correct by writing more
than the sip message itself, but parsers should cope with that, because
devices can send garbage on tcp connections in between sip messages
(e.g., for keepalive purposes).
Cheers,
Daniel
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
-
http://conference.kamailio.com -