Details
-
Type:
Bug
-
Status: Closed
-
Severity:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.11.1
-
Target Release Version/s: 1.8.13.1, 10.5.2, 10.5.2-digiumphones
-
Component/s: Channels/chan_sip/General
-
Security Level: None
-
Labels:None
-
Environment:SIP with a mis-behaving UA
-
Frequency of Occurrence:Occasional
-
Reference Notes:
-
Regression:No
-
Review Link:
Description
I believe that this issue exists through all Asterisk versions as it appears to be an omission in the SIP RFCs (I am happy to be corrected if that is not true).
In a "normal" INVITE, we have a global timeout that is specified by the Dial command's ring duration, such that if all else fails, app_dial or equivalent will stop the channel from existing beyond its natural lifespan. With a Re-INVITE, this is not the case, and I have a scenario where Asterisk leaks RTP ports:
- Inbound call (any channel tech) to SIP endpoint A.
- Original call on-hold by SIP A
- SIP A calls SIP B, and direct-media call is set up.
- SIP A 'REFER's the call to bridge the inbound call to SIP B.
- In response to the REFER, Asterisk Re-INVITEs the SIP A and SIP B RTP audio back to Asterisk
- SIP A has a bug that means it responds "100 Trying" to the Re-INVITE, but then nothing more.
The 100 Trying clears SIP Timer B, and no other SIP events will occur to progress the Re-INVITE. At this point, Asterisk has a channel that will never timeout, and SIP A considers the channel finished with. This results in us leaking any RTP ports opened for that channel as they are never cleaned up.
This leaves a potential DoS where the original SIP A RTP ports are leaked, and over a period of time can prevent Asterisk and/or the host from working.
Issue Links
- must be completed before resolving
-
ASTERISK-20018
Asterisk 1.8.14.0 Blockers
-
- Closed
-
-
ASTERISK-20019
Asterisk 10.6.0 Blockers
-
- Closed
-
Thoughts:
If the SIP A channel sends a 1xx or 18x response to a Re-INVITE packet (A media update, COLP update INVITE, or any other non-initial INVITE), then perhaps we should reset the PVT destroy timer rather than clearing it in handle_response_invite() ? A non-initial INVITE ought to be completed in sub-1 second, so I think allowing the default Timer-B 32 seconds would be plenty?
Could this change be applied to any SIP channel that is in AST_STATE_UP ? Or is that not a safe way to identify a Re-INVITE rather than an initial INVITE?