> > Rocky, > > You have to parse enough of the message to find the content-length > header. You can use whatever tricks you like to find it. Then > parse just > that header to get the lenght and use that to pull the body off the > socket. You can do the rest of the parsing later. > > Is it a pain? Yes. Such is life. > > Paul >
Yes, it is a pain. And yes, sometimes pain is a fact of life. But it still is a shame that it was _made_ a pain when it was easy to avoid by using something trivial like TPKT. (For those that don't understand the reason for the whining, there are devices where the module doing TCP/socket operations isn't the same module that does SIP parsing.) Ah well - such is life ;-( Cheers, Shaun Bharrat Sonus Networks www.sonusnet.com > Rocky Wang wrote: > > But before decoding, you will not know where is the > Content-Length and > > its value. > > Based on double CRLF, we can know that the message header > is finished > > but where is the end of the whole message? > > > > > > -----Original Message----- > > From: Matthew Gardiner [mailto:[EMAIL PROTECTED] > > Sent: 2006年2月6日 16:47 > > To: 'Rocky Wang'; 'SIP Implementors' > > Subject: RE: [Sip-implementors] SIP over TCP implementation > > > > > > I believe that SIP messages are terminated by 2 line-ends, > whereas SIP > > messages carrying one or more message bodies indicate the length of > > their attached cargo by means of the Content-Length header. > > > > These facts are adequate for receive logic to determine the end of a > > message. > > > > Matt > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf > Of Rocky Wang > > > > Sent: 06 February 2006 07:05 > > To: 'SIP Implementors' > > Subject: [Sip-implementors] SIP over TCP implementation > > > > > > Hi, > > I have one question with respect to SIP over TCP > implementation. > > Because the TCP connectsion provides stream service, after > gets some > > bytes from the stream, how a SIP node knows when a SIP messages is > > finished receiving, or more fragments are still in the data stream? > > The receiver must try to do the decode the received > fragments as > > supposing the SIP message is completed. If decoding failed, > then wait > > for more bytes from the stream and do a next decoding again. If the > > receiver must do the docode again and again, it will cost a > lot of CPU > > time slot, I think. Do you have any good idea to improve or > resolve the > > problem. > > > > Best Regards, > > Rocky Wang > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
