From bliss-bounces@ietf.org Fri Oct 26 15:47:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlV8a-0000mM-Bg; Fri, 26 Oct 2007 15:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlV8Y-00082g-ON for bliss@ietf.org; Fri, 26 Oct 2007 15:46:30 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlV8M-0001l1-Ka for bliss@ietf.org; Fri, 26 Oct 2007 15:46:24 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <200710261945480130092ub5e>; Fri, 26 Oct 2007 19:45:48 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9QJjllW031487 for ; Fri, 26 Oct 2007 15:45:47 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9QJjlGB031483; Fri, 26 Oct 2007 15:45:47 -0400 Date: Fri, 26 Oct 2007 15:45:47 -0400 Message-Id: <200710261945.l9QJjlGB031483@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [BLISS] Call completion X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org draft-poetzl-bliss-call-completion-00 discusses implementing Call Completion services within SIP. Largely, it defines an event package which is used by the caller's agent and the callee's agent to implement orderly Call Completion services. I was invited to add a section to the I-D to describe in more detail the procedures that are involved in Call Completion, which form the context within which the call completion event package is used. Nobody will be surprised that describing call completion exactly took a lot more text than I was expecting, 4 pages, and revealed a number of open questions. So instead of going to the work of integrating my draft text into the rather finished text of draft-poetzl-bliss-call-completion-00, only to have to later make a lot of technical corrections, I decided to float the draft text on its own and get it technically correct before I do the integration work. I've submitted the description of the call-completion mechanism as a separate draft, draft-worley-call-completion-00. You can get it from http://www.ietf.org/internet-drafts/draft-worley-call-completion-00.txt. Please critique it. Call Completion Implementation Details draft-worley-call-completion-00 Abstract This paper gives a detailed discussion of the implementation of "call completion on busy subscriber" and "call completion on no reply" to flesh out the proposed call completion event package. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5 3.1. Caller's Call-Completion Agent . . . . . . . . . . . . . . 5 3.2. Callee's Call-Completion Monitor . . . . . . . . . . . . . 5 3.3. The Original Call Is Made . . . . . . . . . . . . . . . . 6 3.4. Call-Completion Is Invoked . . . . . . . . . . . . . . . . 6 3.5. The Call-Completion Request Is Queued . . . . . . . . . . 8 3.6. Call-Completion Is Activated . . . . . . . . . . . . . . . 8 3.7. Data Provided in the Call-Completion Event Package . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Oct 26 17:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlX5T-0001Ys-7K; Fri, 26 Oct 2007 17:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlX5R-0001Rz-Tt for bliss@ietf.org; Fri, 26 Oct 2007 17:51:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IlX5L-000666-EP for bliss@ietf.org; Fri, 26 Oct 2007 17:51:25 -0400 X-IronPort-AV: E=Sophos;i="4.21,335,1188802800"; d="scan'208";a="243075361" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2007 14:51:08 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9QLp76O003577; Fri, 26 Oct 2007 17:51:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9QLp3dO028337; Fri, 26 Oct 2007 21:51:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 17:51:03 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Oct 2007 17:51:02 -0400 Message-ID: <4722614B.6080802@cisco.com> Date: Fri, 26 Oct 2007 17:51:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Call completion References: <200710261945.l9QJjlGB031483@dragon.ariadne.com> In-Reply-To: <200710261945.l9QJjlGB031483@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Oct 2007 21:51:02.0836 (UTC) FILETIME=[4D7DB740:01C8181A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15506.002 X-TM-AS-Result: No--25.455200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10246; t=1193435467; x=1194299467; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Call=20completion |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=8QgSEwUIg5Igi8MbGOtTWHhP2DXb9Ak35MxEwjZYcZ0=; b=Y7l4c0aHTfA+Wejo4J/DQWy0dugQ9PX5u4ICQ8VcSjJgCoPUx8pQLuSNUzKiZGwggjh5TVzT Wagnc87O9jkXpYtsOy/vPJOcqq4X9NXEr921vdhxP7FubDkSTpZFIVEa; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale, I'm glad to see this! The Poetzl document doesn't stand well as it is, it has way too many assumptions. General comment: There has been extensive discussion on the list of how to map the semantics of the queue at the callee with the subscriptions. I do thing we figured it out, but it remains unclear in this document, and in draft-poetzl-bliss-call-completion-00. The key is that you subscribe to a particular resource, and then the subsequent notifications are about the state of that resource. Initially people were thinking that it was the *queue* that was being subscribed to. Eventually, IIRC, we concluded that the resource needs to be a particular entry in the queue - the entry for a specific callid. That solves many problems. It means you can return a 404 if there is no entry for that callid, whereas a 404 wouldn't make much sense if you were subscribing to the queue. Also, it means that when a particular queue entry change state from "queued" to "ready-for-call-completion" a notify is sent to subscribers for that entry, but not to other subscribers. I don't think anything in your document or Poetzl's is *inconsistent* with this model, but its not clear what the model is, and I expect it needs to be. Section 3.2: The callee's monitor has a method of monitoring the status of the UA(s) to determine when they are in a suitable state to receive a CC call. This state may vary depending on the type of CC call in question. E.g., a UA is available for CCBS when it is not busy, but a UA is available for CCNR when it becomes not busy after being busy with an established call. This monitoring may be achieved by subscribing to the dialog event package of the UA(s) or by other means. Note it is the act of being busy that can be used to infer presence, and the act of becoming unbusy that is assumed to indicate availability for a call completion. This is a very poor means of determining presence, since the callee could be sitting beside the phone for hours without being involved in a call. If some other means of determining presence is available, one would hope it would be used. Its also not entirely reasonable to assume that being busy implies not being available for call completion. With multiple lines, or call waiting, it may be possible to take a call completion even when busy. This is again an issue of presence - another means of determining availability could override this inference. Section 3.4: Question: At this point, it seems that the best choice is that the caller's agent need not determine what type of CC is being requested (CCNR vs. CCBS), as (1) it cannot determine this from the INVITE final response, (2) it would be a burden to make the calling user to specify it, and (3) the callee's monitor can determine this from the responses returned by the callee's UAs. Again, this is all about presence. Regardless of the reason for the original failure, the proper condition for attempting call completion is a high probability that the callee is *present* and *available*. Available is typically inferred based on unbusiness of the phone. Presence is inferred from having recently been busy. The only reason I can see for distinguishing CCNR from CCBS is that CCBS is an assertion by the caller that the callee is present, which CCNR is an assertion by the caller that the callee is not present at that time. If the callee monitor has better information about that, great. These inferences aren't very good in the best of cases, and they break down fast in more complex cases: - As I mentioned above, not being busy is a poor indicator of not being present - the user could be sitting next to the UA but not using it. - the phone being in an invite dialog is not a perfect indicator of unavailability. The user may still want to take the call from the person waiting for completion. - Not being busy is also a poor indicator of being available. Consider someone with multiple phones, or phone with multiple AORs. It can be quite common to hang up from one call and take a call on another line. This may make you unavailable for taking calls on the AOR in question. - The value of the caller assertion (via distinguishing CCBS from CCNR) that the callee is/isn't present degrades with time. Immediately after the call attempt is has some relevance. An hour later it probably has none. All in all, I think the concept ought to be a request to attempt call completion when there is an acceptably high probability that the callee is present and available to answer. Question: Should the specification of the original call be done in the SUBSCRIBE body rather than in an event-param? Conceptually the callid is part of the specification of the resource being subscribed to, rather than being a qualifier to how the subscription is processed. So perhaps it ought to be a URI parameter. But if not that then a parameter to the event type seems better to me. Putting it in the body would imply that it is a filter. The call-completion event package returns various information to the caller's agent, but the vital datum is that it contains an indication whether the callee's monitor has chosen the caller's agent to perform the next CC call to the callee. This datum is initially false. By "initially" do you mean in the initial notification to the subscription? It *could* be true then. Section 3.6 The callee's monitor has a policy regarding when and how it selects CC requests to be activated. This policy may take into account the type of the requests (CCNR vs. CCBS), the state of the callee's UA(s), the order in which the original calls arrived, and any previous CC attempts for the same original call. The order in which subscriptions were received could also be a factor. Question: Should the callee's monitor supply a URI which should be used in the CC call? This seems like it would be more reliable, as the monitor is probably "for" a particular callee URI, and it has no information about the destinations of any other forks of the original call. Yes, I think this is an excellent idea. Question: The CC must be marked in some way as a CC call in order for the callee's monitor to know that the CC activation is being acted upon by the caller's agent. And the marking must include the original Call-Id to allow correlation with the original call. Possibilities for a marking are a special URI-parameter on the request URI or a special header. Its not entirely clear to me that the monitor *needs* to know that this call is a completion for some missed call. What bad thing would happen if it didn't know that? BUT, one way to kill two birds with the same stone would be to provide a URI that routes to the callee monitor, and that references the call to be completed in some way. (This could be encoded in some way that prevents cheating.) The monitor could then forward the call to the appropriate destination, using whatever local tricks are needed to give it the appropriate priority - tricks that aren't available to normal incoming calls. Thanks, Paul Dale.Worley@comcast.net wrote: > draft-poetzl-bliss-call-completion-00 discusses implementing Call > Completion services within SIP. Largely, it defines an event package > which is used by the caller's agent and the callee's agent to > implement orderly Call Completion services. > > I was invited to add a section to the I-D to describe in more detail > the procedures that are involved in Call Completion, which form the > context within which the call completion event package is used. > > Nobody will be surprised that describing call completion exactly took > a lot more text than I was expecting, 4 pages, and revealed a number > of open questions. > > So instead of going to the work of integrating my draft text into the > rather finished text of draft-poetzl-bliss-call-completion-00, only to > have to later make a lot of technical corrections, I decided to float > the draft text on its own and get it technically correct before I do > the integration work. > > I've submitted the description of the call-completion mechanism as a > separate draft, draft-worley-call-completion-00. You can get it from > http://www.ietf.org/internet-drafts/draft-worley-call-completion-00.txt. > Please critique it. > > Call Completion Implementation Details > draft-worley-call-completion-00 > > Abstract > > This paper gives a detailed discussion of the implementation of "call > completion on busy subscriber" and "call completion on no reply" to > flesh out the proposed call completion event package. > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5 > 3.1. Caller's Call-Completion Agent . . . . . . . . . . . . . . 5 > 3.2. Callee's Call-Completion Monitor . . . . . . . . . . . . . 5 > 3.3. The Original Call Is Made . . . . . . . . . . . . . . . . 6 > 3.4. Call-Completion Is Invoked . . . . . . . . . . . . . . . . 6 > 3.5. The Call-Completion Request Is Queued . . . . . . . . . . 8 > 3.6. Call-Completion Is Activated . . . . . . . . . . . . . . . 8 > 3.7. Data Provided in the Call-Completion Event Package . . . . 9 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 > 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 > Intellectual Property and Copyright Statements . . . . . . . . . . 13 > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Oct 29 16:59:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbhB-0001t2-Pk; Mon, 29 Oct 2007 16:58:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImbhA-0001rT-Al for bliss@ietf.org; Mon, 29 Oct 2007 16:58:48 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imbh6-0006zL-0D for bliss@ietf.org; Mon, 29 Oct 2007 16:58:44 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (sccrmhc13) with ESMTP id <200710292047540130093foae>; Mon, 29 Oct 2007 20:47:54 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l9TKlrlW004646 for ; Mon, 29 Oct 2007 15:47:53 -0500 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l9TKlrSQ004642; Mon, 29 Oct 2007 15:47:53 -0500 Date: Mon, 29 Oct 2007 15:47:53 -0500 Message-Id: <200710292047.l9TKlrSQ004642@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <4722614B.6080802@cisco.com> (pkyzivat@cisco.com) Subject: Re: [BLISS] Call completion References: <200710261945.l9QJjlGB031483@dragon.ariadne.com> <4722614B.6080802@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Paul Kyzivat I'm glad to see this! The Poetzl document doesn't stand well as it is, it has way too many assumptions. General comment: There has been extensive discussion on the list of how to map the semantics of the queue at the callee with the subscriptions. I do thing we figured it out, but it remains unclear in this document, and in draft-poetzl-bliss-call-completion-00. Yes, I need to work that through. But initially, the purpose of this I-D is to lay out what the machinery is for doing call-completion, within which the specifics of the subscriptions and of the event package must function. The machinery is implied by a short paragraph in draft-poetzl, and the working-out of it is straightforward, but as always, when you work out the details, you discover things. Such as "The SIP response to the original INVITE tells you almost nothing about call-completion status, because the reponse may not be from the UA that supports call completion." Once the machinery is clarified, it will be time to re-examine the specifics of the subscription mechanism. That's the explanation of what I'm trying to accomplish. Response to your detailed observations to come... Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Oct 29 17:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imc47-00035o-Pv; Mon, 29 Oct 2007 17:22:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imc46-000351-U3 for bliss@ietf.org; Mon, 29 Oct 2007 17:22:30 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imc46-0000Kx-FX for bliss@ietf.org; Mon, 29 Oct 2007 17:22:30 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [24.80.240.54]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l9TLM4mD020563 for ; Mon, 29 Oct 2007 15:22:04 -0600 Message-ID: <47264EF1.40201@ntt-at.com> Date: Mon, 29 Oct 2007 14:21:53 -0700 From: Shida Schubert User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [BLISS] Automatic Handling Survey X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org All; In Chicago, there was a suggestion to take one of the milestones and use it as a guinea pig to evaluate the process described in the problem statement draft for its effectiveness and functionality. Problem Statement: http://tools.ietf.org/html/draft-ietf-bliss-problem-statement-00.txt Amongst the chairs and the technical adviser, we decided to take up the milestone "Automatic Handling" as a guinea pig. The idea was to conduct a phase 1 (Identify a Feature Group) and Phase 2 (Submit Feature Flows) in a small group (Authors and chairs) and contact various vendors to gather information necessary to identify the problem source. After some discussion, we realized that contacting individuals to collect call-flow wasn't as easy as we initially thought it would be due to the time and effort on the individuals part. So, to get a reasonable amount of feedback to make any fruitful conclusions or suggestion(s) that would ultimately solve the interoperability issues, there was an obvious need to lower the threshold for providing information. To do this, we set-up a web form which should take no longer than 5 minutes to complete. Beside BLISS, we are going to ask SIPForum and participants at SIPit to participate in the survery(web form), with which we should get enough feedback to assess the preliminary problem of the space we are dealing with. If you know somebody that can answer the questions better than you please forward the link below. After we have enough information on the statistics of current implementations in the wild, we can then have a in-depth discussion on the list. And come up with a clear definition of problem space(phase 3) as well as recommendation(phase 4). Below is the link to the web-form, I ask for your feedback and I thank you for your time and participation. http://www.bliss-ietf.org/autohandle/?id=27bl01dn22d Regards Shida _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Oct 30 12:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtXl-0006e4-SQ; Tue, 30 Oct 2007 12:02:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtXj-0006du-S6 for bliss@ietf.org; Tue, 30 Oct 2007 12:02:15 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImtXj-0008NR-1k for bliss@ietf.org; Tue, 30 Oct 2007 12:02:15 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Tue, 30 Oct 2007 17:02:11 +0100 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:02:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Call completion Date: Tue, 30 Oct 2007 17:02:10 +0100 Message-Id: In-Reply-To: <200710261945.l9QJjlGB031483@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call completion Thread-Index: AcgYCQIZYYP+iEGhQ1eNc9KZ7NgSfADAwPiw From: "Huelsemann, Martin" To: X-OriginalArrivalTime: 30 Oct 2007 16:02:11.0381 (UTC) FILETIME=[3B062650:01C81B0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale, thank you very much for this work and the time you have taken. A general comment at the beginning, following Paul's comment: The concept is to subscribe to one's call completion state, which can = have the values 'queued' or 'call completions active' (ready for recall = in the current document). The call completion state usually is derived = from the queue-state, if you are in you are queued, if you are at the = top you are ready for recall. Anyway the important information for the = user is that he has some state regarding call-completion, and when he = can start the CC call. Sections 3.1, 3.2. I think there are many possible ways to check the availibity of the = callee to receive a call-completion call as well for the caller to start = a call-completion call. One solution that probably crosses one's mind at = once is the dialog event package. Anyway I think we shouldn't be to = explicit on that, there are many ways to implement this.=20 This applies in particular for the availibility of the callee. As Paul = said, at some time the state of the callee changes to a state where 'an = acceptably high probability that the callee is present and available to = answer' to a CC call from a certain user (where CC is active) is = reached. CC informs the caller about that state change. Question: Should the specification of the original call be done in the SUBSCRIBE body rather than in an event-param? As Paul said it's a specification of the resource so a URI parameter = would be a good solution. Could the Target-dialog header also be used = for this? Section 3.6 Question: Is that last statement true? Can a call appear to succeed from the monitor's point of view but fail from the calling user's point of view? I think we have to be pragmatic at some point not to let CC become too = complex. I suggest the monitor's point of view should be the criteria if = CC was successful. Section 3.7 The important CC information is if you are queued, and if you shall = start the CC call. And the service retention information to inform the = user if he is still in the CC queue when the CC call has failed, = depending on the CC implemention. It is also needed for interoperability = reasons. Again thanks a lot. BR, Martin > -----Urspr=FCngliche Nachricht----- > Von: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Gesendet: Freitag, 26. Oktober 2007 21:46 > An: bliss@ietf.org > Betreff: [BLISS] Call completion >=20 >=20 > draft-poetzl-bliss-call-completion-00 discusses implementing Call > Completion services within SIP. Largely, it defines an event package > which is used by the caller's agent and the callee's agent to > implement orderly Call Completion services. >=20 > I was invited to add a section to the I-D to describe in more detail > the procedures that are involved in Call Completion, which form the > context within which the call completion event package is used. >=20 > Nobody will be surprised that describing call completion exactly took > a lot more text than I was expecting, 4 pages, and revealed a number > of open questions. >=20 > So instead of going to the work of integrating my draft text into the > rather finished text of draft-poetzl-bliss-call-completion-00, only to > have to later make a lot of technical corrections, I decided to float > the draft text on its own and get it technically correct before I do > the integration work. >=20 > I've submitted the description of the call-completion mechanism as a > separate draft, draft-worley-call-completion-00. You can get it from > http://www.ietf.org/internet-drafts/draft-worley-call-completi on-00.txt. Please critique it. Call Completion Implementation Details draft-worley-call-completion-00 Abstract This paper gives a detailed discussion of the implementation of "call completion on busy subscriber" and "call completion on no reply" to flesh out the proposed call completion event package. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5 3.1. Caller's Call-Completion Agent . . . . . . . . . . . . . . 5 3.2. Callee's Call-Completion Monitor . . . . . . . . . . . . . 5 3.3. The Original Call Is Made . . . . . . . . . . . . . . . . 6 3.4. Call-Completion Is Invoked . . . . . . . . . . . . . . . . 6 3.5. The Call-Completion Request Is Queued . . . . . . . . . . 8 3.6. Call-Completion Is Activated . . . . . . . . . . . . . . . 8 3.7. Data Provided in the Call-Completion Event Package . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Oct 30 12:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtkJ-0003ZK-Df; Tue, 30 Oct 2007 12:15:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImtkI-0003ZD-46 for bliss@ietf.org; Tue, 30 Oct 2007 12:15:14 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImtkH-0000Jx-Kq for bliss@ietf.org; Tue, 30 Oct 2007 12:15:14 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Tue, 30 Oct 2007 17:15:12 +0100 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Oct 2007 17:15:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Call completion Date: Tue, 30 Oct 2007 17:15:10 +0100 Message-Id: In-Reply-To: <4722614B.6080802@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call completion Thread-Index: AcgYGn5V486T21HQSLO51prasDo5UgC55C8g From: "Huelsemann, Martin" To: , X-OriginalArrivalTime: 30 Oct 2007 16:15:11.0724 (UTC) FILETIME=[0C250AC0:01C81B10] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > Question: The CC must be marked in some way as a CC call=20 > in order for > the callee's monitor to know that the CC activation is being acted > upon by the caller's agent. And the marking must include the > original Call-Id to allow correlation with the original call. > Possibilities for a marking are a special URI-parameter on the > request URI or a special header. >=20 > Its not entirely clear to me that the monitor *needs* to know=20 > that this=20 > call is a completion for some missed call. What bad thing=20 > would happen=20 > if it didn't know that? If there are still entries in the queue the callee's monitor shouldn't = accept calls without this CC indication. Otherwise there could be the = situation that immediately after the callee has become available there = are other calls which are answered then, and the user who requested CC = will never have a chance to complete the call. BR, Martin _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Oct 30 14:17:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImveH-0004x4-5s; Tue, 30 Oct 2007 14:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImveF-0004wz-Sd for bliss@ietf.org; Tue, 30 Oct 2007 14:17:07 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImveE-0006Yf-1f for bliss@ietf.org; Tue, 30 Oct 2007 14:17:07 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="541391353" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2007 11:16:50 -0700 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIGnMH010206; Tue, 30 Oct 2007 14:16:49 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIGbdg021308; Tue, 30 Oct 2007 18:16:51 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:16:46 -0400 Received: from [161.44.174.216] ([161.44.174.216]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:16:46 -0400 Message-ID: <4727750D.8070102@cisco.com> Date: Tue, 30 Oct 2007 14:16:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Huelsemann, Martin" Subject: Re: AW: [BLISS] Call completion References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Oct 2007 18:16:46.0084 (UTC) FILETIME=[07EC0C40:01C81B21] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--22.176100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1295; t=1193768209; x=1194632209; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20AW=3A=20[BLISS]=20Call=20completion |Sender:=20 |To:=20=22Huelsemann,=20Martin=22=20; bh=2OxJTseDfygSQtugDr8JFi1Wjwj5I07YoApxqUnyBAo=; b=U9NIqIL8BVsrNWVi4f1OMjosFXWqNZ1Fe+i9FF2ppJzVOdnYOFp1oY3UOaKuqfZlo7Ekwadg 0mabGXv5ZRhLflaRtE4Ud1DOlvS34TgqRyMCkurDXkiPmqBsQQQ95gk9; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Huelsemann, Martin wrote: > >> Question: The CC must be marked in some way as a CC call >> in order for >> the callee's monitor to know that the CC activation is being acted >> upon by the caller's agent. And the marking must include the >> original Call-Id to allow correlation with the original call. >> Possibilities for a marking are a special URI-parameter on the >> request URI or a special header. >> >> Its not entirely clear to me that the monitor *needs* to know >> that this >> call is a completion for some missed call. What bad thing >> would happen >> if it didn't know that? > If there are still entries in the queue the callee's monitor shouldn't accept calls without this CC indication. Otherwise there could be the situation that immediately after the callee has become available there are other calls which are answered then, and the user who requested CC will never have a chance to complete the call. You are making an assumption about the "monitor" that Dale didn't make: You are assuming that calls flow through it before reaching the callee, and that the monitor can thus prevent those from being accepted. If that is a key part of the mechanism then it needs to be specified somewhere. Thanks, Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Oct 31 05:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InAFE-0002rw-Gb; Wed, 31 Oct 2007 05:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InAFC-0002pp-Oo for bliss@ietf.org; Wed, 31 Oct 2007 05:52:14 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InAF7-0003fJ-FM for bliss@ietf.org; Wed, 31 Oct 2007 05:52:14 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1InAFG-0003yu-7y for bliss@ietf.org; Wed, 31 Oct 2007 02:52:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 31 Oct 2007 02:52:01 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011CE1FBDA@sea02-mxc01.citel.com> In-Reply-To: <0D4E483A0E6E0A46861409E5D6C2011CBC16DD@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notification/warning: call diversion active thread-index: Acf2Dc5SYYg5A8DJSKS8mAEu8+G/NwEnGuzQAAIFrfAIPEFPMA== References: <46E94151.9090000@cisco.com><0D5F89FAC29E2C41B98A6A762007F5D02CFE6C@GBNTHT12009MSX.gb002.siemens.net> <0D4E483A0E6E0A46861409E5D6C2011CBC16DD@sea02-mxc01.citel.com> From: "Steve Langstaff" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [BLISS] Re: notification/warning: call diversion active X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org [Sorry to follow up my own post, but I happened to have it handy!] Did the discussion on "Call-Diversion active" SUBSCRIBE/NOTIFY come to any conclusion? > -----Original Message----- > From: Steve Langstaff [mailto:steve.langstaff@citel.com]=20 > Sent: 19 September 2007 12:51 > To: Elwell, John; Paul Kyzivat; Huelsemann, Martin > Cc: bliss@ietf.org > Subject: RE: AW: AW: [BLISS] Re: notification/warning: call=20 > diversion active >=20 > I like the SUBSCRIBE/NOTIFY proposal - it seems to be the=20 > right tool for the job. >=20 > Might I suggest that we take a leaf out of RFC3842, and have=20 > (at least) a boolean indication that there is some sort of=20 > call diversion active? >=20 > E.g. where RFC3842 says: > "The status line allows messaging systems or messaging=20 > gateways to provide the traditional boolean message waiting=20 > notification. >=20 > Messages-Waiting: yes > " >=20 > BLISS-CALL-DIVERSION could say: > "The status line allows call handling systems to provide the=20 > traditional boolean call diversion notification. >=20 > Call-Diversion: yes > " >=20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 19 September 2007 12:00 > > To: Paul Kyzivat; Huelsemann, Martin > > Cc: bliss@ietf.org > > Subject: RE: AW: AW: [BLISS] Re: notification/warning: call=20 > diversion=20 > > active > >=20 > > Catching up after being away. > >=20 > > I seem to sense a consensus that there is a requirement for=20 > a UA to be=20 > > aware of the status of call forwarding unconditional (or=20 > maybe various=20 > > types of conditional call forwarding too, although that seems to be=20 > > outside the scope of the present thread). It can then use this=20 > > information to advise the user in whatever way is=20 > appropriate. To me,=20 > > things like stutter dial tone or other indications at the time of=20 > > outgoing call establishment are old fashioned - for a long=20 > time I have=20 > > had phones on my desk that permanently indicate my call forwarding=20 > > status. Indeed I very rarely hear dial tone, let along stutter dial=20 > > tone, because I dial from an address book or hot key or missed call=20 > > list, or failing that I key my digits before going "off-hook" (or=20 > > activating headset or speakerphone or whatever). My cellphone never=20 > > gives me dialtone. So PLEASE let's leave the UI to the UA, and just=20 > > consider how the UA becomes aware of the information. > >=20 > > So if this is the requirement (to keep the UA informed), let's=20 > > consider solutions. > >=20 > > I have a certain sympathy with Martin Huelsemann's=20 > contention that a=20 > > SUBSCRIBE/NOTIFY mechanism is too heavy in signalling. > > For example, dialog-stateful proxies / B2BUAs seem to be=20 > sensitive to=20 > > lots of long-term dialogs from every UA. > >=20 > > I like the idea of a URN, but I don't really like putting it=20 > > Alert-Info in a response to INVITE, for all the reasons stated by=20 > > various contributors to this thread. > >=20 > > What about a REFER request, referring to a URN that indicates call=20 > > forwarding status? URN parameters could even indicate=20 > conditions, if=20 > > we need to extend this to conditional call forwarding. Something=20 > > similar has been proposed by others in the past in the context of=20 > > remote call control. > >=20 > > John >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss