RE: [Sip] INVITE after terminated dialog?

"Zhang, Rocky Fan Wen \(Rocky\)" <fanwenz@alcatel-lucent.com> Mon, 07 January 2008 03:19 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 1JBiWQ-0002wv-On; Sun, 06 Jan 2008 22:19:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JBiWP-0002pP-7J for sip-confirm+ok@megatron.ietf.org; Sun, 06 Jan 2008 22:19:29 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBiWO-0002lH-RN for sip@ietf.org; Sun, 06 Jan 2008 22:19:28 -0500
Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBiWN-0003fT-V0 for sip@ietf.org; Sun, 06 Jan 2008 22:19:28 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m073JCWe026751; Sun, 6 Jan 2008 21:19:15 -0600 (CST)
Received: from cnexp01.bj.lucent.com ([135.252.8.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Jan 2008 21:19:13 -0600
Received: from CNEXC1U03.BJ.LUCENT.COM ([135.252.8.27]) by cnexp01.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 11:19:09 +0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Sip] INVITE after terminated dialog?
Date: Mon, 7 Jan 2008 11:18:23 +0800
Message-ID: <1F053F0D5C42184B9878C8D79BAE7D1629579D@CNEXC1U03.BJ.LUCENT.COM>
In-Reply-To: <200801030316.m033GiGC020872@dragon.ariadne.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] INVITE after terminated dialog?
Thread-Index: AchNtyoNAqifhia0RDm7lmEQIqiHdgDHzFBQ
From: "Zhang, Rocky Fan Wen \(Rocky\)" <fanwenz@alcatel-lucent.com>
To: <Dale.Worley@comcast.net>, <sip@ietf.org>
X-OriginalArrivalTime: 07 Jan 2008 03:19:09.0125 (UTC) FILETIME=[112D0750:01C850DC]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc:
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

 

It seems you have used TISPAN mode.
I think the reasonable process should be:
- When flashes at endpoint it will send out a INVITE but it is not a
re-INVITE.
- When AS receive this INVITE it should return 200 OK
- The endpoint return a ACK, and the second INVITE is ignored and the
announcement goes on.
 

 
Best Regards,
 
===========================================
Fanwen zhang
FS5000 CPE IOT, Alcatel-Lucent Qingdao, R&D
Tel: +86-532-88615493
Email:fanwenz@alcatel-lucent.com
===========================================

-----Original Message-----
From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] 
Sent: Thursday, January 03, 2008 11:17 AM
To: sip@ietf.org
Subject: Re: [Sip] INVITE after terminated dialog?

   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


_______________________________________________
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