Re: [Sip] INVITE after terminated dialog?

Dale.Worley@comcast.net Thu, 03 January 2008 03:16 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAGZd-0006tA-I9; Wed, 02 Jan 2008 22:16:49 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JAGZc-0006sv-Vl for sip-confirm+ok@megatron.ietf.org; Wed, 02 Jan 2008 22:16:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JAGZc-0006sn-KM for sip@ietf.org; Wed, 02 Jan 2008 22:16:48 -0500
Received: from qmta01.emeryville.ca.mail.comcast.net ([76.96.30.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JAGZc-0007ml-3S for sip@ietf.org; Wed, 02 Jan 2008 22:16:48 -0500
Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id YLhW1Y00K0lTkoC0A0fX00; Thu, 03 Jan 2008 03:16:47 +0000
Received: from dragon.ariadne.com ([24.34.79.42]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id YTGd1Y00G0umElk8Q00000; Thu, 03 Jan 2008 03:16:39 +0000
X-Authority-Analysis: v=1.0 c=1 a=1uJyfwz8gFoA:10 a=9ADtd9WXbZC9uD0qkyQA:9 a=D72WbAklvw09pl7J47QA:7 a=W4yZHdP6yKHR1c-atV2WCWtEc68A:4 a=8y7tGHue6YMA:10
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id m033Gj5k020876 for <sip@ietf.org>; Wed, 2 Jan 2008 22:16:45 -0500
Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id m033GiGC020872; Wed, 2 Jan 2008 22:16:44 -0500
Date: Wed, 2 Jan 2008 22:16:44 -0500
Message-Id: <200801030316.m033GiGC020872@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
In-reply-to: <DED0424C02C83A4AB0419517605CD11E02F5D329@EXCHANGE-BE2.speakeasy.hq> (janej@hq.speakeasy.net)
Subject: Re: [Sip] INVITE after terminated dialog?
References: <DED0424C02C83A4AB0419517605CD11E02F5D329@EXCHANGE-BE2.speakeasy.hq>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

   From: "Jane Jiang" <janej@hq.speakeasy.net>

   Hi All,

   There is a weird situation with us:
   (1) A Linksys phone sends an INVITE out with incorrect destination TN.
   As a result, our application server will set up a call between the
   Linksys phone and an IVR
   (2) A user incorrectly hits the on-hold key, which is basically sending
   a re-INVITE to the IVR
   (3) Our server seems to have answered the re-INVITE with a BYE
   (4) The Linksys phone responds to the BYE with a 200
   (5) Afterwards, the Linksys phone still thinks that its original
   re-INVITE has not been responded.  So, it will keep resend re-INVITE

   The consequence of these re-INVITEs is a registration migration, which
   we don't like.  We have been trying to figure out which side is not
   following RFC 3261, the phone, the SBCs are wrong, or the application
   servers.

   I am wondering:
   (A) Is it legal for a server to ignore the re-INVITE and respond with a
   BYE and has nothing in between?

The server can legally send a request before responding to a request
it has received.  Indeed, it must be allowed to do so, as from the
protocol point of view that action is indistinguishable from the
network delaying the re-INVITE.

However, the server remains obliged to send a response to the
re-INVITE, as each request is a separate transaction that demands a
response.  In this case, 481 Dialog Usage Does Not Exist seems most
appropriate.

   (B) If a UA has responded to a BYE with 200, is it supposed to forget
   about the re-INVITE request that it has sent out and not try to resend
   the re-INVITE, assuming a dialog has already been terminated with the
   BYE/200 transaction?

In principle, the re-INVITE is a separate transaction and the UA
should complete processing that transaction by re-sending to get a
response (until the time-out).  However, the server cannot enforce
that (as it is possible that the network has lost all sends of the
request), and if the UA decides that it no longer is concerned with
the response the re-INVITE might get, it can give up resending the
re-INVITE.

   Maybe in another sentence, is it legal to send our re-INVITEs
   outside an dialog, even if these re-INVITEs are the repeats of an
   original in-dialog re-INVITE?

A re-INVITE is by definition within a dialog, since a re-INVITE is (by
definition) an INVITE with a to-tag.  However, if the INVITE dialog
usage of the dialog has been terminated (by the server sending the
BYE), the re-INVITE will fail, as you can't create a new INVITE dialog
usage within a dialog that has had one which has been terminated.

Dale


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip