Re: [BLISS] Updated open issues list fordraft-ietf-bliss-call-completion-05
"WORLEY, Dale R (Dale)" <dworley@avaya.com> Wed, 26 May 2010 17:22 UTC
Return-Path: <dworley@avaya.com>
X-Original-To: bliss@core3.amsl.com
Delivered-To: bliss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA2F3A68B2 for <bliss@core3.amsl.com>; Wed, 26 May 2010 10:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 pysNGk80dREN for <bliss@core3.amsl.com>; Wed, 26 May 2010 10:22:25 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7DED23A63EB for <bliss@ietf.org>; Wed, 26 May 2010 10:22:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,304,1272859200"; d="scan'208";a="190575796"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 May 2010 13:22:12 -0400
X-IronPort-AV: E=Sophos;i="4.53,304,1272859200"; d="scan'208";a="466784671"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 May 2010 13:22:12 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.188]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Wed, 26 May 2010 13:22:11 -0400
From: "WORLEY, Dale R (Dale)" <dworley@avaya.com>
To: "Martin.Huelsemann@telekom.de" <Martin.Huelsemann@telekom.de>
Date: Wed, 26 May 2010 13:20:52 -0400
Thread-Topic: [BLISS] Updated open issues list fordraft-ietf-bliss-call-completion-05
Thread-Index: AQHK/PfK+UrRYE0+i0CbTwzYKUekFw==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FD736128@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "bliss@ietf.org" <bliss@ietf.org>, "L.Liess@telekom.de" <L.Liess@telekom.de>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>
Subject: Re: [BLISS] Updated open issues list fordraft-ietf-bliss-call-completion-05
X-BeenThere: bliss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 17:22:28 -0000
I am starting to respond to Martin's response to my "open issues list" message. This message is primarily for Martin (who is editing the -06 version of the draft), but is also intended for the Bliss community. Regarding these issues: * 1011 Forking of the CC SUBSCRIBE to multiple destinations * 2004 Failure codes for CC SUBSCRIBE > From: Martin.Huelsemann@telekom.de > > > From: Dale Worley > > Subject: [BLISS] Updated open issues list for > > draft-ietf-bliss-call-completion-05 > > > * 1011 Forking of the CC SUBSCRIBE to multiple destinations > > > > Andrew Hutton notes that the SIP stack in some UAs may not be > > able to send several SUBSCRIBEs to several destinations using > > the same Call-Id. > > > > The answer is that it is not *necessary* for these SUBSCRIBEs > > to be forks of the same transaction. If they have separate > > Call-Ids, there are certain inefficiencies but no loss of > > functionality: A monitor might receive forks of more than > > one of these SUBSCRIBEs and not realize that they are merged > > requests, and will establish multiple queue elements. But > > only one of these queue elements will be selected for callback. > > > > We need to add some text to section 6.2 about this. (I think > > in older versions there was a requirement that the same > > Call-Id should be used.) This shouldn't be difficult to > > address as it is actually an efficiency measure. > > Maybe we could suggest the usage of the same Call ID with a SHOULD? Yes, I agree, "SHOULD" captures what we want to say. > > * 2004 Failure codes for CC SUBSCRIBE > > > > [New for -05.] The text is inconsistent regarding the > > failure code for a CC SUBSCRIBE for a call that the monitor > > has no record of: 7.2 says 404, 9.7 says 481. It seems to > > me that 404 should be reserved for SUBSCRIBEs for which the > > monitor cannot identify the managed AOR, and 481 used for > > SUBSCRIBEs that designate a proper AOR but not a known call > > for that AOR. > > I agree with your analysis. My proposal is to solve this inconsistency > with a clear definition in subclause 9.7, and delete the regarding > definitions from subclause 7.2, in order to avoid redundant > specification. Yes, that sounds like a good idea. Perhaps add a reference from 7.2 to 9.7. Dale
- Re: [BLISS] Updated open issues list fordraft-iet… WORLEY, Dale R (Dale)
- Re: [BLISS] Updated open issues list fordraft-iet… Kevin P. Fleming