No subject

Siptapi then sends a REFER command which changes the SIP channel's method from INVITE to REFER. This seem to upset Asterisk's internal reference counting.
When an INVITE channel is destroyed at some point stop_media_flows is called within chan_sip.c. This then causes the references to the RTP engine to be decreased allowing it to be destroyed when the SIP channel is destroyed. For some reason stop_media_flows is not being called for the initial INVITE channel between Siptapi and Asterisk. I'm guessing it's something to do with the channel method changing from INVITE to REFER but can't be sure at this stage.
The end result is that when __sip_destroy runs it removes all references to the SIP channel but the RTP engine never gets destroyed and so leaves the ports open.

As a crude fix I've added another call to stop_media_flows in the __sip_destroy function which seems to solve the problem and in the limited testing I've done hasn't introduced any side effects. I'll be testing it more thoroughly next week and will report back.

I can't say it is a particularly good solution as it ignores the real issue of why the reference count of the RTP engine gets out of sync in the first place.

If anyone wants more information about what I've been trying and experimenting with in relation to this problem please let me know. I'll report back towards the end of next week with how the fix has behaved in the real world.
                
      was (Author: pbeaumonthatsoff):
    Hi Rusty.

Thanks for following up on this.

First of all the config changes didn't appear to make any difference to the problem. The ports were still being left open.

Secondly I've been doing my own investigation in to the code and think I've identified the problem and a very crude solution.