On Fri, Jun 15, 2012 at 4:50 AM, Iñaki Baz Castillo <[email protected]> wrote:
> 2012/6/15 Roman Shpount <[email protected]>: > However I do a "trick". If my proxy receives a request retransmission > from a different IP:port, it updates its server transaction > information so responses are now sent to the new IP:port of the UAC. > > So, if in the middle of a transaction the connection is broken and the > UAC reconnects and re-send the request (retransmission) things would > work with my approach. > > This trick relies on the client retransmitting request sent over the reliable transport. AFAIK most of the clients do not do that. Once request is sent over TCP, it is not going to be resent. Furthermore, even if the client is using something similar to UDP rules when retransmitting requests over TCP, it will not resend the INVITE after it receives 100 Trying. Because of this, if the client disconnects between getting 100 Trying and 200 OK for the INVITE (which is in my experience is the most common scenario affected by this issue, simply due to a much longer transaction duration), INVITE is never retransmitted and the client never gets the final response. >From my point of view this is a serious issue and it requires some sort of specification to provide a solution for it. The way we are resolving this is by including GRUU in via parameters from our edge proxy. It works for us, since the same flow is never reused by several GRUUs and we can do GRUU by flow look-up. When edge proxy sends a response back and the original TCP connection is terminated, it detects if another connection was created for this GRUU, and sends the response via this connection. If no connection is present, we queue the response and send it over if client re-registers for this GRUU within certain time. ______________ Roman Shpount _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
