Why does Asterisk spawn a new UDP port?

Folks,

I have been struggling with getting Cisco 9640 phone to work behind NAT. Previously, I have posted my problem under a different subject but I think I am now more clear on the problem. I would appreciate it if someone can tell me what is going on.

The setup:

Asterisk server is in DMZ zone (IP: 192.168.15.7). Linux firewall. Ports 5060 and 10000-10200 are open.

Cisco phone is within NAT. Ports 5060 and 20011-20021 are being forwarded to the phone.

When Asterisk and the phone are within the same network, things work great.

When the phone is taken to a different network, behind the NAT, the phone registers fine with Asterisk. I can dial an extension and can hear the greeting recorded by the extension. Later, I am taken to the voicemail (as expected). At that point, I cannot record any message.

I think it is the same issue when the receiving extension picks up the phone. Although I can hear the other person, my voice does not go through.

I am running asterisk with -vvvvvvvvvvvgc

Here is the output from asterisk:

== Using SIP RTP CoS mark 5
– Called 101
– SIP/101-0871fe38 is ringing
– Nobody picked up in 20000 ms
– Executing [101@FromCiscoPhone:50006] Goto(“SIP/111-b7d01288”, “stdexten-NOANSWER,1”) in new stack
– Goto (FromCiscoPhone,stdexten-NOANSWER,1)
– Executing [stdexten-NOANSWER@FromCiscoPhone:1] VoiceMail(“SIP/111-b7d01288”, ““101"””,u") in new stack
– <SIP/111-b7d01288> Playing ‘/var/spool/asterisk/voicemail/default/101/greet.slin’ (language ‘en’)
– <SIP/111-b7d01288> Playing ‘vm-isunavail.ulaw’ (language ‘en’)
– <SIP/111-b7d01288> Playing ‘vm-intro.ulaw’ (language ‘en’)
– <SIP/111-b7d01288> Playing ‘beep.ulaw’ (language ‘en’)
– Recording the message
– x=0, open writing: /var/spool/asterisk/voicemail/default/101/tmp/sZpd0Z format: wav49, 0x871c240
– x=1, open writing: /var/spool/asterisk/voicemail/default/101/tmp/sZpd0Z format: gsm, 0x871c3b8
– x=2, open writing: /var/spool/asterisk/voicemail/default/101/tmp/sZpd0Z format: wav, 0x8723980
[Aug 14 02:06:12] WARNING[18523]: app.c:724 __ast_play_and_record: No audio available on SIP/111-b7d01288??
– User hung up
== Spawn extension (FromCiscoPhone, stdexten-NOANSWER, 1) exited non-zero on ‘SIP/111-b7d01288’

Here are the trace messages from tcpdump:

02:19:23.030023 IP 65.333.222.111.5060 > 192.168.15.7.5060: SIP, length: 962
02:19:23.030761 IP 192.168.15.7.5060 > 65.333.222.111.5060: SIP, length: 542
02:19:23.123376 IP 65.333.222.111.5060 > 192.168.15.7.5060: SIP, length: 364
02:19:23.200008 IP 65.333.222.111.5060 > 192.168.15.7.5060: SIP, length: 1125
02:19:23.200764 IP 192.168.15.7.5060 > 65.333.222.111.5060: SIP, length: 478
02:19:23.449542 IP 192.168.15.7.5060 > 65.333.222.111.5060: SIP, length: 494
02:19:43.223914 IP 192.168.15.7.5060 > 65.333.222.111.5060: SIP, length: 809
02:19:43.387153 IP 65.333.222.111.5060 > 192.168.15.7.5060: SIP, length: 570
02:19:43.726103 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.746729 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.766615 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.786610 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.806687 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.826613 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.846630 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.866612 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.886609 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.906687 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.926621 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.946609 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.966629 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:43.986616 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:44.006609 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:48.716665 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:48.725994 IP 192.168.15.7.10093 > 65.333.222.111.20013: UDP, length 64
02:19:48.733413 IP 65.333.222.111 > 192.168.15.7: ICMP 65.333.222.111 udp port 20013 unreachable, length 36
02:19:48.736642 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172
02:19:48.756608 IP 192.168.15.7.10092 > 65.333.222.111.20012: UDP, length 172

Notice that, at some point when Asterisk is ready to record the message, it suddenly spawns communication on a new port number (20013). Cisco phone is not ready for it and thus the packet becomes unreachable.

I think the problem is right here. When the phone is within the Intranet, I do not see a new port getting used. Only two ports are used: 5060 and just one media port within 20011 to 20020.

I think something in my configuration is causing this.


Here is my SIP.cnf:

image_version: "P0S3-8-12-00"
line1_name: “111” ;
line1_authname: “111” ;
line1_shortname: “Peter-111” ;
line1_displayname: “” ;
line1_password: “mypass”

proxy1_address: "sip.mycompany.com"
proxy1_port: 5060

outbound_proxy: "sip.mycompany.com"
outbound_proxy_port: “5060”

nat_enable: "1"
nat_received_processing: "1"
nat_address: "65.333.222.111"
start_media_port: "20011"
end_media_port: “20020”


Finally, here is my sip.conf:

[111]
context = FromCiscoPhone
dtmfmode=rfc2833
host=dynamic
type=friend
username=111
secret=mypass
callerid="Peter"
mailbox=111
nat=true

Based on another post, I tried changing nat_received_processing to 0 but that doesn’t make any difference.

I would appreciate it if someone can tell me why Asterisk is suddenly using a new port number in case of extranet communication.

Regards,
Peter

As I said on the other thread:

  1. ports are chosen by the receiver of the RTP traffic;

  2. one needs to see the complete SIP packets to explain what is happening here.

try adding

reinvite=no
canreinvite=no

to your sip.conf for this peer.

I know only one of those is valid… i can just never remember which one, so I put them both :smile:

This is probably incorrect on some level, but in my experience, each call in Asterisk can use up to 4 UDP ports. If you’re expecting the call to function on only one, that’s asking for a problem.

David,

Can you please tell me how I can generate complete SIP packets? Is there a flag in Asterisk to do so? The man pages on tcpdump has an option -x to print the data for each packet. Is this what you are referring to?

Appreciate your help.

Peter

[quote=“david55”]As I said on the other thread:

  1. ports are chosen by the receiver of the RTP traffic;

  2. one needs to see the complete SIP packets to explain what is happening here.[/quote]

I’d normally use “sip set debug” in Asterisk, but tcpdump -X (capital X) should give the information, if -s is large enough. A sufficient number of -v’s will give you at least some of the message in prettier format, although you will need to make sure you get the SDP payload, not just the SIP headers. You will also need a large enough -s.