From shida@ntt-at.com Tue Apr 5 00:24:30 2011 Return-Path: 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 526633A68D4 for ; Tue, 5 Apr 2011 00:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 v2Myumz2WQxi for ; Tue, 5 Apr 2011 00:24:29 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.243.15]) by core3.amsl.com (Postfix) with SMTP id DFEFE3A67EF for ; Tue, 5 Apr 2011 00:24:28 -0700 (PDT) Received: (qmail 1744 invoked from network); 5 Apr 2011 07:30:32 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 5 Apr 2011 07:30:32 -0000 Received: from [126.223.88.194] (port=58131 helo=[192.168.20.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q70eO-0003og-QJ; Tue, 05 Apr 2011 02:26:11 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--588868199 From: Shida Schubert In-Reply-To: Date: Tue, 5 Apr 2011 16:26:02 +0900 Message-Id: <862C168E-E6CD-40EE-B891-686B89C6E354@ntt-at.com> References: <20110314210002.8579.48929.idtracker@localhost> To: bliss@ietf.org X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pw126223088194.59.tss.panda-world.ne.jp ([192.168.20.2]) [126.223.88.194]:58131 Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-shared-appearances-07.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 07:24:30 -0000 --Apple-Mail-5--588868199 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, Alan has talked to some of the key contributors to the draft at the=20 IETF80 with regards to the changes, and as far as I know there=20 were no objections with the way forward.=20 That being said, if we don't hear any objections within a week,=20 we will see it as a consensus and proceed the draft forward,=20 so if you have any objections or comments to the changes=20 indicated in Alan's message below provide your comments.=20 Many thanks & regards Shida (as chair) On Mar 15, 2011, at 11:18 PM, Alan Johnston wrote: > All, >=20 > I have updated the draft based on Robert's feedback and my responses = sent to the list previously. There are lots of edits, so Diff2 gives = the best view: >=20 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-bliss-shared-appearances-0= 7.txt >=20 > A few additional notes: >=20 > - I added some text about dialog matching which we need to be sure is = correct - see 5.2.1. >=20 > - There was a question about the ABNF changes and the SALUD work. = Since the SALUD work is just on the Alert-Info URN, there are no ABNF = changes planned to RFC 3261. >=20 > - I added text relating to appearance handling during call transfers. = See 5.3.1, 5.3.2, and 5.3.3. >=20 > Comments most welcome! >=20 > - Alan - >=20 > On Mon, Mar 14, 2011 at 4:00 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Basic Level of Interoperability for = SIP Services Working Group of the IETF. >=20 >=20 > Title : Shared Appearances of a Session Initiation = Protocol (SIP) Address of Record (AOR) > Author(s) : A. Johnston, et al. > Filename : draft-ietf-bliss-shared-appearances-07.txt > Pages : 67 > Date : 2011-03-14 >=20 > This document describes the requirements and implementation of a > group telephony feature commonly known as Bridged Line Appearance > (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line > Appearance (SCA). When implemented using the Session Initiation > Protocol (SIP), it is referred to as shared appearances of an Address > of Record (AOR) since SIP does not have the concept of lines. This > feature is commonly offered in IP Centrex services and IP-PBX > offerings and is likely to be implemented on SIP IP telephones and > SIP feature servers used in a business environment. This feature > allows several user agents (UAs) to share a common AOR, learn about > calls placed and received by other UAs in the group, and pick up or > join calls within the group. This document discusses use cases, > lists requirements and defines extensions to implement this feature. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-bliss-shared-appearances-07= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss --Apple-Mail-5--588868199 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
All,

I have updated the draft based on = Robert's feedback and my responses sent to the list previously.   = There are lots of edits, so Diff2 gives the best = view:


A few additional notes:

- I = added some text about dialog matching which we need to be sure is = correct - see 5.2.1.

- There was a question = about the ABNF changes and the SALUD work.  Since the SALUD work is = just on the Alert-Info URN, there are no ABNF changes planned to RFC = 3261.

- I added text relating to appearance handling = during call transfers.  See 5.3.1, 5.3.2, and = 5.3.3.

Comments most = welcome!

- Alan -

On Mon, Mar 14, 2011 at 4:00 PM, <Internet-Drafts@ietf.org><= /span> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Basic Level of Interoperability for SIP = Services Working Group of the IETF.


       Title           : = Shared Appearances of a Session Initiation Protocol (SIP) Address of = Record (AOR)
       Author(s)       : A. = Johnston, et al.
       Filename        : = draft-ietf-bliss-shared-appearances-07.txt
       Pages           : = 67
       Date           =  : 2011-03-14

This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA).  When implemented using the Session = Initiation
Protocol (SIP), it is referred to as shared appearances of an = Address
of Record (AOR) since SIP does not have the concept of lines. =  This
feature is commonly offered in IP Centrex services and IP-PBX
offerings and is likely to be implemented on SIP IP telephones and
SIP feature servers used in a business environment.  This = feature
allows several user agents (UAs) to share a common AOR, learn about
calls placed and received by other UAs in the group, and pick up or
join calls within the group.  This document discusses use = cases,
lists requirements and defines extensions to implement this feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-sha= red-appearances-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


_______________________________________________
BLISS mailing = list
BLISS@ietf.org
https://www.ietf.org/= mailman/listinfo/bliss

= --Apple-Mail-5--588868199-- From dworley@avaya.com Wed Apr 13 12:46:21 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5D214E085D for ; Wed, 13 Apr 2011 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP-9ZgVXg3qf for ; Wed, 13 Apr 2011 12:46:19 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfc.amsl.com (Postfix) with ESMTP id BB2E6E07CB for ; Wed, 13 Apr 2011 12:46:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJgtcU3GmAcF/2dsb2JhbACmZHSkegKZF4J/gmIEkAw X-IronPort-AV: E=Sophos;i="4.64,205,1301889600"; d="scan'208";a="184563579" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 13 Apr 2011 15:46:17 -0400 X-IronPort-AV: E=Sophos;i="4.64,205,1301889600"; d="scan'208";a="608471506" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 13 Apr 2011 15:46:17 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 13 Apr 2011 15:46:16 -0400 From: "Worley, Dale R (Dale)" To: "bliss@ietf.org" Date: Wed, 13 Apr 2011 15:46:16 -0400 Thread-Topic: Comments on draft-ietf-bliss-shared-appearances-07 Thread-Index: AQHL+hNzhJdN/nt7gkCgEMuOlYXnMA== Message-ID: 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 Subject: [BLISS] Comments on draft-ietf-bliss-shared-appearances-07 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 19:46:21 -0000 I've finally gotten the cycles to go over draft-ietf-bliss-shared-appearanc= es-07. We consider this work to be seriously important for the use of SIP = in the business telecom market, and want to see Shared Appearances standard= ized. Unfortunately, I'm too pressed for time to have examined these items= a second time, so please forgive the mistakes in my queries. Dale ---------------------------------------------------------------------- section 1: This paragraph is awkward: This document looks at how this feature can be implemented using standard SIP [RFC3261] in conjunction with SIP events [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] for exchanging status among user agents, and the SIP dialog state event package [RFC4235] to exchange dialog state information to achieve the same. Perhaps: This document looks at how this feature can be implemented using standard SIP [RFC3261] in conjunction with SIP events [I-D.ietf-sipcore-rfc3265bis] and publication [RFC3903] (carrying the SIP dialog state event package [RFC4235]) for exchanging status among user agents. section 1: The appearance number relates to the user interface for the telephone - typically each appearance of an AOR has a visual display (lamp that can change color or blink or a screen icon) and a button (used to select the appearance). Might be better as: The appearance number relates to the user interface for the telephone - typically each appearance of an AOR has a visual display (lamp that can change color or blink or a screen icon) and a button (used to select the appearance) - where each appearance number is associated with a different dialog to/from the AOR. section 1: If a telephone has enough buttons/lamps, calls could be presented on the nth button. Would be clearer as: If a telephone has enough buttons/lamps, the appearance number could be the positional sequence number of the button. section 4.1, REQ-14: Exclusivity means that the UA requesting it desires to have a private conversation with the external party and other UAs must not be allowed to be joined or taken. is not correctly phrased. Correct to: Exclusivity means that the UA requesting it desires to have a private conversation with the external party and other UAs must not be allowed to joined or take the call. section 4.2: While an Appearance Agent can be part of a centralized server, it could also be co-resident in a member User Agent who has taken on this functionality for a group. "who" should be "which". section 4.2, step 5: For outgoing calls, the operation depends on the implementation. If the user seizes a particular appearance number for the call, the UA publishes the 100 Trying state dialog information without an appearance number and waits for a 200 OK before sending the INVITE. This appears to be incorrect. I think the correct version is: For outgoing calls, the operation depends on the implementation. If the user seizes a particular appearance number for the call, the UA publishes the >>"trying"<< state dialog information >>with the<< appearance number and waits for a >>2xx<< before sending the INVITE. section 4.2, step 7: For outgoing calls, if the user does not wish to seize an appearance (such as during a consultation call or if a UA is fetching 'service media' such as music on hold [I-D.worley-service-example]), the UA also publishes this prior to sending the INVITE. "this" should be clarified (what exactly is published to indicate lack of interest in receiving an appearance number?) And I think that the question is not "does not wish to seize an appearance" but rather "does not want an appearance number assigned", as a UA can make a call without "seizing" (as defined in section 5), but will have a number assigned automatically. section 4.2, step 9: The Appearance Agent may not have full access to the complete dialog state of some or all of the UAs in the group. If this is the case, the Appearance Agent will subscribe to the dialog state of individual UAs in the group to obtain this information. Normal notifications will be sent every time the dialog state changes, including calls placed, answered, placed on and off hold, and hangups. This is hard to read until you realize that "may not have full access" means "may not have back-door access". A better phrasing would be: The Appearance Agent may not have direct access to the complete dialog state of some or all of the UAs in the group. If this is the case, the Appearance Agent will subscribe to the dialog state of individual UAs in the group to obtain this information. In any case, the Appearance Agent will send normal notifications (via the subscriptions established by the UAs in step 1) every time the aggregate dialog state of the AOR changes, including when calls are placed, answered, placed on and off hold, and hung up. section 5: Somewhere near the beginning of section 5, it seems like a description of the intended properties of appearance numbers is needed. In particular: Appearance numbers are non-negative integers. When an appearance number is requested to be assigned, generally the assigned number is the smallest nonnegative integer that is not currently assigned as an appearance number to a dialog for this AOR. This rules out, e.g., having the appearance numbers be a dialog sequence number that increments throughout the history of the AOR. BTW, is the latest decision that appearance numbers start with 0, rather than 1? A word seems to be missing: [...] initiating a dialog, in order to appear as >>if<< it was already initiating a dialog. The following sentence uses "confirmed", and several later sentences use "confirmed by the Appearance Agent". But there is no definition of this "confirming" operation: The appearance number is confirmed prior to sending the INVITE. The import of this sentence is unclear: This is a user interface only issue. The sentence is also awkwardly phrased, as one would probably want to construct "user-interface-only issue". Less awkward would be: This is an issue only for the user interface. or This is only a user interface issue. But given that there are protocol actions involved, it's not clear why that sentence is stated, or even exactly what "this" refers to. section 5.2.1: There is a lot that is not clear in this paragraph, and also a lot of stealthy description of protocol actions hidden in a paragraph that is ostensibly about a data item. In addition, it does not state that every element is the child of a element (nor does the schema). The element is used to convey the appearance number. The appearance number is a positive integer. When sent in a publication in state Trying to the Appearance Agent, it is used to request an appearance number. When sent by the Appearance Agent, it indicates that the appearance number is associated with a dialog. The UA generating the to-tag and from-tag parameters treats them from a local perspective. In other words, if the UA sent out a request within the dialog, the to-tag parameter would match the remote tag, and the from-tag parameter would match the local tag. Better would be: The element is used to convey the appearance number of the dialog described by the element which is its parent, on the UA(s) [for the AOR?] specified by the "entity" attribute. The appearance number is a positive integer. When sent in a PUBLISH with parent with state attribute "trying" by a UA to the Appearance Agent, the UA is requesting assignment of the given appearance number to the current or future dialog with the given dialog identifiers. When an element is sent by the Appearance Agent in a NOTIFY, it indicates that the appearance number has been assigned to the specified dialog. Note that a element describes the contained s "from the point of view of the UA" (named by the "entity" attribute), regardless of whether the containing request is sent by the UA or the Appearance Agent. In particular, if the UA sent a request within the described dialog, the "To" header URI would match the value and the to-tag parameter would match the remote-tag attribute. Similarly, the "From" header URI would match the value and the from-tag parameter would match the local-tag attribute. But this leads to the point that there is no clear, separate description of the fundamental protocol action, viz., the UA sends a PUBLISH to the Appearance Agent to request an appearance assignment and the Appearance Agent sends a NOTIFY back to the UA with the final assignment. Also, this says that the appearance number is a "positive integer" whereas appearance numbers are non-negative integers. section 5.2.2: The element is a boolean used to indicate whether the UA will accept Join or Replaces INVITEs for this dialog. For example, some shared appearance systems only allow call pickup when the call is on hold. In this case, the element should be used to explicitly indicate this, rather than implicitly by the hold state. could be clarified as: The element is a boolean, which when true, indicates that the UA is willing to accept an INVITE with a Join or Replaces header targeted to the dialog described by the element that is the parent of the element. For example, some shared appearance systems only allow call pickup when the call is on hold. In this case, the element should be set to "true" when the call is held and "false" when the call is not held, rather than having the "exclusive" value implied by the hold state. BTW, is there a default value for "exclusive"? The schema doesn't show one. Expanding this sentence would help: It is important to note that this element is a hint, and that the UA must take additional steps to ensure that INVITE with Join or Replaces is not applied to the dialog. section 5.2.3: Only the UA which is performing the actual media mixing should include this element in publications to the Appearance Agent. This is not exactly correct, as the UA may be doing 3pcc to a mixing agent. What we want is: Only the UA which is the common endpoint of the mixed dialogs (and thus controlling the mixing operation) should include this element in publications to the Appearance Agent. section 5.3: Should probably add: User Agents which implement call pickup, joining and bridging MUST support sending >>and receiving<<< an INVITE with Replaces [RFC3891] or Join [RFC3911]. and omit the last sentence of the paragraph. Or else, the requirements are more complex than I understand them to be. These two sections probably ought to be combined to clarify the operations that are intended: A UA MUST send dialog package PUBLISH requests in the following situations: [...] In all these cases, the INVITE SHOULD NOT be sent until the 200 OK response to the PUBLISH has been received, except for an emergency call, when a UA MUST never wait for a confirmed seizure before sending an INVITE. Instead, the emergency call MUST proceed regardless of the status of PUBLISH transaction. viz.: In the following cases, before sending the INVITE, a UA MUST send a dialog package PUBLISH request to the Appearance Agent containing the forthcoming dialog state changes and receive the 2xx response: [...] An exception is an emergency call, when a UA MUST never wait for a confirmed seizure before sending an INVITE. Instead, the emergency call MUST proceed without waiting for the PUBLISH transaction. section 5.3, item 1: I think "i.e." here should be "e.g.". section 5.3: It's not clear why this sentence using receipt of the 100 as a criterion, as the receipt of the 100 does not provide any additional dialog information: If no dialog identification information is present in the initial PUBLISH, the UA MUST PUBLISH again after receiving the 100 Trying response. I believe that what is wanted is "[...] the UA MUST publish again promptly after the Call-Id and from-tag are established." This publication state is refreshed as described in [RFC3903] during the early dialog state or the Appearance Agent may reassign the I think you want "This publication [published?] state MUST be refreshed as described in [RFC3903] or the Appearance Agent may reassign [...]" It's not clear why PUBLISH refreshes are not required after transition to the confirmed state, as RFC 3903 states that published data are soft-state with specified expiration time. If this I-D intends to handle expiration differently from RFC 3903, this needs to be specified clearly. Shouldn't the following SHOULD be a MUST? A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA SHOULD free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. section 5.3.1: The first sentence would be clearer as: There are cases where two separate dialogs at a UA are not mixed but share the same 'context'. The last sentence of the paragraph would be clearer as: These cases are best handled by not assigning an appearance number to a newly-created dialog when it shares a context with a pre-existing dialog. (But if the pre-existing dialog is terminated, its appearance number should be reassigned to the newly-created dialog.) This sentence could be clarified: If the Appearance Agent policy does not allow calls without an assigned appearance number, a 400 response with the reason phrase "Appearance Number Conflict" will be received, and the UA will republish either selecting/seizing an appearance number or send the INVITE without publishing, in which case the Appearance Agent will assign one. as: If the Appearance Agent policy does not allow calls without an assigned appearance number, a the UA will receive a 400 response with the reason phrase "Appearance Number Conflict", and the UA must either republish selecting/seizing an appearance number or send the INVITE without publishing, in which case the Appearance Agent will assign an appearance number. See also comments below about using 400 as a response code. section 5.3.2: This explanation probably needs to be fleshed out. I can't visualize what is expected to be published: When an INVITE is generated to attempt to bridge or take a call (i.e. contains Join or Replaces with a dialog identifier of another dialog in the shared appearance group), the appearance number of the joined or replaced call SHOULD be published. The publication MUST contain the appearance number of the dialog to be joined or replaced and the dialog identifier in the 'joined-dialog' or 'replaced-dialog' elements. section 5.3.3: This paragraph contains a vicious passive construction, which describes what is to be done but does not describe what is to do it: If Alice is the transferee, the triggered INVITE from the REFER should be treated as a consultation call, and should not use a new appearance number. When the transfer completes, the appearance number associated with the dialog with Carol is moved to the dialog associated with David. The last sentence should be "When the transfer completes, Alice's UA publishes new state associating the appearance number of the former dialog with Carol with the new dialog with David." This paragraph isn't clear whether the incoming INVITE-with-Replaces has no appearance number associated, or whether the AA should tag it with the same appearance number. It seems from the rest of the I-D, that the new dialog should have no appearance number until the dialog that is replaced is terminated, and then Alice's UA should assign the old appearance number to the new dialog. But that is not stated clearly. If Alice is the target, the incoming INVITE should not have a new appearance number assigned. Instead, it should reuse the appearance number associated with the dialog being replaced. If the Appearance Agent does assign a different appearance number, when the transfer completes, Alice should release that appearance number and use the original appearance number associated with the dialog with Carol. section 5.4: The specification requires the use of a particular reason phrase, "Appearance Number Conflict". Making the reason phrase significant is contrary to all previous SIP usage. Wouldn't it be better to allocate a specific 4xx response code? section 6: The schema gives the extension namespace as "urn:ietf:params:xml:ns:sa-dialog-info-info" instead of "urn:ietf:params:xml:ns:sa-dialog-info." The indenting of the XML schema is irregular. section 7: appearance-param =3D "appearance" EQUAL *DIGIT is probably intended to require at least one digit, which would be: appearance-param =3D "appearance" EQUAL 1*DIGIT section 8: The design of the UI is strongly affected by the expected appearance numbers. My belief is that the intended design is that the appearance nubmers will be small non-negative integers. (See the item regarding describing appearance numbers per se at the beginning of section 5.) But there needs to be some stated policy regarding appearance numbers that cannot be rendered by the UA. Is the UA allowed to reject them? Section 8.1.1 appears to allow rejection, but this fact is a significant protocol action that should not be buried in an apparently non-normative section about user-interface design. section 8.2: "sip+rendering=3Dno" should be "+sip.rendering=3Dno" in two places. section 9: Two uses of "interop", which should be "interoperation". section 12 (Security Considerations) should reference or include this text from 5.3, as it is a life-safety consideration: [For an emergency call, a] UA MUST never wait for a confirmed seizure before sending an INVITE. Instead, the emergency call MUST proceed regardless of the status of PUBLISH transaction. section 10: I see three different descriptions of how to determine if SA is available for a particuar AOR: section 4.2, REQ-1 [A UA] attempts a dialog state subscription to the AOR. If the subscription fails, loops back to itself, or returns an error, it knows there is no State Agent, and hence no Appearance Agent and this feature is not implemented. section 5.3 Upon initialization, the UA MUST subscribe to the dialog event package of the AOR and refresh the subscription per the SIP Events Framework. If the SUBSCRIBE request fails, then no Appearance Agent may be present and this feature is not active for this AOR. section 10 UAs can automatically discover if this feature is active for an AOR by looking for the 'shared' Event header parameter in a response to = a dialog package SUBSCRIBE to the AOR, so no provisioning for this is needed. It would also be useful in practice if some hints were given for interoperation with UAs that implement previous versions of this work. This probably can be limited to methods to detect which version a particular UA implements. section 11.8: The description says that a call from one UA in a group to another UA in the group would only use one appearance number. This is not uniform with the rest of the SA architecture and is not the behavior of traditional key phone systems. Are you sure you want to present it this way? section 11.13: Another passive: Whenever Bob's dialog state changes, a NOTIFY is sent to the Appearance Agent who then notifies the other other UAs in the group. should be: Whenever Bob's dialog state changes, Bob sends a NOTIFY to the Appearance Agent who then notifies the other other UAs in the group. You probably want to change "who" to "which". ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Thu Apr 14 05:30:03 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DACCCE08DF; Thu, 14 Apr 2011 05:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn1lA89pDWQg; Thu, 14 Apr 2011 05:30:03 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 33772E08E1; Thu, 14 Apr 2011 05:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110414123003.28126.54267.idtracker@ietfc.amsl.com> Date: Thu, 14 Apr 2011 05:30:03 -0700 Cc: bliss@ietf.org Subject: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF. Title : Call Completion for Session Initiation Protocol (SIP) Author(s) : D. Worley, et al. Filename : draft-ietf-bliss-call-completion-09.txt Pages : 31 Date : 2011-04-14 The call completion features allow the calling user of a failed call to be notified when the called user becomes available to receive a call. For the realization of a basic solution without queuing call- completion requests, this document references the usage of the the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing call-completion requests, this document introduces an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. The deployment of a certain SIP call-completion solution is also dependent on the needed level of interoperability with existing call- completion solutions in other networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-completion-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-bliss-call-completion-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-14052953.I-D@ietf.org> --NextPart-- From Martin.Huelsemann@telekom.de Thu Apr 14 08:01:27 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68801E073D for ; Thu, 14 Apr 2011 08:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER3-2k35CONQ for ; Thu, 14 Apr 2011 08:01:26 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfc.amsl.com (Postfix) with ESMTP id 33748E0791 for ; Thu, 14 Apr 2011 08:01:26 -0700 (PDT) Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 14 Apr 2011 16:59:06 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.191]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Thu, 14 Apr 2011 16:59:06 +0200 From: To: Date: Thu, 14 Apr 2011 16:59:05 +0200 Thread-Topic: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt Thread-Index: Acv6n76+hM08BsrjRAmEjg5vNc43cgADLmiw Message-ID: <9762ACF04FA26B4388476841256BDE020113F82C0956@HE111543.emea1.cds.t-internal.com> References: <20110414123003.28126.54267.idtracker@ietfc.amsl.com> In-Reply-To: <20110414123003.28126.54267.idtracker@ietfc.amsl.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: j.dave.smith@siemens-enterprise.com Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:01:27 -0000 Dear colleagues, a 09 version of the CC draft was uploaded. This versions includes correctio= ns (ABNF, wrong example, missing timer), resulting from the 3 sustantial co= mments I got during WGLC. Further there are editorials (spelling correction= s, wording clarifications, example clarifications). After WGLC I got comments refelecting different reqirements for CC running = on a device and not on a server in the network, which would change some SHA= LLs to SHOULDs, see my last mail to the list. As I said in my opinion those= changes are very useful for a more comprehensive CC solution, and therefor= e should be considered. I have therefore provided a 10_draft_a version of t= he internet draft. You can check the differences at http://bliss-ietf.org/drafts/diff_09_10_draft_a.html http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-10_draft_a.t= xt Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] > Im Auftrag von Internet-Drafts@ietf.org > Gesendet: Donnerstag, 14. April 2011 14:30 > An: i-d-announce@ietf.org > Cc: bliss@ietf.org > Betreff: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Basic Level of > Interoperability for SIP Services Working Group of the IETF. > > > Title : Call Completion for Session > Initiation Protocol (SIP) > Author(s) : D. Worley, et al. > Filename : draft-ietf-bliss-call-completion-09.txt > Pages : 31 > Date : 2011-04-14 > > The call completion features allow the calling user of a > failed call to be notified when the called user becomes > available to receive a call. > > For the realization of a basic solution without queuing call- > completion requests, this document references the usage of > the the dialog event package (RFC 4235) that is described as > 'automatic redial' in the SIP Service Examples (RFC 5359). > > For the realization of a more comprehensive solution with > queuing call-completion requests, this document introduces an > architecture for implementing these features in the Session > Initiation Protocol: > "Call completion" implementations associated with the > caller's and callee's endpoints cooperate to place the > caller's request for call completion into a queue at the > callee's endpoint, and, when a caller's request is ready to > be serviced, re-attempt the original, failed call. > > The deployment of a certain SIP call-completion solution is > also dependent on the needed level of interoperability with > existing call- completion solutions in other networks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-completion-09.t= xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail > reader implementation to automatically retrieve the ASCII > version of the Internet-Draft. > From Martin.Huelsemann@telekom.de Thu Apr 14 08:08:45 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F573E073D for ; Thu, 14 Apr 2011 08:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6bmElffRG2T for ; Thu, 14 Apr 2011 08:08:44 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfc.amsl.com (Postfix) with ESMTP id 82A27E0718 for ; Thu, 14 Apr 2011 08:08:43 -0700 (PDT) Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 14 Apr 2011 17:07:59 +0200 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.191]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Thu, 14 Apr 2011 17:07:59 +0200 From: To: , Date: Thu, 14 Apr 2011 17:07:58 +0200 Thread-Topic: more comments on the CC draft Thread-Index: AcvvtP8u4HqlfMucRyGWDU/f1cRubAAE6CMwAVtknDA= Message-ID: <9762ACF04FA26B4388476841256BDE020113F82C0964@HE111543.emea1.cds.t-internal.com> References: <9762ACF04FA26B4388476841256BDE020113D8897CC1@HE111543.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE020113F82C0964HE111543eme_" MIME-Version: 1.0 Subject: Re: [BLISS] more comments on the CC draft X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:08:45 -0000 --_000_9762ACF04FA26B4388476841256BDE020113F82C0964HE111543eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Keith, I incorporated your comment 1) in the 09 version. For 2), we often used 'SHOULD' in order to be as flexible as possible at im= plementations, as the solution was intended to be interoperable with the PS= TN, and there are some differences between internet and PSTN usecases. For = the normative statements changed after I've added conditions. Are there any= more particular text passages which you think need more clarification? The 10_draft_a version can be found at http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-10_draft_a.tx= t Regards, Martin ________________________________ Von: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Gesendet: Donnerstag, 31. M=E4rz 2011 19:28 An: H=FClsemann, Martin; bliss@ietf.org Cc: j.dave.smith@siemens-enterprise.com; Jesske, Roland Betreff: RE: more comments on the CC draft I was kicked off to look at this further. My brief skim identifies two issues: 1) Generally throughout the document, "header" should be "header fi= eld" and "header parameter" should be "header field parameter". 2) All instances of the words "SHOULD" and "RECOMMENDED" should be = qualified by informative material indicating when the requirement applies /= does not apply. The note below that some SHALLs have changed to SHOULD tri= ggered me on this. I'll try and have a closer look when not in a meeting. Regards Keith ________________________________ From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of M= artin.Huelsemann@telekom.de Sent: 31 March 2011 16:05 To: bliss@ietf.org Cc: j.dave.smith@siemens-enterprise.com; R.Jesske@telekom.de Subject: [BLISS] more comments on the CC draft Dear colleagues, during the last WGLC I again received a lot of comments from Dave for edito= rials and spelling corrections, thanks again for checking, my apologies for= not having detected them myself. Besides the editorials, Dave commented that the procedures are based very m= uch on the assumption of a underlying network architecture where there is a= clear seperation between the UA on the user device and the CC agent/monito= r which is located in the network. Dave proposed to better consider the cas= e where the CC agent/monitor is colocated with the UA on the user device. An example is a simple UA uses CC via a AS in the network, and when this UA= is not available for CC recall, we said that the CC agent SHALL suspend th= e CC request. But the suspension policy of a more sophisticated agent of a = CC App on a device could be different, therefore it was changed to 'SHOULD = be suspended'. There are some other changes in this direction. There are no= syntax changes. Even though they were contributed post WGLC, in my opinion those changes ar= e very useful for a more comprehensive CC solution, and therefore should be= considered. I have provisionally provided a 09 version of the internet dra= ft. You can find the changes at http://bliss-ietf.org/drafts/diff_ccbs.htm= l Your opinions? Regards, Martin --_000_9762ACF04FA26B4388476841256BDE020113F82C0964HE111543eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Keith,
 
