Summary: | ASTERISK-17303: Asterisk doesn't respond ACK to 200 OK retransmission | ||
Reporter: | Andrey Solovyev (corruptor) | Labels: | |
Date Opened: | 2011-01-28 09:10:42.000-0600 | Date Closed: | 2014-03-05 07:34:35.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) retr_bug ( 1) uas_retr.xml | |
Description: | It's written in SIP RFC 13.2.2.4 2xx Responses ..The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. This probably is not an issue. I've noticed that asterisk doesn't send ACK when phone retransmitts OK. I've made a scenario for SIPp to reproduce this issue (it;s attached as uas_retr.xml). SIPp works in UAS mode and after receiving ACK it sends another OK to check if asterisk retransmitts ACK but asterisk just ignores this OK. I've attached full asterisk debug log also. Sorry if am wrong. I might not understand SIP RFC correctly or have done wrong scenario. ****** ADDITIONAL INFORMATION ****** To repruduce just run on testhost1 'sipp -sf uas_retr.xml -i [testhost1_ip]' and make call from asterisk to SIP/testhost1_ip. | ||
Comments: | By: Andrey Solovyev (corruptor) 2011-01-28 09:16:05.000-0600 Oops. The Summary shoud state "Asterisk doesn't repsond ACK to OK retransmission". By: marvy (marvy) 2011-01-30 21:13:40.000-0600 I can confirm this is an issue with 1.6.2.16. Happens exactly as described above. By: marvy (marvy) 2011-01-30 23:08:35.000-0600 This - https://reviewboard.asterisk.org/r/692/diff/ patch seems to be a possible fix. I will apply this tonight and test. By: marvy (marvy) 2011-02-01 18:18:53.000-0600 The patch seems to have worked for me. As a side note, the patch should be modified cosmetically slightly so that it doesn't log "Ignoring this retransmit" when in fact the retransmit hasn't been ignored after the patch has been applied. By: Matt Jordan (mjordan) 2014-03-05 07:34:30.805-0600 This was fixed in r267863 |