IETF Logo Mail Archive

Re: [sipcore] 4028bis: forking

worley@ariadne.com Thu, 28 May 2020 01:59 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09BE3A0A39 for <sipcore@ietfa.amsl.com>; Wed, 27 May 2020 18:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.639
X-Spam-Level:
X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 4RqcerWb99ir for <sipcore@ietfa.amsl.com>; Wed, 27 May 2020 18:59:32 -0700 (PDT)
Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6EF3A0A34 for <sipcore@ietf.org>; Wed, 27 May 2020 18:59:32 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id e7f6jhvT4EK7se7pSjEaB6; Thu, 28 May 2020 01:59:30 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1590631170; bh=Ni3wdmrp5fQ/ed1BIBTEFr3GZsEvM3yAxp62m2H2OuY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gvCf5EPso008/mX8jl4u/TfQE6jGKFWRoYbiOARnG9ACwQV/epI+bLHcrHfSJUfoo 4qt+tYSx+37r0QKR4ioBqzTRNVBTJ0Cwgb9dWRAr3mtIA0FFOlQekHJ5VQocpKOUFr dFy16pFMFl5I+421GMYf8x98I8IC5gNzXXLGd6v/RzJpdWqf/nuOcrI5Na51XDOd3/ v5ft3wJwHE12xhdCQyUjzkgZc/V5RMN/22Mu4ua66K0+ZP6jgkedaktWHp2XKRDBWw lRcChDHpsd+gbnUrRuzr00cBdrlAwQnAqLcsKlklOaJFz3g1oHs3Zm0oNKeSaDHCnX +pMXVa5WfvqTQ==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id e7pQjxCwoNezde7pRjQk9F; Thu, 28 May 2020 01:59:30 +0000
X-Xfinity-VMeta: sc=-100.00;st=legit
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 04S1xRwM017691; Wed, 27 May 2020 21:59:27 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 04S1xP0W017677; Wed, 27 May 2020 21:59:25 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: OKUMURA Shinji <ietf.shinji@gmail.com>
Cc: sipcore@ietf.org, christer.holmberg=40ericsson.com@dmarc.ietf.org
In-Reply-To: <e7963ad4-6423-cf44-1cba-d21536962738@gmail.com> (ietf.shinji@gmail.com)
Sender: worley@ariadne.com
Date: Wed, 27 May 2020 21:59:25 -0400
Message-ID: <87wo4wizuq.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/UFm181nmgHwkUS_11Vkg15h65WI>
Subject: Re: [sipcore] 4028bis: forking
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 28 May 2020 01:59:34 -0000

OKUMURA Shinji <ietf.shinji@gmail.com> writes:
> In following scenario,
> (1) Alice sends INVITE.
> (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol.
> (4) Proxy2 rejects INVITE by 422.
> (6) Carol accepts INVITE by 200.
>
> Eventually Bob never receive INVITE.

True ... but that's acceptable.  Alice sent an INVITE and connected with
one if its destinations.

A more interesting issue is if Carol does not accept the INVITE, and her
UA responds with 487.  Then Proxy1 sees a 422 response from Proxy2 and a
487 from Carol.  If it returns the 487 to Alice, Alice won't update
the session timer.  RFC 3261 sectoin 16.7 item 6 says

         The proxy SHOULD
         give preference to responses that provide information affecting
         resubmission of this request, such as 401, 407, 415, 420, and
         484 if the 4xx class is chosen.

which suggests that 422 should be returned to the UAC, because the UAC
can adjust the request based on it.

Dale

v2.23.0 | Report a Bug | By Email