Thank everybody! Especially thank Brett very much for forwarding this to sipcore!
This issue has been clarified in sipcore forum. Actually this is my misunderstanding. If a server transaction is in proceeding state, and TU hands a 2xx response to server transaction, server transaction should transition to accepted state no matter if there is transport error or not. Best Regards, Caixia On Tue, Jun 24, 2014 at 1:50 AM, Roman Shpount <[email protected]> wrote: > Brett, > > This can probably be handled by timer C. The problem is that very few > clients actually resend the last provisional response every minute to keep > the transaction from expiring on timer C. In practice, application call > timeouts are set to be much less then 3 minutes so that the entire cal gets > hanged up and the whole transaction gets cancelled before timer C ever > fires. My point is, there is a gap in SIP transaction state definition with > INVITE transactions never expiring when in proceeding state, but in > practice this is not a major problem since application call level timers > typically terminate the whole call if it is not answered within reasonable > time. So, this can be fixed but there is very little incentive for real > world implementation to worry or care about this specification change. > > _____________ > Roman Shpount > > > On Mon, Jun 23, 2014 at 7:14 AM, Brett Tate <[email protected]> wrote: > > > Hi Roman, > > > > Transaction state and call state are separate things. However since I'm > > not > > sure what timer (proprietary or RFC defined) sipcore was expecting to be > > used while stuck within Proceeding because of the RFC 6026 requirement, I > > posted the question to sipcore. > > > > It will eventually show up in the archive. > > > > http://www.ietf.org/mail-archive/web/sipcore/current/maillist.html > > > > > > ----- > > > > From: Roman Shpount [mailto:[email protected]] > > Sent: Monday, June 23, 2014 6:06 AM > > To: Caixia Liu > > Cc: Brett Tate; [email protected] > > Subject: Re: [Sip-implementors] A Question about INVITE Server > Transaction > > in RFC 6026 > > > > Caixia, > > > > I do not think specification missed anything. This is quite intentional. > > There is no limit of how long the caller can be dialing the number (as > > there > > is no limit on how long the caller can stay connected on a SIP call). If > > you > > need to put a limit on this duration, this will have to be application > > specific and does not need to be defined in the SIP spec. For instance > you > > can define that dial timeout when placing the call is 1 minute and that > > will > > limit the duration of the proceeding state. Or you can set the dial > timeout > > at 10 minutes. Or you can set this to be unlimited and let the caller > hang > > up when they are done waiting for the call to connect. This is really up > to > > you. The same way you can put maximum call duration at 24 hours and limit > > calls this way or you can let the caller hang up when they are done > > talking. > > _____________ > > Roman Shpount > > > _______________________________________________ > 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
