Subject: RE: [Sip] Outbound and SigComp

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 3 Oct 2006 23:12:20 +0200

RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an
application protocol. Therefore in that document there is no indication
that SigComp is designed for SIP, or for some other protocol.

RFC 3486 (owned by SIP) specifies how SIP uses SigComp.

On that basis, I would have thought that any group that intended their
protocol to run over SigComp would need to define how it is used in
those circumstances, as for usage over any other transport protocol. 

In the absence of such a document, usage of SigComp by that protocol
would be essentially proprietary.

In summary therefore, I would suggest that as far as the RFCs are
currently concerned, STUN is outside of SigComp, because noone in the
STUN community has written a document to put it inside.

Views?

Regards

Keith

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 02 October 2006 21:46
> To: SIP; Rohan Mahy; Adam Roach
> Subject: [Sip] Outbound and SigComp
> 
> 
> A question I have been thinking about a little ... what 
> happens when a UA is doing both outbound and sigcomp. Is it 
> clear enough how this happiness? Is stun inside or outside 
> the sigcomp, etc? Anyways, I just wanted to lodge this as an 
> open issue  - we probably should check that this is 
> reasonable clear how to do this even if we don't have to say 
> anything about it in outbound.
> 
> 
> _______________________________________________
> Sip mailing list  https://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
> 

_______________________________________________
Sip mailing list  https://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

UrZE-0006Vk-OA
	for [email-masked]; Tue, 03 Oct 2006 17:12:46 -0400
Content-class: urn:content-classes:message
Subject: RE: [Sip] Outbound and SigComp
Date: Tue, 3 Oct 2006 23:12:20 +0200
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Cullen Jennings" <[email-masked]>, "SIP" <[email-masked]>,
	"Rohan Mahy" <[email-masked]>, "Adam Roach" <[email-masked]>
Cc: 

RFC 3320 (owned by ROHC) merely specifies a UDVM that can sit below an
application protocol. Therefore in that document there is no indication
that SigComp is designed for SIP, or for some other protocol.

RFC 3486 (owned by SIP) specifies how SIP uses SigComp.

On that basis, I would have thought that any group that intended their
protocol to run over SigComp would need to define how it is used in
those circumstances, as for usage over any other transport protocol. 

In the absence of such a document, usage of SigComp by that protocol
would be essentially proprietary.

In summary therefore, I would suggest that as far as the RFCs are
currently concerned, STUN is outside of SigComp, because noone in the
STUN community has written a document to put it inside.

Views?

Regards

Keith

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 02 October 2006 21:46
> To: SIP; Rohan Mahy; Adam Roach
> Subject: [Sip] Outbound and SigComp
> 
> 
> A question I have been thinking about a little ... what 
> happens when a UA is doing both outbound and sigcomp. Is it 
> clear enough how this happiness? Is stun inside or outside 
> the sigcomp, etc? Anyways, I just wanted to lodge this as an 
> open issue  - we probably should check that this is 
> reasonable clear how to do this even if we don't have to say 
> anything about it in outbound.
> 
> 
> _______________________________________________
> Sip mailing list  https://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
> 

_______________________________________________
Sip mailing list  https://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: <[email-masked]>
Date: Wed, 4 Oct 2006 10:02:02 +0300

Hi,

>STUN community has written a document to put it inside.

I agree with the approach Keith proposed since in my understanding
it would not make any sense to use SigComp for binary encoded STUN
while according to RFC 3320 SigComp is motivated by compressing text 
based protocols:

   Many application protocols used for multimedia communications are
   text-based and engineered for bandwidth rich links.  As a result the
   messages have not been optimized in terms of size. 

STUN messages are size-optimized and small, so you are not expected
to gain much, if anything, by applying SigComp to those.

However for the SIP Outbound case as both the SIP and STUN messages
must share the same source and destination IP address and port, the 
question is if multiplexing STUN messages with SigComp messages can 
be safely done. It seems to be possible by checking the two topmost
bits of the message which are always one for SigComp and zero for STUN:

   All SigComp messages contain a prefix (the five most-significant bits
   of the first byte are set to one) that does not occur in UTF-8
   encoded text messages [RFC-2279], so for applications which use this
   encoding (or ASCII encoding) it is possible to multiplex uncompressed
   application messages and SigComp messages on the same port.

   The most significant two bits of every STUN message are both zeroes.
   This, combined with the magic cookie and the fingerprint attribute,
   aid in differentiating STUN packets from other protocols when STUN is
   multiplexed with other protocols on the same port.

