[asterisk-users] Improving the speed of chan_sip

[Steve Murphy]

On Thu, 2008-08-07 at 18:35 +0200, Pavel Jezek wrote:
> 
> Steve Murphy wrote:
> > Hello--
> >
> > Why do I target chan_sip for so much effort?  Because, 
> > it seems to me, chan_sip is probably the most used channel 
> > driver in the asterisk community!! (and, of course,
> > the zap/dahdi driver, is also pretty popular)
> >
> > I haven't had time to follow up on chan_sip, and I probably 
> > won't for several months. 
> >
> > But, if I had time, here is what I'd do:
> >
> > There are two ways to speed up chan_sip, and they are separate issues,
> > tied together on how many cpu cycles they use up:
> >
> > 1. Call setup/teardown (invites/hangups) -- limits the calls/sec
> > asterisk can handle.
> >   
> 
> one of the big issues in sip callsetup performance, that appears to me 
> in current trunk, is about 500ms delay in propagation SIP/OK message 
> between bridged parties
> eg.: one party answers call, send SIP/OK with SDP to asterisk, asterisk 
> then forwards it to other party, but with unacceptable delay about 500ms!
> this is so much, that users complaining about lost first word of speech 
> communication,
> I posted info about this to bugreport, that seems to be related to this, 
> look at my message:
> http://bugs.digium.com/view.php?id=12708#91173
> I also attach graph picture from wireshark, that clearly ilustrated, 
> where is problem.... (OK-SDP-delay.png )
> PJ

Pavel--

Recently, we found the slowdown that made trunk a LOT slower
on cps ratings than 1.4... And it did indeed point to the INVITE
handling sequence. It involved stripping out a call gethostbyname
in certain circumstances (the one frequently involved when you
use sipp). Putting it back in made trunk and 1.4 run at about the same
speed (the new, better method is a little slower at the moment).

The slowdown involved a call to find_channel_locked code, which ended
up in a fight for a channel lock, in the which it loops and absorbs
a good amount of cpu cycles. This micro-storm of activity was perfectly
timed with the creation of threads in the driver to put a huge dent
in the cps rating. It could easily be, that this sort of activity
is what was causing your bug.

(Now, getting trunk back up to speed with 1.4 is nice, but still,
chan_sip could be faster. I hope, much faster.)

You might try this again, with the current trunk, and see if you still 
suffer the same  delays. If your problem persists, then the bug 
still stands and we'll look at it, I'm sure.

Just updated bug 12708...

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20080807/c0da7106/attachment.bin