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