[Sipping] rfc5359 vs. sipping-cc-transfer: Blind/Unattended Transfer Question
Luca Scheuring <lscheuring.biz@gmail.com> Wed, 11 February 2009 21:13 UTC
Return-Path: <lscheuring.biz@gmail.com>
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E323A659C for <sipping@core3.amsl.com>; Wed, 11 Feb 2009 13:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbjd+0KeFDIA for <sipping@core3.amsl.com>; Wed, 11 Feb 2009 13:13:30 -0800 (PST)
Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 5B81F3A69C9 for <sipping@ietf.org>; Wed, 11 Feb 2009 13:13:30 -0800 (PST)
Received: by fxm13 with SMTP id 13so1213771fxm.13 for <sipping@ietf.org>; Wed, 11 Feb 2009 13:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=yVIqCOYQYmC88KAug1zXvPWLud41macrNieCGSuRzng=; b=Vw0TkuzhchmQ50ZDAyRXxZs2K3n6HG/8nrJGncwAKbS++00WLkCtmn4f89d5H+Ucus Ny9WIRs0VPXAzI4c+6LXqL/Kf0CYRGMgc6mn1GQlMq/OKQzHTdSH/SBXxCUM5CTkIfKI 5AvYz7f1PsafriJqBUgAezZbM33ZnNTXNh9tE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=gt2OyD8xHoiafJHWqM5p2HVCnR42Jtp2M2U+SalfkYu9oDxjGEnwYimK/Q3tYN+pt+ YdpgNYtOfip6894M5NpVAZzUNZ6ttgCPYAlvn+IulpDMsVaDJjIUSrQww81fcPRVVpJ3 Vq+a32QfGcBdRNVGhsSzCQ6F6nqFB3MV7uFWo=
MIME-Version: 1.0
Received: by 10.86.91.3 with SMTP id o3mr937221fgb.60.1234386814048; Wed, 11 Feb 2009 13:13:34 -0800 (PST)
Date: Wed, 11 Feb 2009 22:13:32 +0100
Message-ID: <972e86e20902111313n103b79fewfa0cb1909a1a64c4@mail.gmail.com>
From: Luca Scheuring <lscheuring.biz@gmail.com>
To: sipping@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [Sipping] rfc5359 vs. sipping-cc-transfer: Blind/Unattended Transfer Question
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2009 21:13:31 -0000
Hi, In the call flow for unattended transfer shown in rfc5359 section 2.4 the transferor (Alice) sends the BYE (F9) right after receiving the NOTIFY (100 Trying) (F7) from the transferee (Bob). Statement from draft-ietf-sipping-cc-transfer-11 section 6 / page 7: [...] Each of the flows below shows the dialog between the Transferor and the Transferee remaining connected (on hold) during the REFER process. While this provides the greatest flexibility for recovery from failure, it is not necessary. If the Transferor's agent does not wish to participate in the remainder of the REFER process and has no intention of assisting with recovery from transfer failure, it could emit a BYE to the Transferee as soon as the REFER transaction completes. This flow is sometimes known as "unattended transfer" or "blind transfer". [...] The last sentence implies that if the transferor _wants_ to participate in the remainder of the REFER process (and therefore waits with sending the BYE until another NOTIFY with "200 OK" has been received) this is called attended transfer. But both rfc5359 and draft-ietf-sipping-cc-transfer-11 define "attended transfer" as a transfer where the transferor establishes a call with the transfer target to alert it to the impending transfer. Can somebody clarify this issue? This question came up when analyzing problems that occur if Alice/transferor is an agent that remains in the transfer process until NOTIFY with "200 OK" is received (in order to offer the possibility to un-hold call to Bob/transferee again in case transfer target doesn't reply / declines the call) while Bob/transferee is an agent who expects a call flow as described in rfc5359 section 2.4. Observed problem: Alice is on a call with Bob and then wants to attempt an unattended/blind transfer to Carol. Carol's phone is ringing, but no answer yet. Alice thinks Carol won't answer and therefore un-holds the call to Bob in order to recover. Alice and Bob are in communication again, but Bob is still calling Carol. If Carol finally answers, Bob doesn't know how to handle this session. Call from Bob to Carol ends up as a "phantom call" at Bob that cannot be terminated by Bob. Thanks, Luca
- [Sipping] rfc5359 vs. sipping-cc-transfer: Blind/… Luca Scheuring
- Re: [Sipping] rfc5359 vs. sipping-cc-transfer: Bl… Valentin Nechayev