INVITE after a terminated dialog?

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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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.
>
>But in the meantime there is one fundamental principle
of importance 
>here: every transaction completes independently.

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.


>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://ww
w1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP
Protocol
>Use sip-implementorscs.columbia.edu for
questions on current sip
>Use sippingietf.org for new developments on the
application of sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip