1. "The UA can also include a reg-id parameter which is used to allow the registrar to detect and avoid keeping invalid contacts when a UA reboots or reconnects after its old connection has failed for some reason." Surely if outbound behaviour is required it is necessary to include reg-id. So it should say "The UA also includes...."
2. "When the proxy goes to forward a request to a given target, it looks and finds the flows over which it received the registration." In the case being described here in 3.2 there is only a single flow. Add ", in this case, only a single flow". 3. "The proxy then forwards the request on that flow, instead of resolving the Contact URI using the procedures in RFC 3263 [4] and trying to form a new flow to that contact. This allows the proxy to forward a request to a particular contact over the same flow that the UA used to register this AOR." This seems a bit circular. It effectively says that by forwarding on the existing flow it enables the proxy to forward on the existing flow! I think the second of these two sentences can be deleted. 4. "To convey its instance-id in both requests and responses, the UA includes a "sip.instance" media feature tag as a UA characteristic [7] ." The sending of instance-id in responses does not seem to be specified anywhere, so perhaps this sentence should only refer to requests. On the other hand, perhaps the intention is to send an instance-id in a contact in a response, as described for requests in 4.3. If so, a section on sending responses is required. 5. "These ordinary registration requests include a distinct reg-id parameter in the Contact header field." There is no RFC2119 language here. Shouldn't it say something like: "If outbound behavior is required, registration requests MUST include..." 6. "4.3. Sending Requests" I am not sure whether this section is intended to cover all requests (including REGISTER requests) or requests other than REGISTER. If the latter, the title should be "Sending Requests other than REGISTER". 7. "The contact is formed normally in that the UAC uses the IP address of the device (even if the device is behind a NAT)." This does not allow for the use of a GRUU in non-REGISTER requests. 8. "Note that the requirements in this section applies to both REGISTER requests received from an Edge Proxy as well as requests received directly from the UAC." I think this note is intended to refer only to the current paragraph, not the entire section. 9. "then the proxy MUST send the request over the same 'logical flow' saved with the binding that is known to deliver data to the specific target UA instance." It is the logical flow that is know to deliver data to the UA, not the binding. I think it should say: "then the proxy MUST send the request over the same 'logical flow' saved with the binding, since that flow is known to deliver data to the specific target UA instance." 10. "8. STUN Keepalive Processing" This section contains a mixture of requirements on a UA and requirements on a server. It would be good practice to separate these. 11. "Note that UACs MUST NOT use an ambiguous configuration option such as "Work through NATs?" or "Do Keepalives?" to imply next hop STUN support." I am not sure about RFC2119 language here. First, it does not express a protocol requirement. Second, the whole statement is a note. Third, the requirement is vague and hard to test. I would have thought it sufficient to say "should not". If RFC2119 language is really considered necessary, it should not be stronger than "SHOULD NOT" because of the vagueness of the requirement. 12. "Later, after the Primary reboots, The Callee discovers the flow failure and reestablishes a new flow to the Primary." Alternatively the proxy might discover the flow failure before the Primary reboots, although it cannot of course successfully re-establish the flow until after reboot. Perhaps it should say: "Later, after the Primary reboots, the Callee successfully reestablishes a new flow to the Primary. Keepalive checks and any failed attempts to re-establish the flow are not shown." 13. "The value of the reg-id MUST NOT be 0 and MUST be less than 2**31." According to the ABNF, the value can be less than or equal to 2**31. NITS - Change "the Registrar MUST NOR" to "the Registrar MUST NOT". - Change "Note that the requirements in this section applies" to "Note that the requirements in this section apply" John _______________________________________________ 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
