[sipcore] rfc4244bis #45 (new): 4244bis-02: REFER handling not clear

"sipcore issue tracker" <trac@tools.ietf.org> Sun, 07 November 2010 02:49 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 442B43A69A1 for <sipcore@core3.amsl.com>; Sat, 6 Nov 2010 19:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id AOlkqAspmKJW for <sipcore@core3.amsl.com>; Sat, 6 Nov 2010 19:49:23 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 425443A697B for <sipcore@ietf.org>; Sat, 6 Nov 2010 19:49:23 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1PEvK8-0006Pn-4u; Sat, 06 Nov 2010 19:49:40 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: sipcore issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: hkaplan@acmepacket.com
X-Trac-Project: sipcore
Date: Sun, 07 Nov 2010 02:49:40 -0000
X-URL: http://tools.ietf.org/sipcore/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sipcore/trac/ticket/45
Message-ID: <064.32c7985ec06278ea9918712118d70f22@tools.ietf.org>
X-Trac-Ticket-ID: 45
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, sipcore@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: sipcore@ietf.org
Subject: [sipcore] rfc4244bis #45 (new): 4244bis-02: REFER handling not clear
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2010 02:49:24 -0000

#45: 4244bis-02: REFER handling not clear

 I'm not quite sure what the draft expects of the UA processing a REFER and
 generating a new INVITE from it.  Section 4 says:
    ... A SIP entity changing the target of a
    request in response to a redirect or REFER also propagates any
    History-Info header from the initial Request in the new request.

 Which "initial request"?  The REFER?  The REFER request has its own list
 of H-I, but I don't know what that has to do with the new INVITE going
 out.  Alice calls Bob, Bob calls Charlie; Bob REFERs Charlie to Alice -
 why does Alice care how the REFER reached Charlie?

 Won't it in fact confuse applications to get H-I entries in INVITEs that
 are not in fact the history of the INVITE?  For example, suppose Bob
 called Charlie but his call got redirected to Donna, and then Bob REFERed
 Donna to Alice - wouldn't it confuse Alice to get an INVITE with an H-I
 indicating Charlie was the original target of the INVITE and it got mapped
 to Donna, and that got sent to Alice??

 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  major                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            

Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/45>
sipcore <http://tools.ietf.org/sipcore/>