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 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.
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.
                  
> RTP ports left open after using click to dial application
> ---------------------------------------------------------
>
>                 Key: ASTERISK-22417
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22417
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.4.0
>         Environment: Linux 3.2.0-40-virtual #64-Ubuntu SMP i686 i686 i386 GNU/Linux, Ubuntu 12.04
>            Reporter: Patrick Beaumont
>            Assignee: Patrick Beaumont
>
> Ports in use at the start
> {noformat}
> root at CN1:~# netstat -tunap
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
> tcp        0      0 0.0.0.0:5038            0.0.0.0:*               LISTEN      428/asterisk    
> tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      313/lighttpd    
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      129/sshd        
> tcp        0      0 10.0.3.101:22           10.0.3.1:60572          ESTABLISHED 339/sshd: steve [pr
> tcp6       0      0 :::22                   :::*                    LISTEN      129/sshd        
> udp        0      0 0.0.0.0:30000           0.0.0.0:*                           428/asterisk    
> udp        0      0 10.0.3.101:30001        0.0.0.0:*                           428/asterisk
> {noformat}
> First I initiate a call using dialer.exe through the application Siptapi.
> My desk phone rings.
> I pick it up.
> My mobile phone then rings (the destination I set in dialer.exe).
> I answer on my mobile phone.
> I place the call on hold using my desk phone.
> I initiate another call to my mobile using dialer.exe through the application Siptapi.
> My desk phone indicates I have a call waiting.
> I hang up the call I have on hold and my desk phone starts ringing.
> I pick up my desk phone and my mobile phone starts ringing.
> I answer the call on my mobile.
> I hang up the call on my mobile.
> I hang up my desk phone.
> Ports in use at the end:
> {noformat}
> root at CN1:~# netstat -tunap
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
> tcp        0      0 0.0.0.0:5038            0.0.0.0:*               LISTEN      428/asterisk    
> tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      313/lighttpd    
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      129/sshd        
> tcp        0      0 10.0.3.101:22           10.0.3.1:60572          ESTABLISHED 339/sshd: steve [pr
> tcp6       0      0 :::22                   :::*                    LISTEN      129/sshd        
> udp        0      0 0.0.0.0:30000           0.0.0.0:*                           428/asterisk    
> udp        0      0 10.0.3.101:30001        0.0.0.0:*                           428/asterisk    
> udp        0      0 10.0.3.101:30034        0.0.0.0:*                           428/asterisk    
> udp        0      0 10.0.3.101:30035        0.0.0.0:*                           428/asterisk  
> {noformat}
> This is very repeatable and if performed enough times Asterisk will complain about no longing being able to allocate RTP ports and will start rejecting calls.
> Performing a core restart appears to be the only way to release the ports.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira