You should read: http://www.ietf.org/internet-drafts/draft-ietf-sipping-race-examples-01.txt
Ivar wrote: > 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 > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
