Section 7.5 RFC 3261 "The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports"
Section 18.3 "In the case of stream-oriented transports such as TCP, the Content- Length header field indicates the size of the body. The Content-Length header field MUST be used with stream oriented transports" So I guess you need to decode the message to find out the content length to determine the end of the message? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Wang Sent: Tuesday, February 07, 2006 7:15 AM To: 'Matthew Gardiner'; 'SIP Implementors' Subject: Re: [Sip-implementors] SIP over TCP implementation 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
