20 Jan
2017
20 Jan
'17
12:56 a.m.
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(a)gmail.com <mailto:miconda@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.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com