I=20 incorporated your comment 1) in the 09 version.
 
For=20 2), we often used 'SHOULD' in order to be as flexible as possible at=20 implementations, as the solution was intended to be interoperable with the = PSTN,=20 and there are some differences between internet and PSTN usecases. For the= =20 normative statements changed after I've added conditions. Are there any mor= e=20 particular text passages which you think need more=20 clarification?
 
The=20 10_draft_a version can be found at

http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-10_= draft_a.txt

 
Regards, Martin
 
 
 
 
Von: DRAGE, Keith (Keith)=20 [mailto:keith.drage@alcatel-lucent.com]
Gesendet: Donnerstag, 31= .=20 M=E4rz 2011 19:28
An: H=FClsemann, Martin; bliss@ietf.org
C= c:=20 j.dave.smith@siemens-enterprise.com; Jesske, Roland
Betreff: RE: = more=20 comments on the CC draft

I was kicked o= ff to=20 look at this further.

 

My brief skim= =20 identifies two issues:

 

1)  =       =20 Generally throughout the document, =93header=94 should be =93header field= =94 and=20 =93header parameter=94 should be =93header field=20 parameter=94.

 

2)  =       =20 All instances of the words =93SHOULD=94 and =93RECOMMENDED=94 should be q= ualified by=20 informative material indicating when the requirement applies / does not a= pply.=20 The note below that some SHALLs have changed to SHOULD triggered me on=20 this.

 

