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