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