Thanks, Castillo, In details, that is the following.
Figure 1: Alice Atlanta (INTERNET) Biloxi Bob | | | | |--F1 INVITE-->| | | | |---F2 INVITE--------->| | | | | | | | |--F3 INVITE-->| | | | | | | |<---F4 200------| | |<----F5 200-------------| | |<--F6 200-------| | | |--- F7 ACK---->| | | | |------F8 ACK---------->| | | | |----F9 ACK---->| | | | | In RFC3261, the following is described about retransmission time. --------------RFC3261------------------------------------------------------------------ 17.1.1 INVITE Client Transaction 17.1.1.1 Overview of INVITE Transaction The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. ... -------------------------------------------------------------------------------------------------- In Figure 1 sequence, usually, the time between F4 and F9 may be over 500 ms. Then Bob may often re-transmit 200 OK. If we want to avoid those retransmissions of 200 OK, then what should we do? Yours truly, Tabt, 2011/7/28 Iñaki Baz Castillo <[email protected]>: > 2011/7/28 Couret Tabt <[email protected]>: >> That is to say, >> if we do NOT use B2BUA, >> we need much time to receive ACK for 200 OK, >> especially in Internet. >> Then, we have re-transmitting of 200 OK. >> >> The solution of that is B2BUA. >> Accordingly, most SIP system ( though Internet) >> adopt B2BUA. >> >> Am I right? > > The reasons for using a B2BUA are not "avoiding 200 retransmission". > Retransmissions indeed exist and are 100% covered by RFC 3261 so they > MUST NOT be a problem. > > B2BUA are used to build like-PBX services and so. Also, they don't > "solve retransmissions" always, as typically they send the ACK (for a > 200) in leg B after the ACK arrived from leg A. So the callee could > send 200 retransmissions until it receives the ACK. > > In short, I suggest you to forget that reasoning. > > Regards. > > -- > Iñaki Baz Castillo > <[email protected]> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
