Subject: Re: FW: [rohc] WG last-call for SIP/SigComp

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Oct 2006 13:51:29 +0300

Hi,

>> Unlike the earliear versions the new dfart modifies the SIP 
>> protocol itself. In my opinion, the -03 is such a modification to 
>> SIP that it should be processed by SIP WG according to the BCP 67.

as you may know, this draft has been discussed in SIP in the past, and
the SIP-related mechanisms have been discussed with SIP people.
Additionally, the SIP WG will perform an expert review on this draft.
The SIP chairs and the RAI ADs are all aware of this WGLC.

>> Also, the new draft breaks the backwards-compatibility with 
>> rfc3486-compliant implementations. It would be doubleplusgood if 
>> the breakage was indicated by rfc3486-compatible mechanisms, like 
>> comp=sigcomp1 SIP URI/Via header parameter. The new sigcomp-id 
>> parameters could replace the old ones, too.

No need to do that. Implementations compliant with this spec will use
the sigcomp-id parameter or a feature tag. Legacy implementations will not.

>> I doubt that resubmitting the draft as rfc3486-bis on SIP WG 
>> charter would impose much additional delay for this already way too
>> long delayed spec. For example, there is now a normative reference
>> to the still very much alive sip outbound draft in the spec.

The normative reference to outbound relates to the definition of
instance identifiers. That definition is not likely to change
significantly. In any case, that is why it is a normative reference;
because we need to keep an eye on it.

>> - how to map a large (>64 K or even smaller) SIP message to SigComp
>> messages

I'll leave this one to the other coauthors.

>> - ...and how to do that on SCTP

what do you have in mind? Are you thinking of hosts that share SCTP
state but not SigComp state?

>> - how to handle SIP-level retransmissions

I'll leave this one to the other coauthors.

>> - document could discuss using STUN or other protocols on a single 
>> connection/port in addition to SIP and SigComp

yes, we should discuss that. We will add such discussions to the draft.

>> - the brand new mechanisms for compartment handling, including ABNF
>> and examples in section 6 are contradictory, full of errors and
>> they are just plain confusing. I'll provide detailed proposals for
>> corrections later.

yes, send us your proposals.

>> - the example in section 10 does not address scenario where the
>> original UAC would become UAS (that is, the role of the server and
>> client would reverse)

the goal of the examples is to illustrate the use of the mechanisms, not
to provide an exhaustive list of scenarios where this mechanism could be
used. If you can think of an scenario that could be challenging for
implementers to understand for some reason, let us know and we will
include it in the examples.

>> - the example section should include a flow or flows with 1) 
>> outbound and 2) gruu and 3) a NAT between user-agent and its 
>> outbound proxy

same as above.

Thanks for your comments,

Gonzalo

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Adam Roach <[email-masked]>
Date: Tue, 31 Oct 2006 13:10:55 -0600

> I'll leave this one to the other coauthors.

SigComp explicitly doesn't support messages of 64k or larger. We can't 
really do anything about this without creating an rfc3320-bis draft.

That said, we should probably add text to the effect of, "if you're 
using a stream-based transport and need to send a message that is too 
large for the negotiated SigComp parameters, then create a new TCP 
connection and use it to send non-compressed messages."

> I'll leave this one to the other coauthors.

The proper behavior is actually pretty obvious. If you'd like to spell 
it out, the logic to use is: SIP retransmissions need to be sent through 
the SigComp compressor again. In other words, you don't retransmit the 
already-compressed information; you recompress the SIP message, and send 
the newly compressed message. The reason this behavior is necessary is 
because it is impossible to know whether the failure causing the 
retransmission occurred to the message being retransmitted or to the 
response to that message. If the loss occurred to the response, then any 
state changes effected by the first instance of the retransmitted 
message will already have taken place. If these state changes removed a 
state that the previously-transmitted message relied upon, then 
retransmission of the same compressed message will lead to a 
decompression failure.

> yes, we should discuss that. We will add such discussions to the draft.

Rohan has added these discussions to sip-outbound, which is where I 
think they belong. Duplicating the explanation is a waste of effort, and 
runs the risk of standardizing contradictory normative text.

/a