Subject: [Sip] INVITE after terminated dialog?

From: "Jane Jiang" <[email-masked]>
Date: Mon, 17 Dec 2007 21:22:16 -0800

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?
 
(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?  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?
 
Thanks!
 
Jane
 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 2 Jan 2008 22:16:44 -0500

From: "Jane Jiang" <[email-masked]>

   Hi All,

   I am wondering:

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.

   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

---

From: "Zhang, Rocky Fan Wen \(Rocky\)" <[email-masked]>
Date: Mon, 7 Jan 2008 11:18:23 +0800

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:[email-masked]
===========================================

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, January 03, 2008 11:17 AM
To: [email-masked]
Subject: Re: [Sip] INVITE after terminated dialog?

   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.

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-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip