Sorry, Figure1 is the following:
Alice Atlanta (INTERNET) Biloxi Bob | | | | |--F1 INVITE-->| | | | |---F2 INVITE--------->| | | | | | | | |--F3 INVITE-->| | | | | | | |<---F4 200----| | |<----F5 200-----------| | |<--F6 200-----| | | |--- F7 ACK--->| | | | |------F8 ACK--------->| | | | |----F9 ACK--->| | | | | 2011/7/28 Couret Tabt <[email protected]>: > 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
