[Sip] Review of sip-outbound-13
"Elwell, John" <john.elwell@siemens.com> Fri, 04 April 2008 15:31 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A9D28C794; Fri, 4 Apr 2008 08:31:48 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676CF28C793 for <sip@core3.amsl.com>; Fri, 4 Apr 2008 08:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.237
X-Spam-Level:
X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_38=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ql6nh+paJXET for <sip@core3.amsl.com>; Fri, 4 Apr 2008 08:31:42 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2D76128C540 for <sip@ietf.org>; Fri, 4 Apr 2008 08:30:11 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JYT00B4D49V83@siemenscomms.co.uk> for sip@ietf.org; Fri, 04 Apr 2008 16:27:33 +0100 (BST)
Date: Fri, 04 Apr 2008 15:00:53 +0100
From: "Elwell, John" <john.elwell@siemens.com>
To: IETF SIP List <sip@ietf.org>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D095BA9B@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: Review of sip-outbound-13
Thread-Index: AciWXEvN4G0kcc5IT3CC5/sITATquQ==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Subject: [Sip] Review of sip-outbound-13
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
I think this is ready to go if the following minor comments are addressed: 1. "This specification also defines multiple keep alive schemes." Change "multiple" to "two". 2. "A Flow is a network protocol layer (layer 4) association" Change "network" to "transport". 3. "One case where a UA may not want to include the sip.instance media feature tag at all is when it is making an anonymous request or some other privacy concern requires that the UA not reveal its identity." There is no statement about what should be done in this case. 4. "These registration requests include a distinct reg-id parameter in the Contact header field." I think some normative language is needed here. Perhaps change to: "For registration requests in accordance with outbound behaviour, the UA MUST include a distinct reg-id parameter in the Contact header field." 5. "the target first hop SIP note" Change "note" to "node". 6. "as this is already allowed by [RFC3261]. Section 7.5, however a UA that did not register using outbound registration" I think this should say "as this is already allowed by [RFC3261] section 7.5. However, a UA that did not register using outbound registration" 7. "Configuration indicating keepalive support for a specific target is considered an explicit indication. If these conditions are satisfied, the UA sends its keepalives according to the same guidelines described in the rest of this section as UAs which register." I don't understand the meaning of the first sentence. Is it trying to say that configuration is an alternative way of determining support for keepalive? 8. "For devices where power is not a significant concern, the UA SHOULD select a random number between 95 and 120 seconds between keepalives. When battery power is a concern, the UA SHOULD select a random number between 672 and 840 seconds (14 minutes). These times MAY be configurable." The last sentence seems to undermine the previous SHOULD strength statements. Also, what exactly can be configurable - just the upper and lower bounds? I don't think, for example, we are proposing to allow somebody to configure say 180 seconds as both upper and lower bounds (not a range, no randomisation). So I think it is the bounds that can be configurable, and even then the 20% difference must be maintained. Perhaps it should say something like: "The UA MUST select a random number between a fixed or configurable upper bound and a lower bound, where the lower bound is 20% less then the upper bound. The fixed upper bound or the default configurable upper bound SHOULD be 120 seconds (95 seconds lower bound) where battery power is not a concern and 840 seconds (672 seconds lower bound) where battery power is a concern." 9. "The delay time is computed by selecting a uniform random time between 50 and 100 percent of the wait time. The UA MUST wait for the value of the delay time before trying another registration to form a new flow for that URI." I find this a little confusing. The several paragraphs before that have all talked about wait time, or time to wait, which suggests that that is how long you wait before trying registration again. Then we suddenly have this "delay time" introduced, and it says that "UA MUST wait for the value of the delay time before trying another registration". It might be better to introduce the concept of delay time and wait time up front. Furthermore, it is not clear whether the delay time (between 50 and 100 percent of the wait time) starts when the wait time starts or when the wait time finishes. I think the examples given in the succeeding paragraph suggest it is the former interpretation. In any case, it needs to be clarified. 10. "The Edge Proxy can determine if it is the first hop by examining the Via header field." Does this still work in the case of topology hiding by an upstream entity? 11. "When a '+sip.instance' media feature parameter is present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding binding is between an AOR and the combination of the instance-id (from the +sip.instance media feature parameter) and the value of reg-id parameter if it is present." I think the normative statements that follow are only concerned with the case where reg-id is present, so I think it should be changed to: "When a '+sip.instance' media feature parameter and a reg-id parameter are present in a Contact header field of a REGISTER request (after the Contact header validation as described above), the corresponding binding is between an AOR and the combination of the instance-id (from the +sip.instance media feature parameter) and the value of reg-id parameter." John _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Review of sip-outbound-13 Elwell, John
- Re: [Sip] Review of sip-outbound-13 Francois Audet
- Re: [Sip] Review of sip-outbound-13 Elwell, John
- Re: [Sip] Review of sip-outbound-13 Rohan Mahy
- Re: [Sip] Review of sip-outbound-13 Francois Audet
- Re: [Sip] Review of sip-outbound-13 Elwell, John