[asterisk-dev] [Code Review] Queue SIP requests/responses that cannot be immediately processed.

[Fernando Urzedo]

Guys,

I have a question for you: will this change be merged with the next (or
a future) 1.4 release? Or it is just a patch I need to apply to my
Asterisk boxes?

Thanks!

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Russell
Bryant
Sent: quarta-feira, 7 de janeiro de 2009 13:50
To: Kevin Fleming; Russell Bryant; Asterisk Developers
Subject: Re: [asterisk-dev] [Code Review] Queue SIP requests/responses
that cannot be immediately processed.

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/117/#review297
-----------------------------------------------------------

Ship it!


I couldn't find any problems.  Nice work.  :)

When updating this code for trunk, it will have to be updated to account
for the fact that sip_pvt is a ref counted object when dealing with the
scheduler entry.  There are a number of other examples of how to do it.


/branches/1.4/channels/chan_sip.c
<http://reviewboard.digium.com/r/117/#comment671>

    We might want to increase the debug level of these messages, or just
remove them completely since they will happen under normal
circumstances, and will be very noisy.


- Russell


On 2009-01-06 19:08:33, Kevin Fleming wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/117/
> -----------------------------------------------------------
> 
> (Updated 2009-01-06 19:08:33)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 167370
> 
> Diff: http://reviewboard.digium.com/r/117/diff
> 
> 
> Testing
> -------
> 
> 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.
> 
> 
> Thanks,
> 
> Kevin
> 
>


_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev