IETF Logo Mail Archive

Re: [dispatch] Against RFC 3891 :)

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 26 April 2015 21:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E671A92DD for <dispatch@ietfa.amsl.com>; Sun, 26 Apr 2015 14:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.664
X-Spam-Level:
X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9db36tUon3m for <dispatch@ietfa.amsl.com>; Sun, 26 Apr 2015 14:31:53 -0700 (PDT)
Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3261A0145 for <dispatch@ietf.org>; Sun, 26 Apr 2015 14:31:53 -0700 (PDT)
Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-11v.sys.comcast.net with comcast id LlXi1q0052PT3Qt01lXsY9; Sun, 26 Apr 2015 21:31:52 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id LlXr1q00X3Ge9ey01lXsKx; Sun, 26 Apr 2015 21:31:52 +0000
Message-ID: <553D5947.40500@alum.mit.edu>
Date: Sun, 26 Apr 2015 17:31:51 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <553D4367.14793.165CC40@fas_vm.surguttel.ru>
In-Reply-To: <553D4367.14793.165CC40@fas_vm.surguttel.ru>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1430083912; bh=wF1wzrqt0iPVi1Y7ShQ0TbKeNTA6ETt7dvoG40lwCSw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k4NLVD78/Yyl8j49/vpvHAy17e0XSsLb6OadzeLSgSyI5GZkL4sAbjMBUgYyBJtQH zsPL2Cq2t058vjyczR+7VyX8gJ+J95atAUPU0LY9t+5hRM8SoihjqaKHYmLKS9G6JK GW+DQpOqFLOAFF+1pTVwodce2b7VSGhA5qkOFagildEYJiu0rw6NYBRcyiw3Z6VGi3 hKqeG1+Hn7x/oqJgjeOUKXZFUAiZuXjhLWBTcjnVzWaFAMl0zKG+j6+3GrgUJNEVeb MvjEPW4Yn/KWp+hi2r7zRQ01i+2N7YwOlH0EYx6Jit/hKBpDB2iZdwGqtDVZ20ZFUI pI2XBTYIPNf9w==
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/zFdFy6JkeVVaMUfHBLhUlQevg8Y>
Subject: Re: [dispatch] Against RFC 3891 :)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Apr 2015 21:31:54 -0000

On 4/26/15 3:58 PM, Anton Tveretin wrote:
> Hello All,
> Few more notes about my draft.
> The question is, should the Ctg request the caller (RFC 3891) or the callee to pick up a call?

I'm not sure I understand your question. When you say "pick up a call" 
do you mean:
1) answer the call?
2) initiate a call that will replace the initial one?
3) pay for the call?

If you mean *answer* then the question is nonsense.

If you mean *pay for* then the answer is presumably that the Ctg device 
should choose which one it has sufficient control over. (I guess it 
often will be the case that it doesn't have authorization to control 
them both.)

And I think that is also the answer if you meant *pay for*.

	Thanks,
	Paul

> The former, in addition to charging issues, brings up the following:
> 1. Routing to the caller, which could be hindered by line hunting. I know there is a recently
> published RFC about this.
> 2. Call barring policy at either side.
> 3. Information for the callee only (if it could be). Clearly, this is not possible with RFC 3891. It
> is not specified in draft-worley-sipping-pickup-01, nor in draft-tveretin-dispatch-remote-00, but
> will be in -01 version (Subject: header).
> Of course, I do not want to restrict applicability of the RFC 3891.
> Regards,
> Anton.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

v2.23.0 | Report a Bug | By Email