> -----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? > 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? > 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." 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). > 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. > 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
