Subject: [Sip] issues on TCP support and Record-Route

From: [email-masked]
Date: Fri, 24 Aug 2001 17:04:49 -0600

I am sorry if these issues have been discussed before. I have two issues
concerning carrier grade SIP applications.

(1) When using a stream based transport protocol, e.g., TCP, SIP poses
several problems because SIP messages don't carry total length in a fixed
position, e.g., the first 4 bytes of the messages:

(a) Although the messages can be parsed in normal conditions, our tests
showed that the performance of using current SIP spec is several times
slower than carrying a total length in front of SIP messages.

(b) There is no robust way to handle malformed messages coming from TCP
without a total length in a fixed position. For example, a message doesn't
have a correct end of message headers.

So what is the reason that SIP doesn't specify a total message length in a
fixed position. I propose to carry a total length of each message in the
first 4 bytes for stream-based transport protocol.

(2) The Record-Route header has been overloaded to be used by subsequent
requests in both directions. This causes problems when one side of proxy
uses TCP and the other side uses UDP, although bis-4 does allow Record-Route
header to carry "transport=value" parameter. Some people have suggested to
rewrite the Record-Route header for final responses. This suggestion posts
performance overhead for all final responses. I propose to use different
names when specify transport protocol parameters, e.g., transport_in =
TCP;transport_out=UDP.

Thank you in advance for your comments and suggestions.

Jin-Gen Wang
Level 3 Communications

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Kim Liu <[email-masked]>
Date: Mon, 27 Aug 2001 08:33:35 -0400

> first 4 bytes for stream-based transport protocol.

Well, I agree with you whole-heartedly, but you won't be able to get
this idea to fly with the current spec because it breaks too much.

If you mean four bytes of binary data for length, then it 
breaks the readable text only idea people have.  (i.e. 0x00 00 01 00 
for 256 bytes.)

To quote from the spec (bis-04, 10.18):
        The ability to omit Content-Length simplifies the creation
        of cgi-like scripts that dynamically generate responses.

That is for UDP datagrams.  Unfortunately, if you try to nail down
a fixed content length location at the beginning of the message
for TCP, you'll probably break the above for UDP.  So, everyone
must endure so that some can write simple scripts that don't have
to worry about content length.  :-)

Cheers,
Kim Liu
Senior Software Engineer
Lucent Technologies 
Clearwater, FL