IETF Logo Mail Archive

[dispatch] SIP outbound and in-dialog requests

"Olle E. Johansson" <oej@edvina.net> Mon, 29 April 2013 09:49 UTC

Return-Path: <oej@edvina.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6E21F9D41 for <dispatch@ietfa.amsl.com>; Mon, 29 Apr 2013 02:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf2vUXz91Mm8 for <dispatch@ietfa.amsl.com>; Mon, 29 Apr 2013 02:49:37 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0293E21F9D40 for <dispatch@ietf.org>; Mon, 29 Apr 2013 02:49:35 -0700 (PDT)
Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id C531493C1AF; Mon, 29 Apr 2013 09:49:34 +0000 (UTC)
From: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Apr 2013 11:49:40 +0200
Message-Id: <B2A045DC-1C4E-4380-A228-DCA97247F710@edvina.net>
To: "dispatch@ietf.org list" <dispatch@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [dispatch] SIP outbound and in-dialog requests
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 29 Apr 2013 09:49:37 -0000

In the Kamailio project, we've worked on a registrar and edge-proxy implementation of SIP outbound (RFC 5626) for a while.

We now stumble into the handling of in-dialog requests.

The RFC is clear how to handle dialog-forming requests and failover in regards to these. But it doesn't really say anything
clear on how to handle in-dialog requests in case of a failed flow.

The route set, based on the Path header at registration, now contains a flow token for a failed flow. This route set can
not change, even though we know that we have a secondary flow to the same instance ID that works (another Reg-id).
The dialog has to die since we can not route according to the route set.

I do remember a discussion about this on a SIPit event but don't remember if we found a solution.

Any ideas on how to handle this situation? Anyone working on this issue?

/O

v2.23.0 | Report a Bug | By Email