Jonathan, I have read http://lists.bell-labs.com/pipermail/sip/2001q1/006156.html and have a few questions. I would appreciate if you can clarify some of the issues. Note that these issues/questions do not reflect my disagreement with what has been proposed in the above thread. Scenario 1: A proxy, while trying to proxy a provisional response upstream, discovers that it cannot send() using the tcp connection. In other words, the upstream uac/proxy closed the connection. Now, what is the point of continuing the downstream branches when the upstream guy simply closed the connection. Even if one or more good responses are received from downstream, they will never make it upstream. Is it in the hope that when we are ready to send a final response upstream, the upstream proxy/uac may be up again ?? Scenario 2: A proxy, while trying to proxy a final response upstream, discovers that it cannot send() using the tcp connection. Should it simply delete the transaction state at that point. In a related case, what should it do when it is trying to retransmit a non-200 final response upstream and send() fails. Scenario 3: When forking a branch, should a connection refused error on a branch be treated as a 400 class response ? Last, but not the least, I would like to mention that doing a connect() to an ip addr, when the addr is bogus or the box having that address is down, causes connect() to block for several minutes. In case of UDP all send() calls succeed and do not return ECONNREFUSED error. Does anybody have a different experience ? I am asking this because how will the failover mechanisms specified in the spec make sense, if it takes minutes to figure out. Thanks, Shail _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