I=92ll try and= have a=20 closer look when not in a meeting.

 

Regards

 

Keith

 

From: bliss-bounces@ietf.org=20 [mailto:bliss-bounces@ietf.org] On B= ehalf=20 Of Martin.Huelsemann@telekom.de
Sent: 31 March 2011 16:05
To: bliss@ietf.org
Cc: j.dave.smith@siemens-enterpris= e.com;=20 R.Jesske@telekom.de
Subject:=20 [BLISS] more comments on the CC draft

 

Dear=20 colleagues,

 

during the last WGLC I agai= n=20 received a lot of comments from Dave for editorials and spelling=20 corrections, thanks again for checking, my apologies for not having detec= ted=20 them myself.

 

Besides the editorials, Dav= e=20 commented that the procedures are based very much on the assumption = of a=20 underlying network architecture where there is a clear seperation between= the=20 UA on the user device and the CC agent/monitor which is located in the=20 network. Dave proposed to better consider the case where the CC agent/mon= itor=20 is colocated with the UA on the user=20 device. 

An example is a simple= UA=20 uses CC via a AS in the network, and when this UA is not available for CC= =20 recall, we said that the CC agent SHALL suspend the CC request. But the=20 suspension policy of a more sophisticated agent of a CC App on a device c= ould=20 be different, therefore it was changed to 'SHOULD be suspended'. There ar= e=20 some other changes in this direction. There are no syntax=20 changes.

 

