| Summary: | ASTERISK-18996: Faulty SIP session timer handling | ||||
| Reporter: | Thomas Arimont (tomaso) | Labels: | |||
| Date Opened: | 2011-12-08 08:56:46.000-0600 | Date Closed: | 2012-01-16 14:13:01.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
| Versions: | 1.8.8.0 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) session_timer_fix.diff ( 1) session_timer.patch | |||
| Description: | In case of taking the role of the uas (incoming call, endpoint is re-inviting) the SIP session timer expires after half the time the sip endpoint indicates in session-expires header (proc_session_timer(), chan_sip.c implementation). In this case the timer should run again until the second expiry. Unfortunately the session timer is stopped totally (actually error handling for other cases) and the transmitted 200 o.k. response to the next received SIP Re-Invite from the sip endpoint device does not include the session-expires header anymore, which leads to a call release (from the part of the endpoint) using a SIP pedantic sip endpoint implementation (here Siemens OpenStage 60 V3): {noformat} session-timers=accept ;(or originate) session-expires=3600 session-minse=90 session-refresher=uas [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:22270 handle_request_invite: Incoming INVITE with 'timer' option supported and "Session-Expires" header. [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:25558 parse_session_expires: Session-Expires: 100 [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:25571 parse_session_expires: Refresher: UAC [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:25528 parse_minse: Received Min-SE: 90 [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:25426 start_session_timer: Session timer started: 27271 - dad30178c7404082 [Dec 8 14:28:45] DEBUG[3406]: chan_sip.c:22458 handle_request_invite: SIP/10-0000000e: New call is still down.... Trying... ... [Dec 8 14:29:35] DEBUG[3406]: chan_sip.c:25443 proc_session_timer: Session timer expired: 27271 - dad30178c7404082 [Dec 8 14:29:35] DEBUG[3406]: chan_sip.c:25499 proc_session_timer: Session timer stopped: 27271 - dad30178c7404082 [Dec 8 14:29:35] DEBUG[3406]: chan_sip.c:25397 stop_session_timer: Session timer stopped: -1 - dad30178c7404082 {noformat} | ||||
| Comments: | By: Thomas Arimont (tomaso) 2011-12-08 08:58:04.211-0600 For me the attached patch seems to fix this issue. By: Thomas Arimont (tomaso) 2011-12-08 09:56:09.876-0600 Didn't know how to edit a reference to another JIRA issue (ASTERISK-17942) ... By: Terry Wilson (twilson) 2012-01-10 09:48:27.738-0600 This patch looks correct. It should also be noted that according to the [SIP Session Timers RFC|http://www.ietf.org/rfc/rfc4028.txt], the endpoint is behaving incorrectly as well. From section 7.2: {noformat} If the 2xx response did not contain a Session-Expires header field, there is no session expiration. In this case, no refreshes need to be sent. A 2xx without a Session-Expires can come for both initial and subsequent session refresh requests. This means that the session timer can be 'turned-off' in mid dialog by receiving a response without a Session-Expires header field. {noformat} By: Thomas Arimont (tomaso) 2012-01-10 10:26:22.624-0600 Good to know that some implementors read the specs very well! ;-) Yes, it seems you're right, the endpoint is behaving incorrectly as well. I'll give both of you one point ... By: Terry Wilson (twilson) 2012-01-10 12:06:55.486-0600 Looking again, it looks like we would leak a reference in the case where st_timer >= 2 with the existing patch. I added a new patch that just moves the res = 1 into an else block. Thomas, could you verify that session_timer_fix.diff still fixes the issue for you? By: Thomas Arimont (tomaso) 2012-01-11 03:14:05.336-0600 Terry, yes, YOUR patch looks reasonable (avoiding a reference leak) and I have proved that it still fixes the problem. Thanks, good job! | ||||