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> 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> 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> 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
server.pcap
Description: Binary data
client.pcapng
Description: Binary data
_______________________________________________ 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
