[asterisk-dev] TCP behavior

[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.
> 
> 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.

> 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.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org