Oops, never mind. Didn't realize you were talking about the double CR/LF
at the end of the headers. Thanks!
-----Original Message-----
From: Hearty, John
Sent: Monday, June 18, 2001 1:56 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: Wang, Jin-Gen
Subject: RE: [Sip-implementors] TCP support/fragmented messages
Eric,
Is there any concern of message bodies (other than SDP) containing a double
CR/LF?
John
-----Original Message-----
From: Eric Tremblay [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 1:37 PM
To: Hearty, John; [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] TCP support/fragmented messages
John,
Just accumulate the bytes until you find the double CRLF that terminates a
SIP packet, you can then parse it. Find the content length and get the
content.
You cannot find a double CRLF anywhere within a SIP packet except at the end
of it, so there are no problems.
Cheers!
EricT
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 18, 2001 15:07
To: [EMAIL PROTECTED]
Subject: [Sip-implementors] TCP support/fragmented messages
I'm sending an issue on behalf of developers I work with. I am not
particularly strong in the area of transport protocols or the challenges of
coding so please bear with me. We have begun implementing TCP support in a
proxy. We have found that, while it is possible to implement the proxy to
handle the possibility of a SIP message being divided between transmissions,
the coding can get messy. It becomes particularly difficult when a SIP
header is divided between two transmissions. It seems we have to parse
individual SIP headers as they are read off the socket to determine if more
data is yet to come to complete the message. This is not an issue on UDP as
we are guaranteed exactly one SIP message in a UDP datagram to cover the
reliability mechanisms built into SIP.
The opinion of our developers is that things would be much cleaner if SIP
had a length parameter. This of course is something that should probabally
be discussed on the SIP list rather than here, but we wanted to get opinions
from others who have implemented TCP in proxies. There may be other
considerations we have not thought of. It seems to me that adding a length
would be a big change to SIP which may create all kinds of compatibility
issues, so I wanted to hear more opinions before bringing it to the SIP
list. Below are comment excerpts directly from one of our developers:
It seems like to me that [vendor X] fragmenting their own packets to 512
byte segments is an attempt to keep TCP from bundling multiple messages
together. This doesn't make sense because TCP can keep small messages
bundled up until it is ready to transmit (so I see 0 value in them doing
their own fragmenting). More importantly I'm concerned over comments that
the SIP over TCP implementation does not include any sort of header beyond
the normal SIP stuff. Think about it like this... UDP is a datagram
protocol. One datagram = 1 message. TCP is not. It is a streaming
protocol meaning that TCP doesn't respect message boundaries. When I read a
UDP socket, I will either block until exactly 1 datagram is received if i am
in blocking mode or continue reading while UDP tells me that not all of the
datagram has been delivered (EWOULDBLOCK) if I am in non-blocking mode. TCP
doesn't do this. TCP will tell me that I have 100 bytes waiting, but that
100 bytes can be part of 1 message or contain 50 messages. Generally, most
messaging protocols include a message length in an application level header
so that you know where the message boundaries are. Delimiters works also,
but are not precise (since the delimiter may show up as data in the
message). It seems to me that SIP over TCP does not take into account the
fundamental differences between TCP and UDP and would be concerned that any
solution that requires an application to do their own fragmenting without
including the normal fragmentation information.. or based on assumptions on
how a given TCP implementation will behave is at best kludgy, and at worst,
will have problems.
John Hearty
Level 3 Communications, Inc.
Dept: Systems Integration & Test
Email: [EMAIL PROTECTED]
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
