Hi,
I rephrased the question. Please reconsider.
As depicted by the 'INVITE server transaction' state-machine (Figure 7),
the invite server transaction MUST move to the 'Terminated' state upon
sending 2xx. Moreover, section 17.2.1 instructs that "once the
transaction is in the 'Terminated' state, it MUST be destroyed
immediately".
The following problem arouses:
Consider a session between two UAs denoted A and B. Suppose that A sends
INVITE request to B and B accepts. However, before A receives the 2xx
response from B, it invokes a retransmission of the INVITE. This way, B
receives a retransmission of the INVITE request after responding with
2xx, i.e. after the invite server transaction was terminated.
A B
INVITE----------------------------------------->
-------------------------2xx
INVITE----------------------------------------->
<--------------------
The second INVITE received on B would therefore invoke the creation of a
new invite server transaction (that will be rejected by B since the CSeq
is too small).
How could B prevent from having to create a new server transaction when
it receives the INVITE retransmission?
Thanks,
Tamar Barzuza.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
