Summary:ASTERISK-11130: in a type-9 NAT environment, asterisk 1.4.15 and fail to playback/background/datetime/etc
Reporter:davidnicol (davidnicol)Labels:
Date Opened:2007-12-31 09:19:25.000-0600Date Closed:2011-06-07 14:02:46
Versions:Frequency of
Environment:Attachments:( 0) CONSOLE.txt
1: register eyebeam with 1.4 server
2: CLI> originate SIP/dave application Dial IAX2/guest@misery.digium.com/asterisk-dev

works, I get nice MOH

3: CLI> originate IAX2/guest@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.


KGSIVOIPP01*CLI> rtp debug
RTP Debugging Enabled
KGSIVOIPP01*CLI> originate IAX2/guest@misery.digium.com/asterisk-dev application DateTime
   -- Call accepted by (format gsm)
   -- Format for call is gsm
[Dec 31 09:19:34] WARNING[5288]: pbx.c:5163 ast_pbx_outgoing_app: IAX2/ already has a call record??
      > Channel IAX2/ was answered.
      > Launching DateTime() on IAX2/
   -- <IAX2/> Playing 'digits/day-1' (language 'en')
[Dec 31 09:19:38] WARNING[5298]: file.c:1162 waitstream_core: Unexpected control subclass '-1'
Comments:By: Joshua C. Colp (jcolp) 2007-12-31 09:28:51.000-0600

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.

By: davidnicol (davidnicol) 2007-12-31 10:15:40.000-0600

i have configured no telephony hardware at this point, strictly using VOIP.  What information do you require?

By: Joshua C. Colp (jcolp) 2007-12-31 10:17:58.000-0600

Complete console output with rtp debug, sip debug, debug to console in logger.conf, and core debug set to 9 using core set debug 9.

By: Joshua C. Colp (jcolp) 2008-01-07 11:08:40.000-0600

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.

By: Joshua C. Colp (jcolp) 2008-01-14 16:01:46.000-0600

Suspended as I strongly believe this was a Zaptel timing issue.