Summary:ASTERISK-09492: SIP-phone -> SIP-PSTN-gateway gives silence with canreinvite=no
Reporter:Carl-Mikael Ahlgren (carlis)Labels:
Date Opened:2007-05-22 18:18:41Date Closed:2011-06-07 14:07:53
Versions:Frequency of
Environment:Attachments:( 0) debug.zip
Description:I use Asterisk SVN-trunk-r65298M and get this very strange error. I discovered it in 1.4.4 but have used the svn version to make all the tests presented here.

The problem is reprodusable every time. By adding a playback() in the dialplan I can work around it. I have logs and tcpdumps from a working case, and a non-working one.

I have a PSTN<->SIP subscription IP at rixtelecom [rix] and a SIP-telephone Siemens C450 IP [liljev]. I try to call talking clock (or any other person at PSTN) from the SIP-telephone.

The Asterisk server is behind NAT running on Debian (own compiled kernel) Linux fiskbil #3 PREEMPT Thu Apr 5 19:38:14 CEST 2007 i686 GNU/Linux. The Asterisk server IP is The "router" is a linux/debian with manually setup iptables and udp port 5060, 19000-20000 forwarded from external IP ( to internal I have limited rtp-ports to 19000-20000 in rtp.conf. The forwarding is like this:
iptables -t nat -A PREROUTING -i eth1 -p udp --dport 5060 -j DNAT --to-destination
iptables -t nat -A PREROUTING -i eth1 -p udp --dport 19000:20000 -j DNAT --to-destination

The SIP-telephone is not in the same LAN as the Asterisk server. It's behind another NAT-device (watchguard firebox) with external IP and using STUN. That part seems to work correctly. Even canreinvite=yes works with my SIP<->PSTN provider. The problem starts if I try to use canreinvite=no.

Calling "in" to asterisk (voice menus, dtmf, etc) works fine both from the SIP-telephone and from PSTN<->SIP.

The address tele.neltus.org is a valid DNS address and resolvs correctly to my external IP .

To produce the error:
Dial 890510 from the SIP-telephone. (90510 is the official swedish number to talking clock).

If I use this dialplan entries it works fine: (yes I know answer() should probably not be there)
It seems like the playback() is opening the channel in some way and that makes it work.
exten => _8.,1,answer()
exten => _8.,n,playback(hello-world)
exten => _8.,n,Dial(sip/${EXTEN:1}@rix)

If I change it to this, it dials correctly but after that silence in both directions. The call is "alive" and I can hangup normally.
exten => _8.,1,answer()
exten => _8.,n,Dial(sip/${EXTEN:1}@rix)

tcpdump is run on my linux router on the LAN-side-interface:

Analyzing the network traffic with tcpdump, working case, (tcpdump_01.txt):
We see here the RTP-traffic flows nice both directions through the asterisk server. = sip/pstn [rix], = sip-telephone [liljev]

23:40:16.245841 IP > UDP, length 172
23:40:16.246416 IP > UDP, length 172
23:40:16.263804 IP > UDP, length 172
23:40:16.263953 IP > UDP, length 172

In the nonworking case (tcpdump_02.txt):
We see that the traffic reaches the asterisk server from both SIP-subscription and SIP-telephone but no traffic back from asterisk.
23:41:55.224247 IP > UDP, length 172
23:41:55.235511 IP > UDP, length 172

If I use canreinvite=yes on both, the call works fine (no rtp-traffic to asterisk) but with canreinvite=no it goes like this.
It doesn't seems to make any difference with nat=no or yes. I have entered my external IP in sip.conf (externip =

In some rare cases a single call can actually work even without playback() in the dialplan. But I have seen it only once and I have done a lot of testing.

I attach two debuglogs from asterisk, sip.conf and two tcpdump-logs. All IP-addresses and names, etc, are unchanged (except for blanked passwords in sip.conf)

I have spent a lot of time searching on the net and trying to track this down. Found no real solution. It really seems to me like a bug. If not, why can I get it working by only changing the dialplan? Am I missing some basic setting?

Regards // Carlis in Sweden
Comments:By: Carl-Mikael Ahlgren (carlis) 2007-05-23 16:18:45

Hi! I am sorry. This is not a bug. It was a simple firewall problem where I least expected it. Please erase this bug. It never existed. It even works fine with 1.4.4.

By: Terry Wilson (twilson) 2007-05-24 10:00:03

Closing issue, thanks.