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....@htklabs.com > <mailto:hai....@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 > <mico...@gmail.com <mailto:mico...@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 >>> <mico...@gmail.com <mailto:mico...@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 <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 -- 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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
