[SR-Users] Kamailio parse failed message

[Hai Bui Duc Ha]

Hi Daniel,

Thank for your advice.
I will capture and analyze the call log on both client and kamailio to
check the packet size.

Regards,
Hai Bui


On Fri, Jan 20, 2017 at 3:38 PM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

>
>
> On 19/01/2017 22:56, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> On 19/01/2017 10:48, Hai Bui Duc Ha wrote:
>
> Hi Daniel,
>
> Thank you for reply.
>
> On Tue, Jan 17, 2017 at 6:05 PM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> apparently I missed the follow ups on this discussion, dragged in by
>> other topics on mailing list.
>>
> Can you get the pcap with all the traffic taken on kamailio server for the
>> call (from initial invite to the end of the call)?
>>
> I send you the pcap at enclosed file. You can see the packet *No.5 *, it
> missing SIP message body:
> *            Media Attribute (a): rtpmap:8 PCMA/8000*
> *            Media Attribute (a): rtpmap:101 telephone-event/8000*
> *            Media Attribute (a): fmtp:101 0-16*
>
>> I expect that content length is mismatching or there is a '\0' inside the
>> sdp.
>>
> Can you explain me more about this ?
>
> TCP is a stream protocol, meaning that the application (kamailio) need to
> read and parse to figure out the end of a SIP message. The state machine as
> per RFC requires the application to read and identify the Content-Length
> header, take its value, read until the end of headers is found (an empty
> line) and from there on read as much as the value of Content-Length to get
> the body and consider the end of message there.
>
> If the sending application puts a lower value in the Content-Length than
> the number of chars in the body, the rest remains in the buffer and the
> receiving application (kamailio) attempts to parse a new SIP message.
>
> The other thing I was thinking of was the presence of '\0' which marks the
> end of string in C.
>
> I will look at the pcap very soon and see what I find there.
>
> The problem is the value of Content-Lenght set by the client -- it is set
> only to the size that it is view as part of the invite. A bit later the
> client sends more sdp, but exceeding the size sent in C-L header. That part
> of SDP remains as garbage.
>
> So there is a bug in client app.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
>


-- 
Hai Bui
VoIP engineer, Cvoice team, HTK-HCM Office
Mobile: +84-165-618-9876
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170122/262c581f/attachment.html>