Good question. If within Accepted, it would be Timer L. However if within Proceeding, I'm not completely sure what was expected to occur.
The following are a few situations to consider: 1) RFC 3262 sending first reliable 18x. 2) RFC 3262 sending second reliable 18x. 3) Same as 1 however already sent 100. 4) Sending 100. 5) Sending first 18x without having sent prior 100. 6) Sending first 18x after having sent prior 100. 7) Sending periodic non reliable 18x for Timer C reasons. 8) Sending periodic reliable 18x for Timer C reasons. 9) Sending 2xx. The following was the motivation for the changed behavior. "This allows retransmissions of the INVITE to be absorbed instead of being processed as a new request." Thus from an implementation perspective, that is the goal. However if you don't get a better answer here, you might want to ask the sipcore working group. > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Caixia Liu > Sent: Wednesday, June 18, 2014 1:08 AM > To: [email protected] > Subject: [Sip-implementors] A Question about INVITE Server Transaction > in RFC 6026 > > In section "7.1 Server Transaction Impacts, RFC 6026", it has > statements > like this. > > A server transaction MUST NOT discard transaction state based only > on > encountering a non-recoverable transport error when sending a > response. Instead, the associated INVITE server transaction state > machine MUST remain in its current state. (Timers will eventually > cause it to transition to the "Terminated" state). This allows > retransmissions of the INVITE to be absorbed instead of being > processed as a new request. > > > Which timer will eventually cause the server transaction to > transition to the "Terminated" state? > > For example, if the current state is "Proceeding", due to transport > error > we fail > > to send response, the state will remain in "Proceeding" state. There is > no > timer in > > current Server Transaction, so how we eventually make the state > transition > to > > "Terminated" state? > > Best Regards, > > Caixia > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
