Subject: [Sip] INVITE after a terminated dialog?

From: "Jane Jiang" <[email-masked]>
Date: Tue, 18 Dec 2007 07:28:05 -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: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Dec 2007 11:16:11 -0500

Jane,

Can you provide a call flow for what is happening? Its a little hard to 
follow from the textual description.

But in the meantime there is one fundamental principle of importance 
here: every transaction completes independently.

> BYE and has nothing in between?

While the BYE may in some way have been provoked by the reINVITE, the 
two are distinct. The reINVITE still needs to be answered with some 
final response which then must be ACKed, and the BYE also needs to be 
responded to.

> of an original in-dialog re-INVITE?

It is not legal to send a *new* reINVITE after the dialog has been 
terminated. But it is appropriate to continue retransmissions if no 
response has been received.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Dec 2007 11:17:32 -0600

> of an original in-dialog re-INVITE?

This is really off-target for this list, and possibly more appropriate
for the sip-implementors list. It just occurred to me that we may also
need something more like a sip-users list for people who are trying to
make off-the-shelf stuff work. Perhaps there is such a list somewhere.

My rather old-fashioned point of view suggests that every device in your
chain is misbehaving.

It seems a bit odd to me that the Linksys phone does a reinvite-to-hold
before it completes the first INVITE transaction, but I'm perhaps
misreading your report. Were there 200 (OK) and ACK messages completing
the transaction of the initial INVITE? Or is the INVITE that the Linksys
resends the reinvite-to-hold? What do the CSeq and SDP of the
retransmitted INVITE look like?

A) It is not reasonable to respond to an INVITE with a BYE. There needs
to be a response message (like 200 or 404 or some other kind of
response) as a result of the INVITE.

B) No, every INVITE transaction needs to be completed by a final response.

B part 2) A re-INVITE sent "outside a dialog" is a new
dialog-establishing INVITE. It should have a new Call-ID. But there are
possibly some odd conditions where not every node in the dialog realizes
a dialog has ended. The dialog-uses doc would be a good thing to look at
here.

--
Dean

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Dec 2007 12:15:46 -0600

At 10:16 AM 12/18/2007, Paul Kyzivat wrote:
>Jane,
>
>Can you provide a call flow for what is happening? Its a little hard 
>to follow from the textual description.
>

I agree with Paul, and add to this that the CSeq value indicates 
which request a 200 OK response is for.  Having the call flow would 
be better to diagnose this, and we might ask that you include some 
SIP headers of each message in the flow (Status line, To, From, CSeq, 
Route, ...) to help further.

>>(2) A user incorrectly hits the on-hold key, which is basically 
>>sending a re-INVITE to the IVR
>>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?
>
>While the BYE may in some way have been provoked by the reINVITE, 
>the two are distinct. The reINVITE still needs to be answered with 
>some final response which then must be ACKed, and the BYE also needs 
>to be responded to.
>
>>(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?
>

---

From: Dan York <[email-masked]>
Date: Wed, 26 Dec 2007 12:11:58 -0500

Getting caught up on list email, I thought I'd point out...

> make off-the-shelf stuff work. Perhaps there is such a list somewhere.

.... that the SIP Forum has a "discussion" mailing list which is for  
general discussion of items related to SIP and recently has had some  
of this type of traffic on the list:

http://sipforum.org/mailman/listinfo/discussion

Good to know about the "sip-implementors" list, too.  I was not aware  
of that one.

Regards,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com