Silly question, sorry! A proxy that uses TCP, by definition, must be statefull for this very reason (avoiding the bad scenario below). Now, by induction, one can realize that no matter what type of proxies are along the transaction/(call) path, it should be fine, since the first statefull proxy along the path that "breaks" the reliable transport rule and uses UDP still guarantees retransmission.
In other words, the first hope, which might use a non-reliable transport can be only either the UA or a statefull proxy, thus retransmission (of either requests or 2xx responses for Invite) is guaranteed. Sorry, for this redundant Q&A, but still hopefully someone out there may benefit out of it... (thanks Sudhakar!) Uri ======================================================================= Uri Baniel - Distinguished Member of Technical Staff - Motorola Tel: (847) 632 4616; Fax: (847) 632 3963; "Learning that does not daily increase will daily decrease. - EWC ======================================================================= > -----Original Message----- > From: Baniel Uri-CUB001 > Sent: Thursday, November 21, 2002 11:44 AM > To: [EMAIL PROTECTED] > Subject: retransmissions > > Sorry in advance if this issue has been discussed many times > and the question/answer is obvious. > > According to RFC 3261: 17.1.1.1 and 17.1.2.1 > Requests and/or 2xx responses are being retransmitted ONLY > when unreliable transport is being used. > But what about the following case: > > TCP UDP > UAC-------------stateless proxy----------------------------UAS > > The UAC sends a request, it gets lost on the UDP ifc, and > never retransmitted, same can happen with the response. > > Can that situation indeed happen? > > Uri > > ============================================================== > ========= > Uri Baniel - Distinguished Member of Technical Staff - Motorola > Tel: (847) 632 4616; Fax: (847) 632 3963; > "Learning that does not daily increase will daily decrease. - EWC > ============================================================== > ========= > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
