SIP invite timeout

Short description: SIP invite’s that are not responded to are causing Asterisk to use up all the available RTP ports.

I’m using Dial() to directly send calls to endpoints that are not registered to my asterisk box. If it doesn’t receive a provisional response after sending an invite, Asterisk continues to wait for this forever which ties up the RTP ports that it allocated for the call. Eventually I run out of ports and have to restart asterisk to allow new calls. I have 15,000 ports setup for RTP.

Below is the output of "sip show history " for one of these calls (with the IP changed). The history will only show the last 50 entries, so the calls that have been stuck a while just list out 50 lines of “ReliableXmit timeout”.

  • SIP Call
  1. NewChan Channel SIP/1.2.3.4-000263c2 - from 0b266a293b47563f472b
  2. TxReqRel INVITE / 102 INVITE - -UNKNOWN-
  3. ReTx 1000 INVITE sip:1234@1.2.3.4 SIP/2.0
  4. ReTx 2000 INVITE sip:1234@1.2.3.4 SIP/2.0
  5. ReTx 4000 INVITE sip:1234@1.2.3.4 SIP/2.0
  6. Cancel Cause Unknown
  7. SchedDestroy 32000 ms
  8. DELAY Not sending cancel, waiting for timeout
  9. ReliableXmit timeout
  10. ReliableXmit timeout

[b]Is there a way to set a timeout value to control how long to wait for a response to an invite?

Is there a way to manually kill a SIP channel?[/b]

I’m running Asterisk 1.4.27.1 on CentOS 5.2. I had the same problem with the previous version of Asterisk that was running on this box, SVN-branch-1.4-r214194.

Thanks,

-Justin

There are bug reports about similar symptoms on issues.asterisk.org/

If your problem is not covered by one of these, and you are able to obtain the debugging output required to officially report a SIP problem, you should raise this there.

There is supposed to be a timeout already.

Thanks david55

I’m going to try the fix from issue 0016270 to see if that does the trick.

-Justin

I recompiled with chan_sip.c revision 234095 and it’s no longer bleeding ports.

Fixed.

-Justin