Hi Robert, (I will comment the minors in a separate reply)
------ >Major: >maj-1) Do we have a constituency willing to finish this work? It has a ways to go and the number of commenters has been >pretty small. Does anyone know of any attempts to implement this yet? I am aware of plans to implement it. ------ >maj-2) -02 is an improvement over -00, but the basic architectural intent is still not clear (as evidenced by the >remaining open issue in section 5 - in fact I think this is the _REAL_ open issue that the thing in section 5 is >pointing to). An implementer would probably benefit from a short overview section that outlined the mechanics. I agree that it currently is THE open issue. One proposal, based on input from Bret (see separate thread) would be to say the following: "A UAS must send 199 if it establishes more than one early dialog, and a UAS may send 199 if it establishes a single dialog." That way I don't think we need to distinguish between endpoint UASs and B2BUAs. I've also mailed to other alternatives to the list, which I intended to present at the meeting. ------ >maj-3) The document defines an option tag but doesn't say what it means if it shows up in a Require: header. I think we could say that it means that the UAS must support 199. Whether it then actually sends 199 depends on whether it fulfils the UAS criteria for sending 199 (see maj-2). ------ >maj-4) The Security Considerations section is empty. I've pointed already (in my comments to -00) of at least one >situation we need to discuss here (It said "For instance, I can spoof 199s to affect how a call is ultimately answered >in ways that are different (from the endpoints visibility into what happened point-of-view) from cancels/ byes or even >other response manipulation.) We need some focused discussion to uncover any other issues this new behavior is bringing >to the system. I will initiate a separate thread for this. ------ >maj-5) (I waffled on putting this into minor, but I've made this comment before and it hasn't been sufficiently >addressed). The document needs to be more explicit in explaining how it might be that a single 3-6xx response showing up >at a proxy might cause it to send more than one 199. Something like http://www.nostrum.com/~rjsparks/example.png >perhaps. I will take a second look at that. ------ >maj-6) The document should discuss what a proxy should do if a 199 shows up for an early dialog it's already generated >its own 199 about. >(This might happen, for instance, if a 3-6xx and a 199 crossed on the wire or were reordered by previous elements on the >way to this proxy). If the 199 is sent reliably I guess the proxy could forward it, in order to the UAC to PRACK it. If the 199 is sent unreliably I guess the proxy could discard it, or forward it. But, I need to think about this a little more. ----- >maj-7) Section 7 on backwards compatibility is really confusing and doesn't stand up against some edge situations. In >particular, it doesn't act right when a request comes in that's a retransmission or a merge. It could also be >misinterpreted (a stretch, but I've seen this >stretch) to constrain UASes to send a 481 to an ACK. I suggest we get together in the hall at IETF73 and collaboratively >wordsmith a replacement for this section. I guess we never got a chance to discuss this, but I think I understand your point. I guess I could modify the text, and simply say that a UAS which receives a request after it has sent 199 shall act in the same way as if it had received the request after sending the final non-2xx response to the INVITE, as specified in RFC3216. "If such request is received by a UA, it MUST reply to such requests with a 481 final response." ...is replaced with: "If such request is received by a UA, it shall act in the same way as if it had received the request after sending the final non-2xx response to the INVITE, as specified in RFC3261." ----- >maj-8) What is the purpose of section 8? I suspect it should just be deleted. I took it from another draft (don't remember which) that defines a new response code. ----- >maj-9) Section 9 allows a 199 to contain SDP. Why? This document should either forbid that practice or explicitly >document why it is allowed. I am fine with disallowing it completely. ----- >Nit: >nit-1) "resrouces" occurs several times in section 4.1 > >nit-2) The document still contains [ref needed] when talking about ICE in section 4.1 > >nit-3) The Note in section 4.1 has a reference to RFC3261 ostensibly about SRTP. Did it mean to point to an SRTP >document instead? > >nit-4) "intial" appears in section 5 > >nit-5) Suggest replacing "triggers a 199 response" in section 10 with "generates a 199 response" I'll do the fixes in the next version of the draft. ----- Thank you very much for your comments! Regards, Christer _______________________________________________ Sip mailing list https://www.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
