Affects Version/s: 18.104.22.168
Security Level: None
Environment:SIP with a mis-behaving UA
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.