[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:              01-07-2008 11:08 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-07-08 11:08  
---------------------------------------------------------------------- 
Are you using a hardware card with this that uses Zaptel? It looks as
though a card is present and not providing timing. This timing is used for
the playback of prompts, and if it does not provide timing the prompts
simply hang (exactly what is happening here). If you are you need to ensure
your card is properly configured and operational. You can also unload the
kernel modules in question and playback should return. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-07-08 11:08  file           Note Added: 0076413                          
01-07-08 11:08  file           Status                   new => feedback     
======================================================================