[SR-Users] Kamailio parse failed message

[Hai Bui Duc Ha]

Hi Daniel,

I send you the pcap files on both client and server side.
Analyse this files, I see the packet can not "reassemble"  INVITE message
at server side:
- At client.pcapng, it can detect 6 and 7th packets are one.
- But on server.pcap, it can not "reassemble" 18 and 21st packets.

I just explain as my understand. If you have any information, please ask me.
I think the problem relate the MTU - fragmentation. But I'm not sure about
this.
Thank you for support !

Regards,
Hai Bui

On Sun, Jan 22, 2017 at 4:33 PM, Hai Bui Duc Ha <hai.bui at htklabs.com> wrote:

> 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
>



-- 
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/20170206/0f49d22d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.pcap
Type: application/octet-stream
Size: 12361 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170206/0f49d22d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.pcapng
Type: application/octet-stream
Size: 7248 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170206/0f49d22d/attachment-0001.obj>