Hello All , I don't think that's entirely correct. The question here is , what should the UAS Core do if it receives an invite retransmission after the invite transaction has been destroyed(200 OK sent out). The problem is the dialog matching will also fail in the core because the retransmitted invite will not have a to tag ,hence the core will treat it as a new request. One solution is to put the INVITE transaction into a "WAIT" state after the 200 OK has been sent instead of deleting it. This will handle retransmissions.
This has been discussed in the forume some times back. See this thread ... http://www1.ietf.org/mail-archive/web/sip/current/msg11471.html Regards , Sayan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mahipati Deshpande Sent: Wednesday, September 28, 2005 10:19 AM To: [email protected] Subject: Re: [Sip-implementors] Question about receiving of re-transmission ofinvite at UAS Hi Markus, In section 18.2.1 (RFC 3261) mentioned that -- "... If a matching server trasaction is found, the request is passed to that trasaction for processing. If no match is found, request is passed to the core. which may decide to constrcut a new transaction for that request..." So I think is -- This means core is responsible for creating trasaction. so when retransmitted INVITE is received after destroying IST, INVITE request is passed to core, not INVITE trasaction. Core is going to match received request with existing dialog. CSeq of this received request is less than remote sequence number of that dialog, so it is going to reject the request with 500 (section 12.2.2) (...not going to ignore as I told in my previous email) Am I right? Thanks, --- Markus Hofmann <[EMAIL PROTECTED]> wrote: > > Hello Mahipati, > > I think you misunderstand the question. He was asking about a > retransmission of a INVITE. > > In my opinion the transaction layer has no chance to recognize that a > retransmission of an INVITE was received. UAS must create an new > INVITE transaction and give the INVITE to the UA core. The UA core > must now recognize that the INVITE is a retransmission and must > retransmit the 200 OK. This INVITE server transaction will be > destroyed. > > But my problem is, that I do not understand where the bug should be? > > Greeting > > Markus > > > Mahipati Deshpande <[EMAIL PROTECTED]> schrieb am 27.09.05 > 08:10:23: > > > > Hi, > > When a INVITE is received, TU is going to create trasaction. If > > INVITE matches existing trasaction > it > > is considered as re-invite. In your case, for TU, INVITE trasaction > > is still active( it is waiting > for > > ACK). so it is going to treat it as re-invite and ignore it. If > > suppose it had received ACK for 200 > OK > > before retrasmitteed INVITE arrives, TU is going > to > > ignore it because CSeq does not follow the rules. > > > > Thanks, > > Mahipati Deshpande > > > > --- Richard Wu <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi all, > > > Supporse there are a UAC and a UAS. The UAS > receives > > > the an INVITE and > > > creates a IST. It responds with a 200 OK (IST directly goes to the > > > terminated state) and waits for an ACK. At this time, if a > > > re-transmission of invite is received (with the > same > > > branch param in the > > > top via header), what should the UAS do? create > a > > > new IST or ignore it? > > > If there is a solution, does it apply to the re-invite? Thanks in > > > advance > > > > > > Richard Wu > > > ASTRI > > > > > > This message (including any attachments) is for > the > > > named addressee(s)'s use only. It may contain sensitive, > > > confidential, private proprietary or legally privileged > > > information intended for a specific individual and purpose, and is > protected by > > > law. If you are not the intended recipient, please immediately > > > delete it and all copies of > it > > > from your system, destroy any hard copies of it and notify the > > > sender. Any use, disclosure, > copying, > > > or distribution of this message and/or any attachments is strictly > > > prohibited. > > > > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > Mahipati Deshpande > > > > > > > > > __________________________________________________________ > > > Yahoo! India Matrimony: Find your partner now. Go > to http://yahoo.shaadi.com > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > ______________________________________________________________ > Verschicken Sie romantische, coole und witzige Bilder per SMS! > Jetzt bei WEB.DE FreeMail: > http://f.web.de/?mc=021193 > > Mahipati Deshpande Send instant messages to your online friends http://in.messenger.yahoo.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
