7 Feb
2017
7 Feb
'17
9:40 a.m.
Hello,
with TCP there is no MTU. In the previous pcap you sent there was a
wrong Content-Length value. Was that fixed?
Cheers,
Daniel
On 06/02/2017 12:24, Hai Bui Duc Ha wrote:
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(a)htklabs.com
<mailto:hai.bui@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(a)gmail.com <mailto:miconda@gmail.com>> wrote:
On 19/01/2017 22:56, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
Hello,
On 19/01/2017 10:48, Hai Bui Duc Ha wrote:
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 <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
<http://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 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.