It gets worse: a faulty re-INVITE like the one described will probably not be identified as a retransmission or a fork, since it will probably be received after Timer I fires and the original transaction is "destroyed immediately". (3261 17.2.1)
As a result, TU will create a new transaction, the UAS core will receive the message as a new transaction, will see the empty To tag, and will create a new dialog. So it probably would be seen as a new INVITE in most real world reINVITE cases. -- Brian Badger On Thu, 2005-09-29 at 08:28, Dale R. Worley wrote: > On Thu, 2005-09-29 at 15:15 +0100, Michael Procter wrote: > > In addition, if it isn't a retransmitted initial request, then it > > is probably a forked INVITE and SHOULD be rejected. See RFC3261 > > Section 8.2.2.2 for more details. > > Oops, that's right -- if it has the same call-ID as an ongoing dialog > and the same CSeq as a previous INVITE in the dialog, it's either a > retransmission (same branch-parameter) or another fork (different > branch-parameter). Etc. > > Dale > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
