[asterisk-bugs] [Asterisk 0011656]: in a type-9 NAT environment, asterisk 1.4.15 and 1.4.16.2 fail to playback/background/datetime/etc

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=11656 
====================================================================== 
Reported By:                davidnicol
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   11656
Category:                   Applications/app_playback
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.16.2 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 suspended
Fixed in Version:           
====================================================================== 
Date Submitted:             12-31-2007 09:19 CST
Last Modified:              01-14-2008 16:01 CST
====================================================================== 
Summary:                    in a type-9 NAT environment, asterisk 1.4.15 and
1.4.16.2 fail to playback/background/datetime/etc
Description: 

1: register eyebeam with 1.4 server
2: CLI> originate SIP/dave application Dial
IAX2/guest at misery.digium.com/asterisk-dev

works, I get nice MOH

3: CLI> originate IAX2/guest at misery.digium.com/asterisk-dev application
DateTime

on appearance of the second line, the MOH stops, but no DateTime, as the
playing back of the day-of-week has frozen.




it appears that the first RTP packet is being sent to an invalid port,
and is not followed by additional packets.




according to debug SIP, the client (eyeBeam, which looks like X-lite)
declares
a RTP port, which is the port which later on Asterisk attempts to send its
one
RTP packet to.  This is not the same port that the RTP stream from the
client
arrives on however.  When watching RTP debug output during a routed call
(rather than a playback) the packets are sent to the same port that they
arrive from,
as per correct type-9 NAT configuration.

1.2 works correctly in this regard, allowing simple tests such as
"originate SIP/me application DateTime" to function correctly; and RTP
debug
on the correctly working server indicates that the first and subsequent
RTP
packets all go to the correct port.

Theory:  the bit where Asterisk divines the RTP port from the SIP message
is broken, or at least is not getting revised with correct information
after RTP
packets from the client start arriving.

====================================================================== 

---------------------------------------------------------------------- 
 file - 01-14-08 16:01  
---------------------------------------------------------------------- 
Suspended as I strongly believe this was a Zaptel timing issue. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-14-08 16:01  file           Status                   feedback => resolved
01-14-08 16:01  file           Resolution               open => suspended   
01-14-08 16:01  file           Assigned To               => file            
01-14-08 16:01  file           Note Added: 0076933                          
======================================================================