Summary: | ASTERISK-25036: Asterisk still send an INVITE request after a call was canceled(realtime, rtcachefriends is enabled) | ||
Reporter: | Mikhail Fast (mouseratt1) | Labels: | |
Date Opened: | 2015-04-30 03:32:38 | Date Closed: | |
Priority: | Minor | Regression? | |
Status: | Open/New | Components: | Channels/chan_sip/General |
Versions: | 13.0.0 13.1.0 13.2.0 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Debian wheezy x64 | Attachments: | ( 0) ASTERISK-25036.dump ( 1) debug-ASTERISK-25036.log ( 2) full.gz ( 3) sip-conf-ASTERISK-25036.txt |
Description: | Asterisk 13.2
Realtime, rtcachefriends=yes Steps to reproduce a bug: 0) Asterisk has a public IP, cliens A and B connect over NAT. 1) Regiser user A 2) Register user B 3) Unexpectedly disconnect client B (you may kill a proocess or simply disconnect a network cable) 4) Make a call from A to B(B exists in realtime cache, but really it is offline!) 5) Cancel a call 6) Register with a client B again On secondary register you get a call into your sip-client B. In the console you may see, that asterisk still send an INVITE, although a call already was canceled. | ||
Comments: | By: Mikhail Fast (mouseratt1) 2015-04-30 03:49:52.138-0500 sip.conf: context from_anon_sip allowguest no allowoverlap no udpbindaddr 0.0.0.0 transport udp,ws,wss tcpenable no tcpbindaddr 0.0.0.0 tlsenable no srvlookup yes disallow all allow ulaw allow alaw allow g729 allow g723 allow gsm allow speex trustrpid no sendrpid rpid dtmfmode rfc2833 videosupport no maxcallbitrate 384 alwaysauthreject yes rtptimeout 60 rtpholdtimeout 300 allowsubscribe no t38pt_udptl yes,redundancy,maxdatagram=1024 nat force_rport,comedia directmedia no directrtpsetup no rtcachefriends yes rtsavesysname yes rtupdate yes rtautoclear 3600 ignoreregexpire no progressinband never callcounter yes use_q850_reason no defaultexpiry 60 maxexpiry 60 By: Joshua C. Colp (jcolp) 2015-04-30 06:15:08.214-0500 Thanks for the report and debug. However we also need protocol specific debug captured at the time of the issue. Please include the following: * Asterisk log files generated using the instructions on the Asterisk wiki [1], with the appropriate protocol debug options enabled, e.g. 'pjsip set logger on' if the issue involves the chan_pjsip channel driver. * Configuration information for the relevant channel driver, e.g. pjsip.conf. * A wireshark compatible packet capture, captured at the same time as the Asterisk log output. [1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information By: Mikhail Fast (mouseratt1) 2015-05-13 07:07:36.798-0500 This is log of SIP trafic from asterisk in time of a call By: Mikhail Fast (mouseratt1) 2015-05-13 07:09:11.734-0500 I' ve uploaded SIP log from asterisk. Is this enough? By: Kirill Marchuk (62mkv) 2015-05-13 07:28:53.033-0500 by "this is a log of SIP traffic" Mikhail means https://issues.asterisk.org/jira/secure/attachment/52412/debug-ASTERISK-25036.log (IMHO) By: Mikhail Fast (mouseratti) 2015-05-17 21:33:31.673-0500 I'm sorry, but what should I do now? By: Rusty Newton (rnewton) 2015-05-19 19:37:33.334-0500 [~mouseratt1] If an issue is in Triage, you have to wait until a bug marshal is available to triage the issue. :) Can you follow the https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information guide and provide a full log including the "DEBUG" and "VERBOSE" logs both turned up to 5 or above? If possible, also include a packet capture that can be analyzed in wire-shark (tcpdump is probably the easiest way to gather one). Thanks! By: Rusty Newton (rnewton) 2015-05-19 19:37:54.772-0500 Use "Send Back" or "Enter Feedback" to send the issue back. By: Rusty Newton (rnewton) 2015-06-03 15:00:18.025-0500 Mikhail will you be able to provide the information requested? I'm unable to reproduce and can't go further without the debug and packet capture. By: Mikhail Fast (mouseratti) 2015-06-16 07:28:43.284-0500 Full asterisk log in a moment of call By: Mikhail Fast (mouseratti) 2015-06-16 07:35:16.103-0500 I've uploaded full.gz log and ASTERISK-25036.dump tcpdump file By: Rusty Newton (rnewton) 2015-06-24 18:00:58.816-0500 reattaching reporter's sip peer configuration as .txt |