To document this for SIP Outbound deployments using SigComp (like IMS)
could a note be added to the Outbound draft about this ?

Regards,

Erkki

>From: ext Drage, Keith (Keith) [mailto:[email-masked]] 
>Sent: 04.October.2006 00:12
>To: Cullen Jennings; SIP; Rohan Mahy; Adam Roach

---

From: <[email-masked]>
Date: Mon, 16 Oct 2006 17:15:36 +0300

Hi,

It seems to me that the answer I provided to this question is
only valid when using UDP. However rohc wg suggests that when
using TCP, multiplexing of compressed and not compressed
messages should not be done for the same connection:

This is what the latest draft-ietf-rohc-sigcomp-sip-03.txt 
says for UDP:

   In order to limit the number of ports required by a SigComp-aware
   endpoint, it is possible to allow both SigComp messages and 'vanilla'
   SIP messages (i.e. uncompressed SIP messages with no SigComp header)
   to arrive on the same port.

   For a message-based transport such as UDP or SCTP, this can be done
   per message.  The receiving endpoint checks the first octet of the
   UDP/SCTP payload to determine whether the message has been compressed
   using SigComp.  If the MSBs of the octet are "11111" then the message
   is considered to be a SigComp message and is parsed as per [RFC3320].
   If the MSBs of the octet take any other value, then the message is
   assumed to be an uncompressed SIP message, and is passed directly to
   the application with no further effect on the SigComp layer.

And this is what it says for TCP:

   For a stream-based transport such as TCP, the distinction is per
   connection.  The receiving endpoint checks the first octet of the TCP
   data stream to determine whether the stream has been compressed using
   SigComp.  If the MSBs of the octet are "11111" then the stream is
   considered to contain SigComp messages and is parsed as per
   [RFC3320].  If the MSBs of the octet take any other value, then the
   stream is assumed to contain uncompressed SIP messages, and is passed
   directly to the application with no further effect on the SigComp
   layer.  Note that SigComp message delimiters MUST NOT be used if the
   stream contains uncompressed SIP messages.

   Applications MUST NOT mix SIP messages and SigComp messages on a
   single TCP connection.  If the TCP connection is used to carry
   SigComp messages then all messages sent over the connection MUST have
   a SigComp header and be delimited by the use of 0xFFFF as described
   in [RFC3320].

   Note: Appendix A shows how to send uncompressed messages in a SigComp
   structured TCP connection using a "well-known shim header".  Should
   it for any reason not be desirable to set up more than one TCP
   connection to a SIP implementation, but the flexibility to send both
   compressed and uncompressed SIP messages be required, the compressor
   can set up a SigComp structured connection and send any uncompressed
   SIP messages using the well-known shim header.

Appendix A.  Shim header for sending uncompressed messages

   This appendix presents bytecode that simply instructs the
   decompressor to output the entire message (effectively sending it
   uncompressed but within a SigComp message).

	.... bytecode omitted from this email ...

   As an implementation optimization, a SigComp implementation MAY
   compare the initial 13 bytes of each incoming message with the 13
   bytes given (the "well-known shim header"), and, in case of a match,
   simply copy the SigComp message data that follow the shim header
   without even setting up a UDVM.  (Note that, before a SigComp message
   is formed from the incoming TCP data, the record marking protocol
   defined in section 4.2.2 of [RFC3320] has to be performed.)

   To obtain the maximum benefit from this optimization, compressors
   SHOULD employ exactly the well-known shim header given (and none of
   the other conceivable byte code sequences for just copying input to
   output) to send uncompressed data in a SigComp channel.

Should this also apply to multiplexing STUN and SIP messages
to the same SIP Outbound TCP connection ? If yes it would add
13 bytes of overhead to every single STUN keepalive message that
the UA sends "compressed" to the SIP proxy.

Regards,

Erkki

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 04.October.2006 10:02
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]