Hi, I would like to point out here that, as and when new message is received, UAS should first check, if it is retransmission of any of the existing transactions, if not, it should ideally check, if it is part of any existing dialog (here dialog matching procedure should of "early dialog", since To-tag would not be present). If it finds a dialog and "remote-cseq" (!!!) matches with the request just received, it should pass this request to TU for processing.
- Harmeet Singh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of KrishnaKanthT 70508 Sent: Friday, June 18, 2004 12:27 AM To: NC Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] One clarification required on INVITE servertransaction Hi, Thanks for the response. I just wanted to confirm my understanding of your point :- According to your suggestion, when the retransmitted INVITE comes to the destination sip entity, it will first do a transaction match. Since it does not match any, it will create a new UAS transaction. After than dialog match is done. At this point UAS core will find that this is a retransmission as cseq number is same as remore cseq number and hence, it will send the 200 OK on that UAS transaction. Since final response is sent, the UAS transaction will be deleted immediately. This process will be repeated for every retransmit of INVITE that arrives at destination sip entity. Is my understanding correct ? Thanks & Regards Krishna ----- Original Message ----- From: NC <[EMAIL PROTECTED]> Date: Thursday, June 17, 2004 2:06 pm Subject: Re: [Sip-implementors] One clarification required on INVITE server transaction > The Session should keep track of the ACK receipt. > > 200 Should be retransmitted by session layer (Session to Transport > bypassing Transaction layer) starting with T1 interval and > doubling with each retransmission until T2 or until the ACK is > received. > If ACK is not received after all the retransmissions, the dialog > is considered to be Confirmed but it should be terminated > immediately by sending a BYE. > > Also, the UAS session should be able to identify the retransmitted > INVITES based on the missing "To tag" as well as the same remote > seq number and retransmit the 200 if an ACK is not yet received. > > Have fun, > NC > > KrishnaKanthT 70508 <[EMAIL PROTECTED]> wrote: > Hi, > > I need one clarification on INVITE server transaction. > > After UAS gets INVITE, when TU sends 2xx response, then UAS > immediately transits to "Terminated" state and gets deleted. From > then onwards, TU will handle the retransmissions of 2xx response > and its corresponding ACK. > > Now, if we assume that, after UAS receives INVITE, the 100 sent by > it is dropped in the network. Similarly when UAS sends 2xx, lets > assume that 2xx is also dropped. Since 2xx is sent, UAS > transaction is deleted. Since UAC has not received any response, > it will again retransmit INVITE. Now, when this retransmitted > INVITE comes to the destination, will a new server transaction be > created. If so, how is this retransmitted INVITE handled?? > > Thanks & Regards > Krishna > > _______________________________________________ > Sip-implementors mailing list [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail Address AutoComplete - You start. We finish. _______________________________________________ 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
