Rockson, Thanks for the clarification! Now it is more clear: 1. For outgoing long SIP message, the transport layer of SIP Stack just chooses the TCP as the transport protocol and the TCP is responsible for the fragmentation of this long SIP message. But the SIP transport layer has no capability to divide the SIP message to several packets. 2. For incoming long SIP message, the transport layer of SIP Stack just gets the packets from TCP and once the Content-Length is greater than the actual packets, it is saying that there are still other packets belonging to this SIP message in the incoming buffers or even on the wireline way.
Please correct me if any misunderstanding on this kind of behaviors. Thanks, Alex Zhang ESN: 6-554-8782 -----Original Message----- From: Rockson Li (zhengyli) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 6:11 PM To: Alex Zhang (GDNTRND); [EMAIL PROTECTED] Cc: [email protected] Subject: RE: [Sip-implementors] SDP Content length Alex, FRAGMENTATION is IP layer stuff. I think you just want to talk about "framing" ,which is how to identify one SIP msg from another. On receipt of a packet or notification of packet is ready, When udp, you just get the all data from socket into a buffer and action as per sec 18.3 Framing When tcp, you read into an array of data from socket, feeding into the buffer is responsibility of tcp, but identifing which part of them is a SIP is msg is SIP transport stack's responsibility. So Content-Length here plays significant role to identify a SIP msg, as you said, if "if Content length is greater than the actual packet received, you have to wait,", it maybe in next packet, or it might be Ready in system socket queue, another or serveral read(s) should be OK. Regards, -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 5:55 PM To: [EMAIL PROTECTED]; Rockson Li (zhengyli) Cc: [email protected] Subject: RE: [Sip-implementors] SDP Content length Dinesh and Rockson, After thinking again, I should correct the previous understanding about the fragmenation and now I think Dinesh's thoughts are reasonable. :) Actually, even the transport layer of the SIP stack does not take the responsibility of the FRAGMENTATION. It just gets the content-length value, and decide that which Trasport Protocols is suitable for the real transportation. That is, if the body is too large, the transport layer of the SIP Stack will choose the TCP as the Transport Protocols and then the TCP will be responsibile for the packets fragementation. But this will bring the confusions on Benjamin's statement: "If Content length is greater than the actual packet received, you have to wait, as the rest of the SDP could be in the next packet." Please clarify me, if you have more clear ideas about it. Thanks, Alex Zhang ESN: 6-554-8782 -----Original Message----- From: Dinesh Mude [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 5:07 PM To: Alex Zhang (GDNTRND); [EMAIL PROTECTED] Subject: RE: [Sip-implementors] SDP Content length So Transport layer of SIP stack will take care of this.! Thanks for your response. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 2:16 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] SDP Content length Yes, you are right, there is a transport layer in the SIP spec, but I assume that Dinesh is asking that why not the TCP fragemenation is not used to framing the SDP content. Anyway, the transport layer of the SIP spec which is the application layer of the TCP/UDP/SCTP, has the info about the content-length and does have the responsibility as you say. Alex Zhang ESN: 6-554-8782 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rockson Li (zhengyli) Sent: Tuesday, July 01, 2008 4:20 PM To: [email protected] Subject: Re: [Sip-implementors] SDP Content length Actually, sec RFC3261 for details 18.3 Framing In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet. 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. Regards, -Rockson -----Original Message----- From: Rockson Li (zhengyli) Sent: Tuesday, July 01, 2008 4:10 PM To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] SDP Content length Alex, Yes, TCP does have no knowledge of content in upper layer. But we are talking about transport layer of SIP spec, which is part of app layer of TCP/IP stack. I think it should be transport layer of SIP spec's responsibility to reassemble the SIP msg and pass them to upper layer. Regards, -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 01, 2008 2:56 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] SDP Content length I think the framentaion/de-fragmentation is for the SDP content which can not be handled by the transport layer but the applcation layer. The TCP actually has no any knowledge on the application layer content. Alex Zhang ESN: 6-554-8782 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dinesh Mude Sent: Tuesday, July 01, 2008 2:50 PM To: [email protected] Subject: Re: [Sip-implementors] SDP Content length I have one question on the same topic. If transport is TCP, Why application layer needs to support message fragmentation and de-fragmentation with SIP header "Content Length:". Why not Transport layer will re-assemble all the fragmented packets and send it to higher layer ? Thanks, Dinesh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin Jacob Sent: Tuesday, July 01, 2008 11:57 AM To: [email protected] Cc: Arun Subject: Re: [Sip-implementors] SDP Content length To rephrase a confused line : 1. If UDP, if incorrect SDP length received(greater or less than advertised in the Content length) or invalid Content length, respond with an error. ----- Original Message ---- From: Benjamin Jacob <[EMAIL PROTECTED]> To: [email protected] Cc: Arun <[EMAIL PROTECTED]> Sent: Tuesday, July 1, 2008 11:53:27 AM Subject: Re: [Sip-implementors] SDP Content length >From the various torture tests drafts/ RFCs: 1. If UDP, if incorrect/invalid(-ve for e.g.) length (greater or less than advertised in the Content length) , respond with an error. 2. If TCP : a. If Content length is greater than the actual packet received, you have to wait, as the rest of the SDP could be in the next packet. b. If Content length is less than the actual packet received, respond with an error. c. If invalid Content length, respond with an error. - Benjamin Jacob. ----- Original Message ---- From: Arun <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, July 1, 2008 10:54:58 AM Subject: [Sip-implementors] SDP Content length Hi all, I have a problem here with the SDP content length. Wat if the content length is less than or greater than the actual sdp packet. Should that packet be processed properly or it is to be discarded. Is it a malformed packet if content length is greater or less than the length of the SDP packet. _______________________________________________ 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 Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
