[rohc] Making SigComp recognizable
"Dr. Carsten Bormann" <cabo@tzi.org> Tue, 26 February 2002 01:35 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05689
for <rohc-archive@odin.ietf.org>; Mon, 25 Feb 2002 20:35:34 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29680;
Mon, 25 Feb 2002 20:29:44 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176])
by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29632
for <rohc@optimus.ietf.org>; Mon, 25 Feb 2002 20:29:36 -0500 (EST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de
[134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05554
for <rohc@ietf.org>; Mon, 25 Feb 2002 20:29:09 -0500 (EST)
Received: from cabo3 (nmh.informatik.uni-bremen.de [134.102.224.3])
by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id g1Q1T4C10691
for <rohc@ietf.org>; Tue, 26 Feb 2002 02:29:04 +0100 (MET)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <rohc@ietf.org>
Subject: [rohc] Making SigComp recognizable
Date: Tue, 26 Feb 2002 02:29:03 +0100
Message-ID: <NFBBJFHGMCFINEMHAMBGCEIBHHAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression <rohc.ietf.org>
X-BeenThere: rohc@ietf.org
Content-Transfer-Encoding: 7bit
In a phone conversation today, it occurred to us that it would be a good idea to make SigComp packets clearly distinguishable from uncompressed packets. For SIP, this is easy, as all methods and reply codes are ASCII, so setting the MSB in the first byte of all packets would suffice. However, it's probably a good idea not to trigger the link-layer RTP ROHC heuristics, which tend to look for 10xxxxxx in the first byte (RTP V=2) of UDP packets. More generally, I think we want to cater for general UTF-8-based signalling protocols. Looking at RFC2044, we have: UCS-4 range (hex.) UTF-8 octet sequence (binary) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx Now, since RFC2044 (October 1996), Unicode has been decided to stop at 0010 FFFF, so the code combinations 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx never can appear in real UTF-8. Leaping to a conclusion, it seems a SigComp/UDP packet should start with 11111xxx Sigcomp-04 uses 0xFF as an escape character, so xxx=111 should probably also be avoided. Alternatively, we could simply define a single byte distinguisher for UDP and start all TCP streams with the escape sequence (and not use the UDP distinguisher here). Any other things we should avoid? General comments on the whole approach? (I just wish UDP had a protocol field.) Gruesse, Carsten PS.: Anyone for defining an RFC2246 (TLS) CompressionMethod value for SigComp? Should be fun, and would save the 0xFFFFs. Can't even find an IANA registry for TLS, though. PPS.: RFC2817 section 1 (motivation) is interesting reading. Has anyone implemented that spec? Could be done for SIP, too. _______________________________________________ Rohc mailing list Rohc@ietf.org https://www1.ietf.org/mailman/listinfo/rohc
- [rohc] Making SigComp recognizable Dr. Carsten Bormann
- Re: [rohc] Making SigComp recognizable Allison Mankin
- Re: [rohc] Making SigComp recognizable Miguel A. Garcia
- RE: [rohc] Making SigComp recognizable Dr. Carsten Bormann
- Re: [rohc] Making SigComp recognizable Miguel A. Garcia