[sr-dev] presence notify packet garbage with latest 4.0

Daniel-Constantin Mierla miconda at gmail.com
Mon Mar 11 10:46:20 CET 2013


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 -




More information about the sr-dev mailing list