Onle last question. You say UAC can send re-INVITE after 2xxx, so but for example UAC sends re-INVITE but UAS not got ACK, so you just get 491 from UAS ? (Otherwise i dont see any point)
I have got much wiser now, like yep, UAC must keep each invite 2xx retransmit timer till it expires. Thanks, indresh singh wrote: > Below are my thoughts > > Regards, > > Indresh K Singh > > On 5/23/07, Ivar <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> After reading rfc multiple times i can't fugure out following: >> If UAC dialog gets 2xx for INVITE, it waits 64 * T1 for 2xx >> retransmissions and send ACK to it. >> Does that mean UAC dialog may not send re-INVITE during that time ? >> > > > It can send a re-INVITE as the session is established at this point of time > and a re-INVITE/UPDATE can be used to modify the session. 64* t1 timer is > being run to ensure that for any reason if there is a retransmission of 2xx > ( for example UAS send 2xx, but got no response, UAC sent the ACK for first > 2xx, but UAS has not received the ACK and it retransmitted another 2xx. Now > the first ACK sent by UAC may get lost in the network, so for the second one > the if the UAC does not respond with an ACK. UAS will not be able to stop > retransmission of his 2xx. > > > >> Or if it's allowed, what happens to timer ? >> > > > After the expiry of 64 * t1 timer expiry on the UAC, retransmission related > resources can be freed in the TU/UAC core and UAC will not be responsible > for sending ACK for any 2xx response recieved afterwards ( could be possible > bcoz of network delays etc ) > > And similar reverse version: > >> UAC dialog waits 2xx retransmissions, >> > > > UAC dialog waits for first 2xx response and sends an ACK. After this if it > receives a re-INVITE it should process it and not respond with 491 and > should separately handle the 2xx retransmission on the previous INVITE-2xx > transaction. > > Similarly on the UAS side if UAS has sent a 2xx response or retransmitted > 2xx response and has received an ACK for a 2xx response, then it can > send/receive a re-INVITE on a separate transaction and if it recieves an ACK > on previous INVITE for next 64 * t1 second it should process it > successfully. > > but UAS dialog send re-INVITE, is > >> it allowed(just kill wait timer) or "491 Request Pending" must be sent. >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
