Hi Brett, Thanks a lot for your detailed analysis.
Yes, the proceeding state is big issue to me. It seems spec missed this scenario, I have to retreat to an implementation specific behavior. Best Regards, Caixia On Wed, Jun 18, 2014 at 7:39 PM, Brett Tate <[email protected]> wrote: > 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
