Then how would we handle non invite transactions where there's no three way handshake? Consider the MESSAGE method.
How would I handle a retransmitted message? Do I need hold txn state for some time after transmitting 200 OK to absorb any retransmissions? It is important to me to identify a retransmission as I have a quota on the max offline MESSGES I want to forward to my client and with the current problem there is a possibility that my retransmitted messages are considered as new messages. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen van Bemmel Sent: Wednesday, September 28, 2005 1:39 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] Question about receiving ofre-transmissionofinvite at UAS Sayan, That's the one I was looking for, thanks. I remembered that it had been reported as a bug / issue with RFC3261, and I agree that a solution is to (in effect) slightly alter the INVITE server transaction state diagram. Regards, Jeroen ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[email protected]> Sent: Wednesday, September 28, 2005 8:46 AM Subject: RE: [Sip-implementors] Question about receiving of re-transmissionofinvite at UAS > > 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 _______________________________________________ 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
