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.
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?
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?
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
_______________________________________________
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
