Review Board 1.7.16


Queue SIP requests/responses that cannot be immediately processed.

Review Request #117 - Created Jan. 6, 2009 and submitted

Kevin Fleming
1.4
Reviewers
asterisk-dev
Asterisk
When a request or response arrives in sipsock_read(), and the associated sip_pvt has an ast_channel (owner), sipsock_read() attempts to obtain the channel's lock. However, this can fail if the channel is locked by another thread, which could be the case for an extended period of time (multiple microseconds, if not longer). sipsock_read() tries to work around this issue by retrying (up to 100 times) to obtain the lock, but if it still fails, the incoming message is unceremoniously dropped, under the assumption that the other endpoint will retransmit if needed. If this occurs, a message is logged to the console.

As it turns out, this is a rather common occurrence, because when an incoming call is answered via the diaplan, a '200 OK' is sent to the UAC that originated the call, which will likely result in an *immediate* 'ACK' response from the UAC. However, the channel answer process might not actually be completed, especially if it involves creation of translator paths, and so the 'ACK' is dropped, generating an error message and requiring the retransmission of both the '200 OK' and the 'ACK'.

This commit would change sipsock_read() to instead queue requests that cannot be processed immediately; queued requests will be processed either when a timer expires (no more than 10 milliseconds later), or when another request arrives and sipsock_read() was able to obtain the channel lock. In either situation, requests will be processed in the order they were received.
A small amount of testing was done on Shaun Ruffell's transcoder test system, which was exhibiting this problem for every single call that required creation of a transcoder-based translation path. These changes solved his issues regarding SIP message loss and retransmission and did not exhibit any negative effects.
Review request changed
Updated (Jan. 7, 2009, 4:39 a.m.)
Removed LOG_DEBUG messages generated when lock could not be obtained.
Ship it!
Posted (Jan. 7, 2009, 8 a.m.)
Looks good. Shipppppppppppppppp it.

https://reviewboard.asterisk.org/ runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to asteriskteam@digium.com.