[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 requires your FEEDBACK. 
====================================================================== 
http://bugs.digium.com/view.php?id=11656 
====================================================================== 
Reported By:                davidnicol
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11656
Category:                   Applications/app_playback
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
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:              
====================================================================== 
Date Submitted:             12-31-2007 09:19 CST
Last Modified:              12-31-2007 09:28 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 - 12-31-07 09:28  
---------------------------------------------------------------------- 
Please provide complete information, as well as if you are using Zaptel or
not. If the actual playback of the file is not continuing then it is a
timing issue. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
12-31-07 09:28  file           Note Added: 0076168                          
12-31-07 09:28  file           Status                   new => feedback     
======================================================================