[asterisk-dev] TCP behavior

[Klaus Darilion]

Hi Kevin!

Am 08.07.2010 17:51, schrieb Kevin P. Fleming:
> On 07/08/2010 10:38 AM, Klaus Darilion wrote:
>
>> I just made some tests with trunk and SIP over TCP/TLS.
>
> It's important to very clear whether you were testing with TCP or with
> TCP/TLS.

it was TCP

>>
>> I wonder how Asterisk should behave when TCP connections fail. E.g.
>> after registration I killed eyebeam. Thus, a RST packet was sent to
>> Asterisk. Nevertheless the registration will be kept until it expires.
>
> The registration should not be destroyed just because the TCP connection
> gets closed. Plain TCP means Asterisk could open a connection to that
> endpoint when it is required, although this is generally not true for TLS.

I think we should have an option to tell Asterisk if it should try to 
open a new connection if the old one failed. E.g. in case of NATed 
clients it is useless to try to reconnect. E.g. something like
[peername]
outgoingtcp=[no|yes]    ; default: yes

would be useful.

What about Asterisk restarts? I tested and Asterisk deletes the 
registration on restart when the registration was performed via TCP. 
Using UDP, the registration survived the restart. Is this the intended 
behavior?

>> If i now try to call the killed client, Asterisk writes to console:
>>
>>    WARNING[28782]: chan_sip.c:3036 __sip_xmit: sip_xmit of 0xb875fe0 (len
>> 1519) to 83.136.33.3:3558 returned -2: Success
>>
>> but this does not cause a CHANUNAVAIL or similar - Asterisk just keeps
>> waiting for some timeout (really takes a lone time).
>
> The timeouts should be handled very differently for TCP/TLS connections
> than for UDP connections, so yes, this sounds like a bug.
>
>> Shouldn't chan_sip immediately report an error to Dial application if
>> the TCP connection has gone, or TCP send failure happens?
>
> No, it should report a failure when it has determined that it is unable
> to deliver the SIP INVITE to the endpoint; the rules for how that should
> be attempted, what timeouts should exist, how connections should be
> established, etc. are in RFC 3261. It *may* be true that the TCP
> connection being closed means definitively that the INVITE cannot be
> delivered (in which case the dialing operation can terminate
> immediately), or it may not be... depending on the configuration.

In above scenario Asterisk was not trying to establish a new TCP 
connection - it just was waiting -> I will file a bug report.

regards
klaus