| Summary: | ASTERISK-25154: [patch]fromtag may need to be updated after successful call dialog match | ||
| Reporter: | Damian Ivereigh (damianivereigh) | Labels: | |
| Date Opened: | 2015-06-10 00:29:58 | Date Closed: | 2015-06-12 16:25:08 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | 11.6.0 13.3.2 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Centos-7 | Attachments: | ( 0) 020788CFDE8140000000004E@10.1.252.234.pcap |
| Description: | When using an NEC-i SV8100-GE (NEC SIP Card) as a authenticating user, after the initial INVITE which is 401 unauthorised rejected, the next INVITE with authentication is sent with the same call-id but a different fromtag. I am unclear whether this is OK (per the RFCs), however asterisk specifically allows this to happen by matching it against the previous INVITE's dialog (it ignores the from tag).
Asterisk then continues to use the new fromtag in any responses, however it does not update the fromtag in the dialog. Then when it again has to match any responses within that dialog (e.g. the ACK to the OK or the OK to the BYE) it cannot match it. The end result is that the call is dropped after about 10 secs. I will upload a pcap file to show what happens. I am uploading a patch to gerrit to fix this. | ||
| Comments: | By: Damian Ivereigh (damianivereigh) 2015-06-10 00:34:06.414-0500 PCap file demonstrating what happens when asterisk loses track of the fromtag. Note the change in the fromtag between the first INVITE and the second. | ||