[SR-Users] Kamailio parse failed message

Daniel-Constantin Mierla miconda at gmail.com
Fri Jan 20 09:38:21 CET 2017



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 <mailto: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 Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170120/d6c32b73/attachment.html>


More information about the sr-users mailing list