2011/6/11 Roman Shpount :
> I guess, my only issue with your argument is what is considered "connection
> failure" in TCP. I always assumed that this means not being able to
> establish a TCP connection. Connection closure after sending the request is
> not considered an error.
That is a very good
I guess, my only issue with your argument is what is considered "connection
failure" in TCP. I always assumed that this means not being able to
establish a TCP connection. Connection closure after sending the request is
not considered an error. TCP error while sending a request is not an error
and
2011/6/11 Roman Shpount :
> Well, I do not think you are correct. First of all, if UA receives a
> response over the second flow, it should process it properly based on the
> basic SIP specs.
I never contradicted that.
> There is nothing in SIP specifications that implies that
> SIP transaction
Well, I do not think you are correct. First of all, if UA receives a
response over the second flow, it should process it properly based on the
basic SIP specs. There is nothing in SIP specifications that implies that
SIP transaction is associated with a particular TCP connection and should be
termi
2011/6/10 Roman Shpount :
> 1. Client registers and creates two TCP flows to two different edge proxies
> 2. Client sends an INVITE message to edge proxy 1 which responds with 100
> Trying and forwards it through the authoritative proxy to the final
> destination
> 3. Edge proxy 1 restarts and clie
I am looking at implementation of RFC 5626 (SIP-OUTBOUND) and wanted to see
what would be a proper scenario for sending responses for requests received
over a flow which got disconnected before the response was sent. Imagine the
following scenario:
1. Client registers and creates two TCP flows to
