[asterisk-bugs] [Asterisk 0014401]: dead SIP channels get not cleared though in status SIP_NEEDDESTROY thus are blocking ports
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Feb 6 01:45:26 CST 2009
The following issue has been REOPENED.
======================================================================
http://bugs.digium.com/view.php?id=14401
======================================================================
Reported By: pguido
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14401
Category: Channels/chan_sip/General
Reproducibility: have not tried
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.4.20.1
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-02-04 07:52 CST
Last Modified: 2009-02-06 01:45 CST
======================================================================
Summary: dead SIP channels get not cleared though in status
SIP_NEEDDESTROY thus are blocking ports
Description:
The number of dead channels continuesly increases which then requires a
restart of asterisk to clean up the locked channels and udp ports. The
channels look like:
<client ip> <phone_nr> 5078a9a7133 00102/00001 0x0 (nothing) No
(d) Rx: BYE
<client ip> <phone_nr> 1ebd5e2f7fb 00102/00001 0x0 (nothing) No
(d) Rx: BYE
It seems the qualify=yes option with the sip OPTIONS packet disrupts the
sequence of the call as can be seen in the following trace.
After an INVITE the called phone answers with multiple SDP packets, which
aren't forwarded by asterisk. Instead asterisk sends the OPTION packet to
the calling phone. Only after this handshake is acknowledged asterisk
continues with the call handshake sequence. But during this time the called
phone has already timed out and terminated the call with BYE. Nevertheless
the hold back SDP packets are now forwarded too late to the calling party.
Both phones are within the same client IP behind a NAT Router.
Phone 490 has port 1126. The calling phone has port 1186.
|Time | <IP A> | <Server IP> |
|3200,079 | Request: INVITE sip |SIP/SDP: Request:
INVITE sip:490@<Server IP>;transport=udp, with session description
| |(1186) ------------------> (5060) |
|3200,080 | Status: 100 Trying |SIP: Status: 100
Trying
| |(1186) <------------------ (5060) |
|3200,093 | Request: INVITE sip |SIP/SDP: Request:
INVITE sip:490@<IP A>:1126;transport=udp, with session description
| |(1126) <------------------ (5060) |
|3200,251 | Status: 180 Ringing |SIP: Status: 180
Ringing
| |(1126) ------------------> (5060) |
|3200,251 | Status: 180 Ringing |SIP: Status: 180
Ringing
| |(1186) <------------------ (5060) |
|3210,135 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1126) ------------------> (5060) |
|3210,627 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1126) ------------------> (5060) |
|3211,628 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1126) ------------------> (5060) |
|3213,039 | Request: OPTIONS si |SIP: Request: OPTIONS
sip:458@<IP A>:1186;transport=udp
| |(1186) <------------------ (5060) |
|3213,100 | Status: 200 OK |SIP: Status: 200 OK
| |(1186) ------------------> (5060) |
|3213,627 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1126) ------------------> (5060) |
|3217,627 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1126) ------------------> (5060) |
|3219,213 | Request: BYE sip:06 |SIP: Request: BYE
sip:458@<Server IP>
| |(1126) ------------------> (5060) |
|3219,213 | Status: 200 OK |SIP: Status: 200 OK
| |(1126) <------------------ (5060) |
|3219,500 | Status: 180 Ringing |SIP: Status: 180
Ringing
| |(1186) <------------------ (5060) |
|3221,021 | Status: 200 OK, wit |SIP/SDP: Status: 200
OK, with session description
| |(1186) <------------------ (5060) |
|3221,137 | Request: ACK sip:49 |SIP: Request: ACK
sip:490@<Server IP>
| |(1186) ------------------> (5060) |
|3259,499 | Request: OPTIONS si |SIP: Request: OPTIONS
sip:490@<IP A>:1126;transport=udp
| |(1126) <------------------ (5060) |
|3259,636 | Status: 200 OK |SIP: Status: 200 OK
| |(1126) ------------------> (5060) |
|3273,099 | Request: OPTIONS si |SIP: Request: OPTIONS
sip:458@<IP A>:1186;transport=udp
| |(1186) <------------------ (5060) |
|3273,172 | Status: 200 OK |SIP: Status: 200 OK
| |(1186) ------------------> (5060) |
|3319,635 | Request: OPTIONS si |SIP: Request: OPTIONS
sip:490@<IP A>:1126;transport=udp
| |(1126) <------------------ (5060) |
|3319,707 | Status: 200 OK |SIP: Status: 200 OK
| |(1126) ------------------> (5060) |
|3333,171 | Request: OPTIONS si |SIP: Request: OPTIONS
sip:458@<IP A>:1186;transport=udp
| |(1186) <------------------ (5060) |
|3333,241 | Status: 200 OK |SIP: Status: 200 OK
| |(1186) ------------------> (5060) |
|3346,921 | Request: BYE sip:06 |SIP: Request: BYE
sip:458@<IP A>:1186;transport=udp
| |(1186) <------------------ (5060) |
|3346,986 | Status: 200 OK |SIP: Status: 200 OK
| |(1186) ------------------> (5060) |
This could be related to http://bugs.digium.com/view.php?id=13957
======================================================================
----------------------------------------------------------------------
(0099586) pguido (reporter) - 2009-02-06 01:45
http://bugs.digium.com/view.php?id=14401#c99586
----------------------------------------------------------------------
sip_show channels shows: ast_test_flag(&cur->flags[0], SIP_NEEDDESTROY))
which has value 2.
The change in revision 144420 looks for me that it only works if this flag
is not set. Additionally this is related to a cancel message, which is not
sent in the depicted message flow diagram.
Why does the scheduler not remove the channel? Is it because the dialog is
partially gone? After sending 5 times a SDP A sends at 3219,213 a BYE,
which is OKed by asterisk, so half of the call is gone.
Nevertheless Asterisk sends a RINGING and a SDP starting at 3219,500. So
the second half of the call is just starting.
Does this lead to a situation where the scheduler cannot remove a channel?
Issue History
Date Modified Username Field Change
======================================================================
2009-02-06 01:45 pguido Note Added: 0099586
2009-02-06 01:45 pguido Status closed => new
2009-02-06 01:45 pguido Resolution no change required =>
reopened
======================================================================
More information about the asterisk-bugs
mailing list