Francois, Thanks for your responses, my responses are identified by <kcj>.
Kevin -----Original Message----- From: Francois Audet [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 6:12 PM To: Kevin Johns; [email protected] Cc: Rohan Mahy; Cullen Jennings Subject: RE: [Sip] Outbound-12 comments > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Kevin Johns > Sent: Monday, March 10, 2008 11:27 > To: [email protected] > Subject: [Sip] Outbound-12 comments > > 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." I think it's clear. What do you propose we change? <kcj> I was not necessarily proposing a change. I just wanted to make sure folks were comfortable with the language 'a unique REGISTER in the normal way'. When I read this it was unclear to me what unique was referring to? Is the REGISTER unique in that each must have a different reg-id or that a unique call-id is used or both? Further if the normal way is RFC 3261 then why not state a REGISTER per RFC 3261 with the following enhancements...? > 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. You mean the Flow-Timer? I'm not sure why we would want to discuss the Flow-Timer in the section about Registration. Can you be more specific on what you are looking for? <kcj> Yes I meant flow-timer, sorry for the confusion. Given there is text in 4.2.1 to examine the registration response for presence of the outbound option-tag it seemed reasonable to identify all the parameters the UA should look for in the response. No big deal if folks are comfortable with the current text. > 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 You mean saying: "Re-registrations and single Contact de-registrations MUST use the same instance-id and reg-id values as the corresponding initial registration." <kcj> Yes this is my suggestion Rohan? > 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? I think this is a typo: it should say "non-Register request.". > Further why is this recommended? I did not see this information being > used by the edge proxy elsewhere in the document? That is a good question. Rohan? Cullen? > 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? Correct. It would cross with the current tread on keep-alive usage. > 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'. Correct. > 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? I'm not sure it would be useful, as omitting the Flow-Timer altogether would have the same result (and would use less bytes in messages). <kcj> OK > Section 6, Registrar Mechanisms: Processing REGISTER Requests > - this section has no discussion on action taken on receipt of a 430 > response. Correct. It describes UAS not UAC. <kcj> I am no longer sure why I called this out, especially given my comment below on section 7. > 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. Yes, it may need some improvements. _______________________________________________ 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
