Cisco SIP phone - are there any timeout parameters?

Folks,

In my setup, Cisco phone as a SIP client is behind the NAT.

AsteriskServer <–INTERNET—>Linksys router<–>Cisco phone

I have configured Cisco phone to have media_start at 20010 and media_end at 20020.

Linksys router is configured to forward port range 20010-20021 to Cisco phone’s IP address.

The SIP user has “nat=true” in sip.conf. The Cisco phone has nat_enable=1.

This configuration works (almost). When the Cisco phone boots up, it discovers TFTP server, initializes configuration, and registers the phone with Asterisk. So far so good.

Now, when I dial an extension, I am taken to the extension’s voicemail. This is expected as there was no one to pick the phone at that extension. However, when I try to record a message, Asterisk simply assumes that the caller has hung up.

WARNING[8882]: app.c:724 __ast_play_and_record: No audio available on SIP/111-b7c06c28??

I used tcpdump to trace what is going on.

For the initial communication, Asterisk picks a port, say 20018, to talk to Cisco phone. This UDP connection goes through.

During the voicemail, to record the audio, Asterisk now uses the next port number (20019 in our case). When it tries to open a UDP connection to 20019, it is not able to reach the phone. Not able to hear anything back from the caller’s SIP extension, Asterisk just hangs up.

00:38:59.730210 IP 192.168.15.7.10048 > myexternalip.net.20018: UDP, length 172
00:38:59.750145 IP 192.168.15.7.10048 > myexternalip.net.20018: UDP, length 172
00:38:59.770246 IP 192.168.15.7.10048 > myexternalip.net.20018: UDP, length 172
00:38:59.778664 IP 192.168.15.7.10049 > myexternalip.net.20019: UDP, length 64
00:38:59.783031 IP myexternalip.net > 192.168.15.7: ICMP myexternalip.net udp port 20019 unreachable, length 36

It is always the same problem with any pair of ports. For example, 20016 goes through but 20017 does not.

I am wondering if this is just a timeout related issue and can be fixed with some parameters. Any other thought would also be appreciated.

I am also not sure why I see “ICMP” in the trace. Wonder if I need to configure something else as well on the router.

A little bit more info. Asterisk box itself is behind NAT. However, it is configured to be in the DMZ zone. I don’t believe this info is relevant to the problem at hand but just wanted to pass this along.

Thank you in advance for your help.

Regards,
Peter

Anyone?

Please share any idea that you may have. I am completely stuck and am desperate to try out anything.

Regards,
Peter

Asterisk doesn’t choose the port to talk to the Cisco; the Cisco, or the NAT logic in the router, chooses that, and tells Asterisk. Asterisk only choses the port that the Cisco uses to talk to Asterisk.

The port unreachable indicates the myexternalip router doesn’t know what to do with that port number. I’m not clear where you are actually monitoring this.

Finally, note that UDP doesn’t have connections.

Hi David,

Thank you for your help.

If I understand you right, the port range value (media_start and media_end) never goes to Asterisk from Cisco. As part of the initial communication over port 5060, it is the phone that picks up a random port within the range and informs Asterisk to use this specific port. Is this right?

In my case, for example, although the defined range was 20010 to 20020, the phone told Asterisk to use port 20017.

During voicemail recording, it appears a new audio port is needed. Once again, the phone tells Asterisk to use port 20018. It is not Asterisk that is automatically trying to use the next port number. Is this right? I suspect this is not the case. Explanation follows at the end of this message.

I think I will switch my router and test my scenario.

About UDP and connections, UDP also has connections. Without connection, there is no communication. The major difference between TCP and UDP is that there is no “guaranteed” delivery. Flow control, error correction, etc. are missing under UDP. But I guess that is what you meant.

On a side note, there is definitely a bug, either in latest Cisco phone firmware or in Asterisk. My port range within the phone is defined as 20010 to 20020. During initial communication, port 20020 is used to send Welcome message, etc. However, during voicemail recording, Asterisk tries to open port 20021. Either the phone is sending incorrect 20021 port number to Asterisk or Asterisk just uses the next port for audio. I suspect it is the second case.

Regards,
Peter

[quote=“david55”]Asterisk doesn’t choose the port to talk to the Cisco; the Cisco, or the NAT logic in the router, chooses that, and tells Asterisk. Asterisk only choses the port that the Cisco uses to talk to Asterisk.

The port unreachable indicates the myexternalip router doesn’t know what to do with that port number. I’m not clear where you are actually monitoring this.

Finally, note that UDP doesn’t have connections.[/quote]

UDP is formally a “connectionless protocol”. Nothing in UDP requires anything to remember anything from one packet to the next, although modern firewalling may need to infer higher level connections in order to selectively pass related UDP packets.

You are going to have to provide sip set debug traces and sip show channel output to convince me that Asterisk is doing anything but exactly what the incoming SDP tells it to do.

I think it more likely that the Asterisk side NAT router is getting confused.

David,

Asterisk server is in the DMZ zone. I would imagine it won’t have any problem with NAT.

I have spent a number of hours trying to debug the problem but no luck so far.

When the phone is inside the network, it works great.

When I take the phone outside the network, it stops working.

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, Asterisk suddenly spawns communication on a new port number (20013). Cisco phone is not ready for it and thus the packet becomes unreachable.

This new port is NOT spawned when the phone is within the Intranet. 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 any help that you can provide.

Regards,
Peter

If you are doing tcpdump, you need to set the verbosity so that you can see the complete SIP packets.

The fact that it works inside but not outside, re-inforces the position that you have a NAT, or other router related, problem.