All, I did a review of outbound, please find my comments below. This review is for sections 4-8 and the comments are primarily related to tightening up the procedures.
Comments are formatted as follows - <section #>, <section title>, <optional text location> - comment... Regards, Kevin Section 4.2.1, Initial Registration, 2nd para - Is the opening sentence well understood by all? "For each outbound proxy URI in the set, the UA SHOULD send a unique REGISTER in the normal way using this URI as the default outbound proxy." Section 4.2.1, Initial Registration - this section makes no reference to the keep-timer. It would seem that this should be discussed in the same context as detecting outbound support in the registration response? It is covered in section 4.4 but seems out of place as a first reference. Section 4.2.2, Subsequent REGISTER requests, The first sentence - "Re-registrations and single Contact de-registrations use the same instance-id and reg-id values as the corresponding initial registration." Suggest making this normative Section 4.3, Sending Non-REGISTER Requests, 1st paragraph - "UAs that support this specification SHOULD include the outbound option tag in a Supported header field in a non-Register REGISTER request." What is a non-Register REGISTER request? Further why is this recommended? I did not see this information being used by the edge proxy elsewhere in the document? Section 4.4, Keep-alives and Detecting Flow Failure, 2nd paragraph - "When a successful registration response contains the Flow-Timer header field..." This is the first reference to the Flow-Timer header and it is unclear in the context of this section what a successful registration response is. While a proxy is only allowed to insert this in a response containing the outbound option-tag in a Require header field, it would seem reasonable to indicate that it is only used by the UA if outbound support is also signaled. However this may cross with the current thread on keep-alive usage and that a proxy may choose to use keep-alives without outbound and have a desire to control their rate of arrival? Section 4.4, Keep-alives and Detecting Flow Failure, 2nd paragraph - "For example, it the server suggests 120 seconds, the UA would send each keepalive with a different frequency between 95 and 120 seconds." I think 'it' should be 'if'. Section 5.4, Edge Proxy Keep alive Handling, last paragraph - should recommended timer values be provided which align with the UA recommended values in absence of the Flow-Timer value? Section 6, Registrar Mechanisms: Processing REGISTER Requests - this section has no discussion on action taken on receipt of a 430 response. Section 7 (Authoritative Proxy Mechanisms: Forwarding Requests - last para) does talk about invalidating bindings to invalid flows but does not reference a 430 response as one possible methods for determining a failed flow/binding. I am not sure which section should address this but some text does need to be added to cover this cause. _______________________________________________ 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
