This is a bug in the spec. though I don't think it has been filed yet. There is a suggestion to keep the INVITE server transaction in a "wait" state... please see the following thread. http://www1.ietf.org/mail-archive/web/sip/current/msg11471.html
Thanks Nasir Khan BEA Systems, Inc >Message: 2 >Date: Thu, 26 May 2005 15:28:38 -0700 >From: "Anil Bollineni" <[EMAIL PROTECTED]> >Subject: [Sip-implementors] About Invite Server transaction >To: <[email protected]>, <[email protected]> >Message-ID: <[EMAIL PROTECTED]> >Content-Type: text/plain; charset="us-ascii" > >Hi, > > Assume 100, 200 responses are sent from UAS to client, and >they are lost. Then INVITE is retransmitted to UAS. As soon as UAS send >200 OK it destroys the server transaction. Per UAS, the dialog state is >already created after sending 200 response. If INVITE is passed to TU >from transport layer, then how this INVITE is been treated as >retransmission of INVITE, since the TU, will not able to match any >existing dialog (since no to-tag in INVITE), and will it treat as a new >call. Is the assumption correct? Or where in RFC this scenario will be >treated. > >Thanks, > >Anil _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
