From rjsparks@nostrum.com Mon Dec 3 12:06:54 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7491921F881F for ; Mon, 3 Dec 2012 12:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CvOFZ+8Xam5 for ; Mon, 3 Dec 2012 12:06:53 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9388721F8817 for ; Mon, 3 Dec 2012 12:06:53 -0800 (PST) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB3K6n8N043558 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 14:06:50 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50BD0659.7070404@nostrum.com> Date: Mon, 03 Dec 2012 14:06:49 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <20121130100739.24517.71787.idtracker@ietfa.amsl.com> <9762ACF04FA26B4388476841256BDE020116952C2A4E@HE111543.emea1.cds.t-internal.com> In-Reply-To: <9762ACF04FA26B4388476841256BDE020116952C2A4E@HE111543.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: bliss@ietf.org Subject: Re: [BLISS] I-D Action: draft-ietf-bliss-call-completion-18.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: Mon, 03 Dec 2012 20:06:54 -0000 I have requested IETF Last Call on this version of the document - watch for its announcement soon. RjS On 11/30/12 4:18 AM, Martin.Huelsemann@telekom.de wrote: > Dear colleagues, > > due to a boilerplate error the 18 version of the CC draft was uploaded, which changes the boilerplate from 'pre-5378' back to 'trust200902' (as it was until the 16 version). > > > Otherwise the 17 version and the 18 version are identical. > > > Best regards, Martin > > > > >> -----Ursprüngliche Nachricht----- >> Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >> Im Auftrag von internet-drafts@ietf.org >> Gesendet: Freitag, 30. November 2012 11:08 >> An: i-d-announce@ietf.org >> Cc: bliss@ietf.org >> Betreff: [BLISS] I-D Action: draft-ietf-bliss-call-completion-18.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) : Dale R. Worley >> Martin Huelsemann >> Roland Jesske >> Denis Alexeitsev >> Filename : draft-ietf-bliss-call-completion-18.txt >> Pages : 37 >> Date : 2012-11-30 >> >> Abstract: >> The call completion feature defined in this specification >> allows the >> caller of a failed call to be notified when the callee becomes >> available to receive a call. >> >> For the realization of a basic solution without queuing, this >> document references the usage of 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, >> this document introduces an architecture for implementing these >> features in the Session Initiation Protocol where "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 of the original, failed call is made. >> >> The architecture is designed to interoperate well with >> existing call- >> completion solutions in other networks. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-bliss-call-completion-18 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-bliss-call-completion-18 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www.ietf.org/mailman/listinfo/bliss >> From iesg-secretary@ietf.org Mon Dec 3 12:38:33 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ECB21F88B1; Mon, 3 Dec 2012 12:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtoEjx9NgsV6; Mon, 3 Dec 2012 12:38:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7321F88BD; Mon, 3 Dec 2012 12:38:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203203832.4334.22117.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 12:38:32 -0800 Cc: bliss@ietf.org Subject: [BLISS] Last Call: (Call Completion for Session Initiation Protocol (SIP)) to Proposed Standard X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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, 03 Dec 2012 20:38:33 -0000 The IESG has received a request from the Basic Level of Interoperability for SIP Services WG (bliss) to consider the following document: - 'Call Completion for Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-12-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of 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, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "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 of the original, failed call is made. The architecture is designed to interoperate well with existing call- completion solutions in other networks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-bliss-call-completion/ballot/ No IPR declarations have been submitted directly on this I-D. From worley@shell01.TheWorld.com Fri Dec 7 13:28:29 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2FC21F8878 for ; Fri, 7 Dec 2012 13:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKKbA+GpHVwT for ; Fri, 7 Dec 2012 13:28:28 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C006721F8799 for ; Fri, 7 Dec 2012 13:28:27 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qB7LSG4c026681 for ; Fri, 7 Dec 2012 16:28:18 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qB7LSFFh2580134 for ; Fri, 7 Dec 2012 16:28:16 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qB7LSF282576958; Fri, 7 Dec 2012 16:28:15 -0500 (EST) Date: Fri, 7 Dec 2012 16:28:15 -0500 (EST) Message-Id: <201212072128.qB7LSF282576958@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: bliss@ietf.org Subject: [BLISS] Last call comments on draft-ietf-bliss-call-completion-18. 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: Fri, 07 Dec 2012 21:28:29 -0000 Fundamentally, I think the draft is in great shape. The only significant change is that I think a summary of the "retain option" procedures and considerations should be added so the reader can see how it affects the procedures (and how gateways to the PSTN handle "retain"). Only items 2 and 19 have technical content; the remainder are editorial. item 1) headers Can you abbreviate my affiliation on the front page to "Ariadne"? If you are using XML2RFC, you can use the 'abrev' attribute of the element: USC/Information Sciences Institute item 2) overall The procedures regarding the retain option are scattered throughout the document in a way that makes it difficult to see how it is handled. It seems to me that it would be helpful to add a summary of retain option processing as a section, perhaps at the end of section 4. This allows deleting the last paragraph of section 4.2, which is vague when it stands alone. 4.5 Summary of retain option procedures When the call completion call fails there are two possible options: the CC feature has to be activated again by caller's agent subscribing to callee's monitor, or CC remains activated and the original CC request remains in the queue. If the callee's monitor operates in the latter way, it is said to support the retain option. Callee's monitors SHOULD support the retain option. If a monitor supports the retain option, it SHOULD provide the cc-service-retention header in its call-completion events. The caller's agent can use this header to know that this monitor supports the retain option. If a callee's monitor does not support the retain option (e.g., if it is a gateway to a network device whose CC functionality does not support the retain option), it SHOULD NOT provide the cc-service-retention header. In addition, after a failed CC call that causes the CC request to be deleted from the queue, the monitor MUST terminate the corresponding agent's subscription to inform the agent that its CC request is no longer in the queue. After a failed CC call, the caller's agent MAY terminate its subscription, to inform the monitor that it is terminating its CC request. After a failed CC call, the caller's agent MAY receive a termination of its subscription from the callee's monitor, if the monitor has terminated the agent's CC request. In either case, the agent MAY create a new subscription (as described in section 6.2) to create a new CC request for the same original call. The agent SHOULD avoid terminating one subscription and creating a new one if the caller's monitor has indicated support of the retain option. I have used SHOULD to describe procedures which are desirable but are not required for correct functioning. In particular, the cc-service-retention value does not have to be correct for a properly-implemented agent and monitor to interact correctly. This gives us some freedom in situations where a gateway cannot discern accurately whether the ultimate callee supports the retain option or not. Pure SIP agents and monitors can implement all the SHOULD behaviors straightforwardly, so in the pure-SIP case, CC is done with the retain option, which is what we want. item 3) section 4.1 The callee's monitor maintains information about the set of INVITEs received by the callee's UA(s) considered unsuccessful by the caller. Strictly speaking, the monitor can't know if an INVITE is considered unsuccessful by the caller. This wording might fix that: The callee's monitor maintains information about the set of INVITEs received by the callee's UA(s) that the caller might consider unsuccessful. item 4) section 4.2 The callee's monitor keeps a list or queue of the caller's agent's subscriptions, representing the requests from the caller's agent to the callee's ---------------------------------------------------^ should be "agents" monitors for call-completion services. ----------^ should be "monitor" item 5) section 4.2 When the callee's monitor determines the callee and/or callee's UA insert "are" here available for a CC call, it selects a caller to execute the CC call and sends a call-completion event update (''cc-state: ready'') via a ---------------------------------------------^^ this should probably use " rather than '' NOTIFY request to the selected caller's agent's subscription, telling it to begin the CC call to the callee's UA. item 6) section 4.2 When the call completion call fails there are two possible options: the CC feature has to be activated again by caller's agent subscribing to callee's monitor, or CC remains activated and the original CC request retains its position in the queue if retain option is supported. This is kinda vague. See item 2. item 7) section 4.3 There is no interaction between call completion and automatic redial, -----------------------------------^ There is a risk of confusion. I think this could be clarified as There is no interaction between automatic redial and call completion (as defined in this document), as they use different event packages and specify different behaviors regarding the events. item 8) section 5 Each CCE has an availability state, determined through caller's presence status at the callee's monitor. A presence status of ''open'' represents CCE's availability state of 'available' and a ---^^ this should probably use " rather than '' presence status of "closed" represents CCE's availability state of 'unavailable'. item 9) section 5 A CCE is identified by the request-URI (if it was taken from a call-completion event --------------^^^^^^^ I think this would be clearer as request-URI of the PUBLISH request (if that URI was taken from a call-completion event item 10) section 5 notification which identifies the CCE) or the From URI of the request (matching the From URI recorded in the CCE). state of the CCE to 'not-available' (suspend). ------------------------^^^^ Other locations in the text use the value 'unavailable'. item 11) section 7.1 The callee's monitor SHOULD insert a URI in the Call-Info header Since the first sentence of the previous paragraph specifies "MUST" regarding inserting Call-Info, this "SHOULD" would be better specified as "MUST". item 12) section 7.1 The 'm' parameter defines the "mode" of call completion. The "m=NR" parameter indicates that it failed due to lack of response, the ----------------------------^^ this "it" should be "the original call" "m=BS" parameter indicates that it failed due to busy subscriber, and -----------------------------------^^ the latter two "it"s are probably unambiguous the "m=NL" parameter indicates that it failed due to non registered ---------------------------------------^^ subscriber (no devices are registered for the AoR contacted). The item 13) section 7.4 The callee's UA(s) and the callee's monitor may give the CC call precedence over non-CC calls by evaluating the presence of the 'm' URI parameter and the From header of the INVITE request. -----------------^^^ I don't think this "and" is correct. One possibility is: The callee's UA(s) and the callee's monitor may give the CC call precedence over non-CC calls by evaluating the presence of the 'm' URI parameter in the From header of the INVITE request. item 14) section 7.5 the retain option and terminate the subscription along with the queue if it doesn't support the retain option. Similarly, if the CC call I think "queue" is supposed to be "CCE". item 15) section 7.5 completion" events, or any URI it returns as the "URI" line of the ---------------------------------------------^^ I think this is supposed to be "in". item 16) section 7.5 The receipt of the PUBLISH request initiates a presence event state for the caller's identity at the presence server functionality of the callee's monitor as specified in [RFC3903] , together with a logical presence server if this has not been done before for another call. Note: The presence server may initiate a presence event state for the caller's identity at the receipt of SUBSCRIBE request as well, dependent on the implementation. These paragraphs do not match the following paragraph from 4.2: Upon receiving a SUBSCRIBE request from the caller's agent, the callee's monitor instantiates a presence state for the caller's UA which can be modified by the caller's UA to indicate its availability for CC call. The status at the presence upon instantiation is "open". Also, this section doesn't explicitly specify what is happening: The first sentences need to say that suspend requests are PUBLISH with status 'closed'. Somewhere in this section it needs to be mentioned that the CCE is set to 'unavailable'. item 17) section 7.6 Similarly to 7.5, the first sentences need to say that suspend requests are PUBLISH with status 'closed'. Somewhere in this section it needs to be mentioned that the CCE is set to 'unavailable'. The final sentence seems to be incorrect in some cases: If the callee is not busy and there is no entry in the CC queue which is currently being processed, the callee's monitor MUST process the queue as described in section 7.3 above. because the callee's policy may not allow any CCE to be recalled at this time. (For example, if a recall for that CCE has recently failed.) Assembling these changes, I think something like this would be better: A CC request is resumed by a PUBLISH request from caller's agent as described in section 6.6, that is, containing a 'state' of 'open'. The presence event state for the caller's identity at the presence server functionality of the CC monitor MUST be updated as described in [RFC3903], and the corresponding CCE's availablity state must be set to 'available'. This may cause the CCE to be selected for recall under the monitor's policy. item 18) section 8 In the second example, I see two uses of "Content-Type: 'app/pidf'". I think this should be spelled out as "Content-Type: application/pidf". For the bodies, I think it would be safer to spell out the PIDF a bit more: | Body: ...open... item 19) section 10.3 The cc-URI line provides a URI (possibly in the form of a name-addr) but it also says cc-URI = "cc-URI" HCOLON addr-spec There are three choices for the syntax of the value of cc-URI: addr-spec this eliminates the possibility of generic-params ("header parameters") name-addr this allows generic-params but requires that we rephrase the first sentences of the section, as a name-addr isn't a URI, strictly speaking. addr-spec / name-addr this alternative is used a lot in headers, but we would have to mention that the rule in RFC 3261 section 20.10 applies: Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the "<". Looking at the old drafts, we changed the value from "(name-addr / addr-spec)" to "addr-spec" in -15. So the ABNF is probably correct. So we should reduce the text of this section to just the first three sentences: The cc-URI line provides a URI (possibly in the form of a name-addr) which the agent SHOULD use as the request-URI of the CC recall INVITE and the suspend/resume PUBLISH. It SHOULD be provided in all NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely identify the CCE in question. item 20) section 12.2 Intended usage: LIMITED USE We could expand this to: Intended usage: Within the procedures of RFC XXXX. item 21) section 12.4 Reference: [RFC3261].[RFC5367][[RFC XXXX]] -----------------------^ I think this is intended to be a comma. Dale From shida@ntt-at.com Sat Dec 8 07:46:15 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABD21F88C7 for ; Sat, 8 Dec 2012 07:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.543 X-Spam-Level: X-Spam-Status: No, score=-100.543 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3p1tQLFzT1I for ; Sat, 8 Dec 2012 07:46:14 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 160A021F8785 for ; Sat, 8 Dec 2012 07:46:13 -0800 (PST) Received: from [125.193.49.76] (port=51133 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1ThMbU-0008MF-3w; Sat, 08 Dec 2012 09:46:12 -0600 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <201212072128.qB7LSF282576958@shell01.TheWorld.com> Date: Sun, 9 Dec 2012 00:46:10 +0900 Content-Transfer-Encoding: 7bit Message-Id: <772B03DC-6911-43BB-BE78-7DD995A07D87@ntt-at.com> References: <201212072128.qB7LSF282576958@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1283) 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-BWhitelist: yes X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.11.3]) [125.193.49.76]:51133 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: bliss@ietf.org Subject: Re: [BLISS] Last call comments on draft-ietf-bliss-call-completion-18. 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: Sat, 08 Dec 2012 15:46:15 -0000 Hi Dale; The draft is going through IETF last call not WGLC so any comments you have should be sent to ietf@ietf.org. Detail review is always welcome but you being a co-author of the draft, these comments I think should have been provided sooner to your co-author or included in the ongoing revision that the draft has undergone. Regards Shida On Dec 8, 2012, at 6:28 AM, Dale R. Worley wrote: > Fundamentally, I think the draft is in great shape. The only > significant change is that I think a summary of the "retain option" > procedures and considerations should be added so the reader can see > how it affects the procedures (and how gateways to the PSTN handle > "retain"). > > Only items 2 and 19 have technical content; the remainder are > editorial. > > item 1) headers > > Can you abbreviate my affiliation on the front page to "Ariadne"? If > you are using XML2RFC, you can use the 'abrev' attribute of the > element: > > > USC/Information Sciences Institute > > > item 2) overall > > The procedures regarding the retain option are scattered throughout > the document in a way that makes it difficult to see how it is > handled. It seems to me that it would be helpful to add a summary of > retain option processing as a section, perhaps at the end of section > 4. This allows deleting the last paragraph of section 4.2, which is > vague when it stands alone. > > 4.5 Summary of retain option procedures > > When the call completion call fails there are two possible options: > the CC feature has to be activated again by caller's agent > subscribing to callee's monitor, or CC remains activated and the > original CC request remains in the queue. > > If the callee's monitor operates in the latter way, it is said to > support the retain option. Callee's monitors SHOULD support the > retain option. If a monitor supports the retain option, it SHOULD > provide the cc-service-retention header in its call-completion > events. The caller's agent can use this header to know that this > monitor supports the retain option. > > If a callee's monitor does not support the retain option (e.g., if > it is a gateway to a network device whose CC functionality does not > support the retain option), it SHOULD NOT provide the > cc-service-retention header. In addition, after a failed CC call > that causes the CC request to be deleted from the queue, the > monitor MUST terminate the corresponding agent's subscription to > inform the agent that its CC request is no longer in the queue. > > After a failed CC call, the caller's agent MAY terminate its > subscription, to inform the monitor that it is terminating its CC > request. After a failed CC call, the caller's agent MAY receive a > termination of its subscription from the callee's monitor, if the > monitor has terminated the agent's CC request. In either case, the > agent MAY create a new subscription (as described in section 6.2) > to create a new CC request for the same original call. The agent > SHOULD avoid terminating one subscription and creating a new one if > the caller's monitor has indicated support of the retain option. > > I have used SHOULD to describe procedures which are desirable but are > not required for correct functioning. In particular, the > cc-service-retention value does not have to be correct for a > properly-implemented agent and monitor to interact correctly. This > gives us some freedom in situations where a gateway cannot discern > accurately whether the ultimate callee supports the retain option or > not. > > Pure SIP agents and monitors can implement all the SHOULD behaviors > straightforwardly, so in the pure-SIP case, CC is done with the retain > option, which is what we want. > > item 3) section 4.1 > > The callee's monitor maintains information about the set of INVITEs > received by the callee's UA(s) considered unsuccessful by the caller. > > Strictly speaking, the monitor can't know if an INVITE is considered > unsuccessful by the caller. This wording might fix that: > > The callee's monitor maintains information about the set of INVITEs > received by the callee's UA(s) that the caller might consider > unsuccessful. > > item 4) section 4.2 > > The callee's monitor > keeps a list or queue of the caller's agent's subscriptions, > representing the requests from the caller's agent to the callee's > ---------------------------------------------------^ > should be "agents" > monitors for call-completion services. > ----------^ > should be "monitor" > > item 5) section 4.2 > > When the callee's monitor determines the callee and/or callee's UA > insert "are" here > available for a CC call, it selects a caller to execute the CC call > and sends a call-completion event update (''cc-state: ready'') via a > ---------------------------------------------^^ > this should probably use " rather than '' > NOTIFY request to the selected caller's agent's subscription, telling > it to begin the CC call to the callee's UA. > > item 6) section 4.2 > > When the call completion call fails there are two possible options: > the CC feature has to be activated again by caller's agent > subscribing to callee's monitor, or CC remains activated and the > original CC request retains its position in the queue if retain > option is supported. > > This is kinda vague. See item 2. > > item 7) section 4.3 > > There is no interaction between call completion and automatic redial, > -----------------------------------^ > There is a risk of confusion. I think this could be clarified as > > There is no interaction between automatic redial and call > completion (as defined in this document), as they use different > event packages and specify different behaviors regarding the > events. > > item 8) section 5 > > Each CCE has an availability state, determined through caller's > presence status at the callee's monitor. A presence status of > ''open'' represents CCE's availability state of 'available' and a > ---^^ > this should probably use " rather than '' > presence status of "closed" represents CCE's availability state of > 'unavailable'. > > item 9) section 5 > > A CCE is identified by the > request-URI (if it was taken from a call-completion event > --------------^^^^^^^ > I think this would be clearer as > > request-URI of the PUBLISH request (if that URI was taken from a > call-completion event > > item 10) section 5 > > notification which identifies the CCE) or the From URI of the request > (matching the From URI recorded in the CCE). > > state of the CCE to 'not-available' (suspend). > ------------------------^^^^ > Other locations in the text use the value 'unavailable'. > > item 11) section 7.1 > > The callee's monitor SHOULD insert a URI in the Call-Info header > > Since the first sentence of the previous paragraph specifies "MUST" > regarding inserting Call-Info, this "SHOULD" would be better specified > as "MUST". > > item 12) section 7.1 > > The 'm' parameter defines the "mode" of call completion. The "m=NR" > parameter indicates that it failed due to lack of response, the > ----------------------------^^ > this "it" should be "the original call" > "m=BS" parameter indicates that it failed due to busy subscriber, and > -----------------------------------^^ > the latter two "it"s are probably unambiguous > the "m=NL" parameter indicates that it failed due to non registered > ---------------------------------------^^ > subscriber (no devices are registered for the AoR contacted). The > > item 13) section 7.4 > > The callee's UA(s) and the callee's monitor may give the CC call > precedence over non-CC calls by evaluating the presence of the 'm' > URI parameter and the From header of the INVITE request. > -----------------^^^ > > I don't think this "and" is correct. One possibility is: > > The callee's UA(s) and the callee's monitor may give the CC call > precedence over non-CC calls by evaluating the presence of the 'm' > URI parameter in the From header of the INVITE request. > > item 14) section 7.5 > > the retain option and terminate the subscription along with the queue > if it doesn't support the retain option. Similarly, if the CC call > I think "queue" is supposed to be "CCE". > > item 15) section 7.5 > > completion" events, or any URI it returns as the "URI" line of the > ---------------------------------------------^^ > I think this is supposed to be "in". > > item 16) section 7.5 > > The receipt of the PUBLISH request initiates a presence event state > for the caller's identity at the presence server functionality of the > callee's monitor as specified in [RFC3903] , together with a logical > presence server if this has not been done before for another call. > > Note: The presence server may initiate a presence event state for the > caller's identity at the receipt of SUBSCRIBE request as well, > dependent on the implementation. > > These paragraphs do not match the following paragraph from 4.2: > > Upon receiving a SUBSCRIBE request from the caller's agent, the > callee's monitor instantiates a presence state for the caller's UA > which can be modified by the caller's UA to indicate its availability > for CC call. The status at the presence upon instantiation is > "open". > > Also, this section doesn't explicitly specify what is happening: The > first sentences need to say that suspend requests are PUBLISH with > status 'closed'. Somewhere in this section it needs to be mentioned > that the CCE is set to 'unavailable'. > > item 17) section 7.6 > > Similarly to 7.5, the first sentences need to say that suspend > requests are PUBLISH with status 'closed'. Somewhere in this section > it needs to be mentioned that the CCE is set to 'unavailable'. > > The final sentence seems to be incorrect in some cases: > > If the callee > is not busy and there is no entry in the CC queue which is currently > being processed, the callee's monitor MUST process the queue as > described in section 7.3 above. > > because the callee's policy may not allow any CCE to be recalled at > this time. (For example, if a recall for that CCE has recently > failed.) > > Assembling these changes, I think something like this would be better: > > A CC request is resumed by a PUBLISH request from caller's agent as > described in section 6.6, that is, containing a 'state' of 'open'. > The presence event state for the caller's identity at the presence > server functionality of the CC monitor MUST be updated as described > in [RFC3903], and the corresponding CCE's availablity state must be > set to 'available'. This may cause the CCE to be selected for > recall under the monitor's policy. > > item 18) section 8 > > In the second example, I see two uses of "Content-Type: 'app/pidf'". > I think this should be spelled out as "Content-Type: application/pidf". > > For the bodies, I think it would be safer to spell out the PIDF a bit > more: > > | Body: ...open... > > item 19) section 10.3 > > The cc-URI line provides a URI (possibly in the form of a name-addr) > > but it also says > > cc-URI = "cc-URI" HCOLON addr-spec > > There are three choices for the syntax of the value of cc-URI: > > addr-spec > this eliminates the possibility of generic-params ("header parameters") > name-addr > this allows generic-params but requires that we rephrase the > first sentences of the section, as a name-addr isn't a URI, strictly > speaking. > addr-spec / name-addr > this alternative is used a lot in headers, but we would have > to mention that the rule in RFC 3261 section 20.10 applies: > > Even if the "display-name" is empty, the "name-addr" form MUST be > used if the "addr-spec" contains a comma, semicolon, or question > mark. There may or may not be LWS between the display-name and the > "<". > > Looking at the old drafts, we changed the value from "(name-addr / > addr-spec)" to "addr-spec" in -15. So the ABNF is probably correct. > So we should reduce the text of this section to just the first three > sentences: > > The cc-URI line provides a URI (possibly in the form of a name-addr) > which the agent SHOULD use as the request-URI of the CC recall INVITE > and the suspend/resume PUBLISH. It SHOULD be provided in all > NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely > identify the CCE in question. > > item 20) section 12.2 > > Intended usage: LIMITED USE > > We could expand this to: > > Intended usage: Within the procedures of RFC XXXX. > > item 21) section 12.4 > > Reference: [RFC3261].[RFC5367][[RFC XXXX]] > -----------------------^ > > I think this is intended to be a comma. > > Dale > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From worley@shell01.TheWorld.com Tue Dec 11 08:49:52 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FDC21F84DE for ; Tue, 11 Dec 2012 08:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y5X1A-X3afx for ; Tue, 11 Dec 2012 08:49:51 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61D21F84DB for ; Tue, 11 Dec 2012 08:49:51 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qBBGn7PI032478; Tue, 11 Dec 2012 11:49:10 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qBBGn6uh2820803; Tue, 11 Dec 2012 11:49:07 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qBBGn6VO2793813; Tue, 11 Dec 2012 11:49:06 -0500 (EST) Date: Tue, 11 Dec 2012 11:49:06 -0500 (EST) Message-Id: <201212111649.qBBGn6VO2793813@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Shida Schubert In-reply-to: <772B03DC-6911-43BB-BE78-7DD995A07D87@ntt-at.com> (shida@ntt-at.com) References: <201212072128.qB7LSF282576958@shell01.TheWorld.com> <772B03DC-6911-43BB-BE78-7DD995A07D87@ntt-at.com> Cc: bliss@ietf.org Subject: Re: [BLISS] Last call comments on draft-ietf-bliss-call-completion-18. 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: Tue, 11 Dec 2012 16:49:52 -0000 > From: Shida Schubert > > The draft is going through IETF last call not WGLC > so any comments you have should be sent to > ietf@ietf.org. > > Detail review is always welcome but you being a > co-author of the draft, these comments I think should > have been provided sooner to your co-author or > included in the ongoing revision that the draft has > undergone. Yes, my apologies, I've not been keeping up and got quite rushed and sloppy. And though I'm an author, I haven't been involved in the editing cycles for at least a year (after the my list of technical issues were resolved). What is the best way for me to proceed? Most of my items are really editorial. One other item has technical content, but I think the real issue is that an edit has not been fully applied. The most significant item is that I think the document would be clearer if a summary of behaviors related to the "retain option" was added. Of course, all of these should be decided by the current authors, but what is the proper process at this point? Dale From internet-drafts@ietf.org Fri Dec 21 12:03:58 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB70A21F841B; Fri, 21 Dec 2012 12:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jzGfoqRGkDy; Fri, 21 Dec 2012 12:03:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B56D21F842A; Fri, 21 Dec 2012 12:03:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121221200358.31134.91565.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 12:03:58 -0800 Cc: bliss@ietf.org Subject: [BLISS] I-D Action: draft-ietf-bliss-shared-appearances-14.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: Fri, 21 Dec 2012 20:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Basic Level of Interoperability for SIP S= ervices Working Group of the IETF. Title : Shared Appearances of a Session Initiation Protocol (SIP= ) Address of Record (AOR) Author(s) : Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan Filename : draft-ietf-bliss-shared-appearances-14.txt Pages : 71 Date : 2012-12-21 Abstract: 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. This specification updates RFC3261 and RFC4235. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bliss-shared-appearances There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bliss-shared-appearances-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bliss-shared-appearances-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fas_vm@surguttel.ru Sun Dec 30 14:40:52 2012 Return-Path: X-Original-To: bliss@ietfa.amsl.com Delivered-To: bliss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0304721F8B30 for ; Sun, 30 Dec 2012 14:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.253 X-Spam-Level: **** X-Spam-Status: No, score=4.253 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_SORBS_WEB=0.619, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd+TcWUsGCYY for ; Sun, 30 Dec 2012 14:40:51 -0800 (PST) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 414AE21F8B28 for ; Sun, 30 Dec 2012 14:40:51 -0800 (PST) Received: by mail.s86.ru (Postfix, from userid 1116) id 5E8B9515F1F; Mon, 31 Dec 2012 04:39:03 +0600 (YEKT) Received: from Gateway (unknown [217.114.191.30]) by mail.s86.ru (Postfix) with ESMTPA id 47E1C51459F for ; Mon, 31 Dec 2012 04:39:00 +0600 (YEKT) Message-ID: <69B8A685D1FE4D8BB2953BECCE62F574@Gateway> From: "Anton Tveretin" To: Date: Mon, 31 Dec 2012 04:40:24 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 121230-0, 30.12.2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [BLISS] draft-ietf-bliss-call-completion-18 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: Sun, 30 Dec 2012 22:40:52 -0000 Hello All, I think that "busy" state (as oppesed to "free" state) is not something absolute. It means "out of resources" but different calls have different resource requirements. A user might be busy to answer a voice call, but fax could be received automatically. A private network with narrowband link might accept just few video calls, yet might more voice calls. Therefore, we should place enough information, preferrably the entire SDP, into subscription (SUBSCRIBE request). Suggestion: 9.3: add, "The SUBSCRIBE body MUST contain the original session description, to provide information about resource requirements." This could be reproduced in Section 5, somewhat like "There are effectively several queues for calls with different resource requirements". 12.2 Why is it application/call-completion, not text/call-completion? Shouldn't charset appear explicitly? I'm afraid of different encoding problems... This MIME type is also more compact. What is about interoperability with RFC 4235? There is none, but IMO this should be explicitly stated somewhere. E.g. in 6.1 or 6.2, "Caller MUST try this procedure first, and if the "call-completion" event package is unsupported, it may attempt complete the call as in RFC 4235". Sorry for being away too long (and cross-posting, if any). Regards, Anton Tveretin