Hi Adam,
I believe this comment has been adressed in outbound-11 section 4.4.1:
If sending over a SigComp [25] compressed data stream, the CRLF
keepalives are sent inside the compressed stream.
thanks,
-rohan
On Jul 19, 2007, at 4:15 PM, Adam Roach wrote:
With the move to CRLF for keepalive in outbound, the language
discussing STUN handling with SigComp in TCP is also gone. This
makes sense, since TCP no longer uses STUN.
However, there was no equivalent language added for how to handle
the CRLF keepalives in conjunction with SigComp.
As with the earlier STUN mechanism, you can't just send the CRLF
stuff down the TCP connection -- it needs to be wrapped in SigComp.
Of course, we could employ the same mechanism originally proposed
for STUN (the well-known shim), which would be the 13-byte SigComp
shim, plus 2 bytes (CRLF) or 4 bytes (double CRLF).
Alternately, we can shave this down a _little_ bit by using
bytecodes specifically designed to output just the CRLFs we need;
for a double-CRLF, it would look like:
at (128)
OUTPUT (crlf, 4)
JUMP(end)
:crlf byte(13,10,13,10)
:end
END-MESSAGE (0,0,0,0,0,0,0)
Which translates to the following 14 bytes: f8 00 b1 22 a0 86 04 16
06 0d 0a 0d 0a 23
(Yes, I realize this is 14 bytes instead of the 17 bytes you get
with the shim, so it might not be worth using custom code).
For a single CRLF, such code would end up looking like this:
at (64)
:crlf pad(2)
at (128)
LOAD (crlf, 3338)
OUTPUT (crlf, 2)
END-MESSAGE (0,0,0,0,0,0,0)
Which translates to the following 11 bytes: f8 00 81 0e 86 ad 0a 22
86 02 23.
In practice, we're probably best off just normatively saying that
the CRLF characters are sent inside SigComp, and that the mechanism
for representing them is a matter to be handled by the SigComp
compressor at the sending end. We can point out the shim, and we
can include the foregoing purpose-built SigComp messages, but there
may be architectural complications to using either of them, so the
ultimate requirement is simply to send something that produces
"CRLF" as its output when it is sent.
/a
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