Even though they were contr= ibuted=20 post WGLC, in my opinion those changes are very useful for a more=20 comprehensive CC solution, and therefore should be considered. I have=20 provisionally provided a 09 version of the internet draft. You can find t= he=20 changes at  http://bliss-ietf.or= g/drafts/diff_ccbs.html

 

Your=20 opinions?

 

 

Regards, Martin

=  

=  

=
--_000_9762ACF04FA26B4388476841256BDE020113F82C0964HE111543eme_-- From dworley@avaya.com Thu Apr 14 14:33:59 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E48B4E08FD for ; Thu, 14 Apr 2011 14:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPo7Vq8kAPmf for ; Thu, 14 Apr 2011 14:33:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfc.amsl.com (Postfix) with ESMTP id 26893E0705 for ; Thu, 14 Apr 2011 14:33:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.64,213,1301889600"; d="scan'208";a="274874970" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Apr 2011 17:33:55 -0400 X-IronPort-AV: E=Sophos;i="4.64,213,1301889600"; d="scan'208";a="639231128" 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; 14 Apr 2011 17:33:55 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 14 Apr 2011 17:33:54 -0400 From: "Worley, Dale R (Dale)" To: "bliss@ietf.org" Date: Thu, 14 Apr 2011 17:33:12 -0400 Thread-Topic: Technical issues regarding draft-ietf-bliss-shared-appearances-07 Thread-Index: AQHL+uunlbt2P8z0FUiuIFKAC/5cNA== Message-ID: 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 Subject: [BLISS] Technical issues regarding draft-ietf-bliss-shared-appearances-07 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 21:34:00 -0000 To extract the technical questions from the editorial ones in my comments: It seems to me that the open technical questions are: * Is the latest decision that appearance numbers start with 0, rather than 1? Starting the numbering from 0 would be cleaner, but the customers will universally count from 1, so all UAs are going to have to present appearance numbers 1, 2, 3, .... If the appearance numbers in the protocol start with 0, all UAs will have to translate, which will inevitably lead to errors. * Is there a default value for "exclusive"? The schema doesn't show one. Inevitably people will omit the element, so we need to decide what the implicit value is. For simplicity, this default should probably be the effective value for UAs that publish non-shared dialog events, as the schema doesn't seem to be able to make mandatory. * It's not clear why PUBLISH refreshes are not required after transition to the confirmed state, as RFC 3903 states that published data are soft-state with specified expiration time. If this I-D intends to handle expiration differently from RFC 3903, this needs to be specified clearly. I suggest that we not use PUBLISH in a way that is at all different from RFC 3903 -- changes would make it impossible to use a general PUBLISH toolkit as part of a SA UA. * The specification requires the AA to reject proposed appearance number assignments by a 400 response with a particular reason phrase, "Appearance Number Conflict". Making the reason phrase significant is contrary to all previous SIP usage. And using 400 (the generic failure message) to indicate a specific meaning is hazardous. Wouldn't it be better to allocate a unique 4xx response code? (There are over 50 available.) * It would also be useful in practice if some hints were given for interoperation with UAs that implement previous versions of this work. This probably can be limited to methods to detect which version a particular UA implements. * The description in section 11.8 says that a call from one UA in a group to another UA in the group would only use one appearance number. This is not uniform with the rest of the SA architecture and is not the behavior of traditional key phone systems. Are you sure you want to handle this call this way? Dale From dworley@avaya.com Mon Apr 18 14:18:36 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CBECAE06B5 for ; Mon, 18 Apr 2011 14:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-g2ZHZyQk2D for ; Mon, 18 Apr 2011 14:18:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfc.amsl.com (Postfix) with ESMTP id 063D7E06F9 for ; Mon, 18 Apr 2011 14:18:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJgtcU3GmAcF/2dsb2JhbACmZHSkegKZF4VhBJAM X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="184929229" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 Apr 2011 15:42:14 -0400 X-IronPort-AV: E=Sophos;i="4.64,234,1301889600"; d="scan'208";a="610140428" Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Apr 2011 15:42:14 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 18 Apr 2011 15:42:14 -0400 From: "Worley, Dale R (Dale)" To: "bliss@ietf.org" Date: Mon, 18 Apr 2011 15:39:08 -0400 Thread-Topic: How are appearance assignments by phones confirmed? Thread-Index: AQHL/gC3BtBJZIcmRU2mlcFrCcpO5w== Message-ID: 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 Subject: [BLISS] How are appearance assignments by phones confirmed? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 21:18:37 -0000 Regarding draft-ietf-bliss-shared-appearances-07, I mentioned that there wa= sn't a clear calling-out of the "fundamental operation" whereby a UA assign= ed an appearance number and the AA confirms the assignment. At that time I= thought that it was done by the UA sending a PUBLISH, and watching for the= AA to send a NOTIFY containing the assignment. But now I think I was wron= g, that the confirmation is done by a success response to the PUBLISH. (Wh= ich means that the PUBLISH must be handled directly by the AA.) The fact that I was confused about this operation means that it isn't descr= ibed specifically in the draft. I think it needs to be described as a sepa= rate, fairly high-level section. Dale From shida@ntt-at.com Tue Apr 19 18:31:08 2011 Return-Path: X-Original-To: bliss@ietfc.amsl.com Delivered-To: bliss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C1322E0820 for ; Tue, 19 Apr 2011 18:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG-wULIxD-Ep for ; Tue, 19 Apr 2011 18:31:07 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfc.amsl.com (Postfix) with ESMTP id D3B4BE081D for ; Tue, 19 Apr 2011 18:31:07 -0700 (PDT) Received: from [221.170.62.9] (port=59361 helo=[192.168.11.11]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QCMG0-0005uP-ED; Tue, 19 Apr 2011 20:31:05 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <9762ACF04FA26B4388476841256BDE020113F82C0956@HE111543.emea1.cds.t-internal.com> Date: Wed, 20 Apr 2011 10:31:02 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110414123003.28126.54267.idtracker@ietfc.amsl.com> <9762ACF04FA26B4388476841256BDE020113F82C0956@HE111543.emea1.cds.t-internal.com> To: bliss@ietf.org X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1ack009.tky.mesh.ad.jp ([192.168.11.11]) [221.170.62.9]:59361 X-Source-Cap: moc.adanga@adihs Cc: JDave Smith Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 01:31:08 -0000 Folks; Please have a look at the proposed changes in the 10_draft_a, if=20 we get no feedback within a week, I will view it as "no objection" and=20= I will proceed with the proto-writeup for this draft. Many Thanks Shida (as a chair) On Apr 14, 2011, at 11:59 PM, = wrote: > Dear colleagues, >=20 > a 09 version of the CC draft was uploaded. This versions includes = corrections (ABNF, wrong example, missing timer), resulting from the 3 = sustantial comments I got during WGLC. Further there are editorials = (spelling corrections, wording clarifications, example clarifications). >=20 >=20 > After WGLC I got comments refelecting different reqirements for CC = running on a device and not on a server in the network, which would = change some SHALLs to SHOULDs, see my last mail to the list. As I said = in my opinion those changes are very useful for a more comprehensive CC = solution, and therefore should be considered. I have therefore provided = a 10_draft_a version of the internet draft. You can check the = differences at >=20 >=20 >=20 > http://bliss-ietf.org/drafts/diff_09_10_draft_a.html >=20 >=20 > = http://bliss-ietf.org/drafts/draft-ietf-bliss-call-completion-10_draft_a.t= xt >=20 >=20 >=20 > Regards, Martin >=20 >=20 >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >> Im Auftrag von Internet-Drafts@ietf.org >> Gesendet: Donnerstag, 14. April 2011 14:30 >> An: i-d-announce@ietf.org >> Cc: bliss@ietf.org >> Betreff: [BLISS] I-D Action:draft-ietf-bliss-call-completion-09.txt >>=20 >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Basic Level of >> Interoperability for SIP Services Working Group of the IETF. >>=20 >>=20 >> Title : Call Completion for Session >> Initiation Protocol (SIP) >> Author(s) : D. Worley, et al. >> Filename : draft-ietf-bliss-call-completion-09.txt >> Pages : 31 >> Date : 2011-04-14 >>=20 >> The call completion features allow the calling user of a >> failed call to be notified when the called user becomes >> available to receive a call. >>=20 >> For the realization of a basic solution without queuing call- >> completion requests, this document references the usage of >> the the dialog event package (RFC 4235) that is described as >> 'automatic redial' in the SIP Service Examples (RFC 5359). >>=20 >> For the realization of a more comprehensive solution with >> queuing call-completion requests, this document introduces an >> architecture for implementing these features in the Session >> Initiation Protocol: >> "Call completion" implementations associated with the >> caller's and callee's endpoints cooperate to place the >> caller's request for call completion into a queue at the >> callee's endpoint, and, when a caller's request is ready to >> be serviced, re-attempt the original, failed call. >>=20 >> The deployment of a certain SIP call-completion solution is >> also dependent on the needed level of interoperability with >> existing call- completion solutions in other networks. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-bliss-call-completion-09.tx= t >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail >> reader implementation to automatically retrieve the ASCII >> version of the Internet-Draft. >>=20