Hi Sunil, I think you are wrong.
The server transaction state machine goes only by sending of a 3xx-6xx response into the state COMPLETED and after receiving an ACK into CONFIRMED. But if the TU decides to create a 200 OK, the transaction layer takes the response and passes to the transport layer. After this, retransmission is handled by the TU and the state machine MUST be destroyed. >From RFC 3261 17.2.1 p. 133 "If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not retransmitted by the server transaction; retransmission of 2xx responses are handled by the TU. The server transaction MUST then transition to the "Terminated" state." Greeting Markus Sunil George <[EMAIL PROTECTED]> schrieb am 17.08.04 15:14:11: > > Hi Roman, > > The INVITE server transaction should not terminate when it sends out a > 2xx , it should go into completed state and wait for ACK to go into > CONFIRMED state, then it waits for Timer I before it terminates. This > should handle your issue of retransmitted INVITE's . 500 response should > be sent for the retransmitted invites. > > Regards, > Sunil. > > > > > > [EMAIL PROTECTED] wrote: > > >Hi Roman, > >It seems this UAC is not stopping Timer A after receiving provisional > >response. UAC should not retransmit the invite in "proceeding" state. > >Re-Invite is possible. > >Vivek > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Roman > >Shpount > >Sent: Tuesday, August 17, 2004 4:30 AM > >To: [EMAIL PROTECTED] > >Subject: [Sip-implementors] Problem with an intial SIP INVITE > >servertransaction. > > > > > >I run into the problem with handling of retransmitted SIP INVITE message > >based on the RFC 3621. > > > >Imagine the following situation > > > >INVITE 1 > >-----------------------> > >100 > ><----------------------- > >2XX > ><----------------------- > >re-transmitted INVITE 1 > >-----------------------> > > > >Based on RFC 3261, server INVITE transaction terminates as soon as 2XX > >response is sent. This means that re-transmitted INVITE will be treated > >as a new transaction. This INVITE message will not match the existing > >dialog, since its To tag is empty. This means it will be treated as new > >dialog creating message and phone will treat this message as a new call, > >which is clearly not intended. > > > >___________________________________ > >Roman Shpount, VP of Technology > >aTelo, Inc. -- www.atelo.com > > > > > > > > > > > > > >_______________________________________________ > >Sip-implementors mailing list > >[EMAIL PROTECTED] > >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > >Confidentiality Notice > > > >The information contained in this electronic message and any attachments to this > >message are intended > >for the exclusive use of the addressee(s) and may contain confidential or > >privileged information. If > >you are not the intended recipient, please notify the sender at Wipro or [EMAIL > >PROTECTED] immediately > >and destroy all copies of this message and any attachments. > > > >_______________________________________________ > >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 _______________________________________________________ WEB.DE Video-Mail - Sagen Sie mehr mit bewegten Bildern Informationen unter: http://freemail.web.de/?mc=021199 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
