RE: [Sip] INVITE after terminated dialog?
"Zhang, Rocky Fan Wen \(Rocky\)" <firstname.lastname@example.org> Mon, 07 January 2008 03:19 UTC
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 email@example.com; 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 firstname.lastname@example.org; Sun, 06 Jan 2008 22:19:28 -0500
Received: from ihemail4.lucent.com ([18.104.22.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JBiWN-0003fT-V0 for email@example.com; Sun, 06 Jan 2008 22:19:28 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [22.214.171.124]) 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 ([126.96.36.199]) 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 ([188.8.131.52]) by cnexp01.bj.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jan 2008 11:19:09 +0800
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [Sip] INVITE after terminated dialog?
Date: Mon, 7 Jan 2008 11:18:23 +0800
Thread-Topic: [Sip] INVITE after terminated dialog?
From: "Zhang, Rocky Fan Wen \(Rocky\)" <firstname.lastname@example.org>
To: <Dale.Worley@comcast.net>, <email@example.com>
X-OriginalArrivalTime: 07 Jan 2008 03:19:09.0125 (UTC) FILETIME=[112D0750:01C850DC]
X-Scanned-By: MIMEDefang 2.57 on 184.108.40.206
X-Spam-Score: 0.0 (/)
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:email@example.com?subject=subscribe>
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:firstname.lastname@example.org =========================================== -----Original Message----- From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] Sent: Thursday, January 03, 2008 11:17 AM To: email@example.com Subject: Re: [Sip] INVITE after terminated dialog? From: "Jane Jiang" <firstname.lastname@example.org> 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 email@example.com for questions on current sip Use firstname.lastname@example.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 email@example.com for questions on current sip Use firstname.lastname@example.org for new developments on the application of sip