SCCP (skinny) phone behind NAT: RTP to wrong IP


I have a working configuration for SCCP on our LANS which doesn’t
route RTP correctly to a skinny phone behind NAT registering from
a remote public IP.


asterisk 1.4.35 servicing only skinny phones trunked to
asterisk 1.2.40 which services chan_phone FXS, zap FXO
and SIP phones; both instances of asterisk are behind NAT
and run on the same host (using different base directories)

working: cisco 7920 on wireless LAN behind NAT (

rtp problem: cisco 7920 on public access point behind NAT

symptom: asterisk is sending rtp to the NAT address of the
phone, e.g.

in skinny.conf, nat=yes is set for the context block of the

tcpdump of port 2000 reveals one packet after placing a call
from the phone that includes the NAT ip address of the phone
(c0a8 0003):

12:14:18.812960 IP (tos 0x0, ttl 50, id 16034, offset 0, flags [none], proto
TCP (6), length 72) > Flags [P.], cksum 0x461d
(correct), seq 148:180, ack 569, win 16384, length 32
0x0000: 4500 0048 3ea2 0000 3206 b62f 47d7 c1a1 E…H>¢…2.¶/G×Á¡
0x0010: d8fb b16a 0401 07d0 7c8a ecc6 710d 8d62 Øû±j…Ð|.ìÆq…b
0x0020: 5018 4000 461d 0000 1800 0000 0000 0000 P.@.F…
0x0030: 2200 0000 0000 0000 c0a8 0003 ba71 0000 "…À¨…ºq…
0x0040: 6d00 0000 0000 0000 m…

packet tracing RTP at the border router shows (on the LAN segment
of the asterisk host), e.g.

11:43:54.380567 IP (tos 0x0, ttl 64, id 737, offset 0, flags [DF], proto UDP
(17), length 200) > UDP, length 172

Shouldn’t ‘nat=yes’ in skinny.conf force asterisk to use the public IP
of the phone?

Help much appreciated!


Cisco phones don’t support NAT. In their intended environment, one would use VPN tunneling.

replies are appreciated!

  1. the 7920 phone firmware has no vpn capability which would be very nice indeed.

  2. what is the purpose of the ‘nat=’ statement in skinny.conf? most of the example phone configs include ‘nat=yes’ but
    without any qualification. i experimented with ‘nat=no’, ‘nat=1’, no nat= statement but there was no difference in
    the behavior. i started to inspect chan_skinny.c but a real understanding of the nat behavior will require a deeper
    understanding of asterisk and channel architecture than i now have.

  3. who all are currently contributing to maintenance of chan_skinny, especially the 1.4.x version? if this is fixed in
    later versions i will attempt to back port the changes (we need to run 1.4.x for handling skinny phones).

  4. if this could be fixed, the cheap 7920 could be used at public access points that don’t block the requisite ports and that
    preserve rtp source port mapping.

Cisco’s advice re VPN’s and CUCM is to terminate the VPN tunnel in the (Cisco) router.

I don’t know why there is a nat parameter. Maybe it was an oversight, cut and pasted from other channels. Maybe there are some Cisco phones that can do NAT.

If you want to trace the developer, you probably want the developer mailing list or developer IRC channel. They are unlikely to be reading here.

If I’m correct that there is no NAT support in any of the Cisco phone firmware, it cannot be “fixed” in Asterisk. You simply have to operate in a NAT free environment.

The Skinny NAT only seems to apply to the equivalent of the SDP layer and RTP layer.

Problem solved: built chan_sccp ver chan_sccp-b_20090602; on asterisk 1.4.35 / linux 2.4.27 / i386, cisco 7920 wifi
phone behind NAT at public access point now works with two-way audio.