Binu wrote:
> In section 10.3 of the bis-02 draft it is mentioned that if
> the server
> closes a connection prematurely, the client should treat the closure as a
> 500 (Server Internal Error) response. It is also mentioned that the server
> treats closure of connections as a CANCEL for the pending transactions on
> that connection. So if a TCP connection were to break before a transaction
> could be completed, won't the client treat this as a 500 response to the
> request and then receive a "487 Transaction Cancelled" response from the
> proxy server on a passive connection ?
To be honest, I'm slightly confused by this question, but
I'll blunder on as always, anyway. &:)
Basically, the semantics of a "premature" TCP connection close
depends on who was responsible for closing it. A client seeing
a connection close interprets that as a 500 for all transactions
using that connection that have not had received responses.
A server seeing a connection close interprets that as a CANCEL
for all transactions using that connection that have not been
sent final responses.
In your case above, it is the server that is closing the
connection prematurely (at least, that is how I interpret it),
so the client pretends it saw a 500. Probably, the proxy
(or whatever) has died in this case. If the proxy has not
died, then it might be that we're seeing some sort of network
outtage, in which case the proxy will see the close as a
CANCEL, and thus do its normal cancelling magic. (I guess
it's not impossible that the proxy would actively open up
a connection back to the client to return the final response
to the connection, but since it seems reasonable to assume
that this will fail (otherwise, why did the connection close?),
I would imagine that most proxies do not do this.)
> Or is it that the proxy server treats the closure as a
> CANCEL in order
> to cancel pending transactions on the branches but does not respond to the
> client with a "Transaction Cancelled" response for the original request ?
More likely, I think.
[Note that for a proxy, the response should be the result of
all the transaction branches; i.e., not necessary a 487.]
Cheers,
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
