No subject

question that the SIP RFCs do not appear to handle. I've been using
the Asterisk 1.8.11.0 code to determine how Asterisk behaves, so
apologies if version 10 already answers this.

In a "normal" INVITE, we have a global timeout that is specified by
the Dial command's ring duration, such that it 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.
- As part of this, it Re-INVITEs the SIP A and SIP B audio back to Asterisk
- SIP A has a bug that means it responds "100 Trying" to the
Re-INVITE, but then nothing more.

I completely appreciate that this is not Asterisk's problem, BUT it
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.

My Thoughts:

If we know we are a Re-INVITE, set a new destroy timer on the pvt
after a 1xx or 18x response. I assume that we can identify a Re-INVITE
as an invite that it in progress on a channel that is in state
AST_STATE_UP ?

Regards,
Steve