[asterisk-users] No reply to our critical packet
Hi list! Today I tried to change the NAT-configuration on my Firewall to use another port for SIP. I configured it so: /sbin/iptables -t nat -A PREROUTING -p udp -m udp --dport 1:10100 -j DNAT --to-destination 192.168.20.120 /sbin/iptables -t nat -A PREROUTING -p udp -m udp --dport my new port -j DNAT --to-destination 192.168.20.120:5060 then, I tried to log on my Asterisk with my mobile phone. It works. Great! Then I tried to call an extension I created for the tests. This extension just play a beep, record a message and play it back. I hear the beep and I can speak my test message, then I can just hear a couple of seconds of my message and I get this error: [Jun 9 07:41:56] WARNING[19374] chan_sip.c: Retransmission timeout reached on transmission 1ec8759e5160b42b92000629ec5e4771@10.102.46.147 for seqno 993 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 13569ms with no response [Jun 9 07:41:56] WARNING[19374] chan_sip.c: Hanging up call 1ec8759e5160b42b92000629ec5e4771@10.102.46.147 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions). I'm really not sure, what can be the problem, now... I read the wiki page, but I can understand what is wrong now in a configuration that works for days... Have I to say Asterisk, that the NAT receive data from another port? This is the only change in my configuration since yesterday, as all worked... Thanks Luca Bertoncello (lucab...@lucabert.de) -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] No reply to our critical packet
Hi, I’ve installed Asterisk for use as a SIP server. I can call people, but one strange thing happens: if I call someone with a SIP account outside my server (for example, sip:enum-echo-t...@sip.nemox.net) everything is fine, if I call any Asterisk extension it also works, but the call gets disconnected in about 20 seconds. To be exact, audio is turned off but the SIP client still thinks it’s connected. Logs say “no reply to our critical packet”. tcpdump shows that the packet does arrive at the destination. sip set debug shows this is what the packet contains: Retransmitting #6 (NAT) to 77.239.189.223:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 77.239.189.223;branch=z9hG4bK-d8754z-db899ced94cc7fd3-1---d8754z-;received=77.239.189.223 From: Romasip:r...@qwertty.com;transport=UDP;tag=01785d5e To: sip:e...@qwertty.com;transport=UDP;tag=as068592d2 Call-ID: ZTkzNjYxNzZmOWMzY2ZhOTdjMWIwYTEwZTYxZmUyZTY. CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:e...@78.46.49.80 Content-Type: application/sdp Content-Length: 285 v=0 o=root 25952 25952 IN IP4 78.46.49.80 s=session c=IN IP4 78.46.49.80 t=0 0 m=audio 30606 RTP/AVP 3 0 8 101 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv There’s NAT: computer (192.168.1.2) behind a router (77.239.189.223), the server (78.46.49.80) doesn’t have any NAT. I have even set DMZ host to 192.168.1.2, so I’m sure all packets reach it. As far as I understand, Asterisk expects the SIP client to reply to that packet with an ACK, the client receives the packet but does not reply. What have I configured incorrectly? In sip.conf I have nat=yes (otherwise I don’t hear anything), whatever I do with NAT settings of SIP clients does not help. Maybe there’s something wrong with the headers of the packet that makes the client think the packet is misaddressed? Twinkle says, “you have the following registrations sip:r...@192.168.1.2” while I’d expect sip:r...@qwertty.com. So how do I make sure the client sends its ACK? -- TIA Roman. smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
-Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 9:57 AM To: asterisk-users@lists.digium.com Subject: [asterisk-users] No reply to our critical packet Hi, I've installed Asterisk for use as a SIP server. I can call people, but one strange thing happens: if I call someone with a SIP account outside my server (for example, sip:enum-echo-t...@sip.nemox.net) everything is fine, if I call any Asterisk extension it also works, but the call gets disconnected in about 20 seconds. To be exact, audio is turned off but the SIP client still thinks it's connected. Logs say no reply to our critical packet. tcpdump shows that the packet does arrive at the destination. sip set debug shows this is what the packet contains: Retransmitting #6 (NAT) to 77.239.189.223:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 77.239.189.223;branch=z9hG4bK-d8754z-db899ced94cc7fd3-1---d8754z-;received=7 7.239.189.223 From: Romasip:r...@qwertty.com;transport=UDP;tag=01785d5e To: sip:e...@qwertty.com;transport=UDP;tag=as068592d2 Call-ID: ZTkzNjYxNzZmOWMzY2ZhOTdjMWIwYTEwZTYxZmUyZTY. CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:e...@78.46.49.80 Content-Type: application/sdp Content-Length: 285 v=0 o=root 25952 25952 IN IP4 78.46.49.80 s=session c=IN IP4 78.46.49.80 t=0 0 m=audio 30606 RTP/AVP 3 0 8 101 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv There's NAT: computer (192.168.1.2) behind a router (77.239.189.223), the server (78.46.49.80) doesn't have any NAT. I have even set DMZ host to 192.168.1.2, so I'm sure all packets reach it. As far as I understand, Asterisk expects the SIP client to reply to that packet with an ACK, the client receives the packet but does not reply. What have I configured incorrectly? In sip.conf I have nat=yes (otherwise I don't hear anything), whatever I do with NAT settings of SIP clients does not help. Maybe there's something wrong with the headers of the packet that makes the client think the packet is misaddressed? Twinkle says, you have the following registrations sip:r...@192.168.1.2 while I'd expect sip:r...@qwertty.com. So how do I make sure the client sends its ACK? -- TIA Roman. -- Two thoughts (both could be wrong) 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Danny Nicholas ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn’t help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
-Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 10:38 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No reply to our critical packet Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn't help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. Next Step would be to check/update the firmware on your phones or router. Regards, Danny Nicholas ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
On Friday, 13.03.2009 17:50:57 Danny Nicholas wrote: Next Step would be to check/update the firmware on your phones or router. I don’t think the router is to blame, it does deliver all the packets. And there are no hardware phones, only numerous software SIP clients. Which (GNU/Linux) software clients are known to have maximum compatibility with Asterisk? -- TIA Roman. smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
I have the same situation. My scenario is weird: I have a DID with IPkall that points to my asterisk server, and I have it play a message with Playback() after about 20 seconds call drops and give me the same message you get: no reply to our critical packet BUT I have a DID from Vitelity, and that one works fine no drops. I have no idea why. On Fri, Mar 13, 2009 at 12:37 PM, Roman Odaisky r...@qwertty.com wrote: On Friday, 13.03.2009 17:50:57 Danny Nicholas wrote: Next Step would be to check/update the firmware on your phones or router. I don’t think the router is to blame, it does deliver all the packets. And there are no hardware phones, only numerous software SIP clients. Which (GNU/Linux) software clients are known to have maximum compatibility with Asterisk? -- TIA Roman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
--- On Fri, 3/13/09, Pascal Bruno tipas...@gmail.com wrote: I have the same situation. My scenario is weird: Well, I've experienced the same symptoms but in a whole different context. It's happening in my LAN (no firewalls, no NAT) and only with specific IP phones + early dial + pedantic=yes. http://bugs.digium.com/view.php?id=14652 I guess it's the client's fault in this case. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
I had this issue with SIP Phones (Cisco 7961) to local voicemail; the issue was resolved by adding a Ringing() followed by Wait(1) before the VoicemailMain() in the dial plan... it seems like there should be a better way, and I feel it's rather crude to force the user to listen to a second of ringback before launching into voicemail, but it solved the problem for me (and yes, I did try just Ringing() with no wait with no such luck) -- maybe it would work in your case with a SIP call as well? HTH, Lincoln -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 11:38 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No reply to our critical packet Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn't help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
Not a better hack but perhaps more palatable to the listener Playback(please-wait) Wait(1) -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Lincoln King-Cliby Sent: Friday, March 13, 2009 1:16 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet I had this issue with SIP Phones (Cisco 7961) to local voicemail; the issue was resolved by adding a Ringing() followed by Wait(1) before the VoicemailMain() in the dial plan... it seems like there should be a better way, and I feel it's rather crude to force the user to listen to a second of ringback before launching into voicemail, but it solved the problem for me (and yes, I did try just Ringing() with no wait with no such luck) -- maybe it would work in your case with a SIP call as well? HTH, Lincoln -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 11:38 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No reply to our critical packet Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn't help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
My best guess at the root cause of the problem after looking at the packet capture was that the phone was not happy seeing the call connected before any of the intermediate states (trying, ringing, etc.) and Ringing() generated the session progress (e.g. in addition to the in-band ringback it also generates the SIP message to tell the phone that the phone is ringing... or maybe it just generates the SIP message and the phone generates the ringback) necessary to make the phone happy; I don't think Playback() does the same thing. -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Danny Nicholas Sent: Friday, March 13, 2009 2:22 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet Not a better hack but perhaps more palatable to the listener Playback(please-wait) Wait(1) -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Lincoln King-Cliby Sent: Friday, March 13, 2009 1:16 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet I had this issue with SIP Phones (Cisco 7961) to local voicemail; the issue was resolved by adding a Ringing() followed by Wait(1) before the VoicemailMain() in the dial plan... it seems like there should be a better way, and I feel it's rather crude to force the user to listen to a second of ringback before launching into voicemail, but it solved the problem for me (and yes, I did try just Ringing() with no wait with no such luck) -- maybe it would work in your case with a SIP call as well? HTH, Lincoln -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 11:38 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No reply to our critical packet Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn't help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
Correct you are. Playback just plays a file back to the caller, Ringing sends a ringing to over the channel (to the user). -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Lincoln King-Cliby Sent: Friday, March 13, 2009 1:42 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet My best guess at the root cause of the problem after looking at the packet capture was that the phone was not happy seeing the call connected before any of the intermediate states (trying, ringing, etc.) and Ringing() generated the session progress (e.g. in addition to the in-band ringback it also generates the SIP message to tell the phone that the phone is ringing... or maybe it just generates the SIP message and the phone generates the ringback) necessary to make the phone happy; I don't think Playback() does the same thing. -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Danny Nicholas Sent: Friday, March 13, 2009 2:22 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet Not a better hack but perhaps more palatable to the listener Playback(please-wait) Wait(1) -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Lincoln King-Cliby Sent: Friday, March 13, 2009 1:16 PM To: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No reply to our critical packet I had this issue with SIP Phones (Cisco 7961) to local voicemail; the issue was resolved by adding a Ringing() followed by Wait(1) before the VoicemailMain() in the dial plan... it seems like there should be a better way, and I feel it's rather crude to force the user to listen to a second of ringback before launching into voicemail, but it solved the problem for me (and yes, I did try just Ringing() with no wait with no such luck) -- maybe it would work in your case with a SIP call as well? HTH, Lincoln -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 | F: 440.729.0884 | I:http://www.thecontrolworks.com/ Crestron Authorized Independent Progammers -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Roman Odaisky Sent: Friday, March 13, 2009 11:38 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No reply to our critical packet Hi, thanks for the quick reply. 1. Do you have the incoming 1-2 holes in your firewall so the remote server can get it's reply back to *? This was what I checked first. Both firewalls let everything through. 2. If #1 is ok, try putting an Answer command in front of your Dial Command. Doesn't help, alas. Also, it works the same (disconnect after 20 seconds) both for Dial and Echo, regardless of presence of Answer. -- TIA Roman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
Ringing() followed by Wait(1) I made it exten = echo,1,Ringing() exten = echo,2,Wait(1) exten = echo,3,Playback(abandon-all-hope) exten = echo,4,Echo() to no avail. This looks like a client issue, though all of my clients fail. Which clients are the most standards conforming? Also, maybe Asterisk isn’t what I need? I need a server with which several people would register accounts, they’ll be able to place calls among themselves and also call other SIP accounts, as well as calling PSTN numbers using predefined accounts (so that it would be possible to share one paid account between several users). So a SIP server + possibility for dialplans through 3rd party SIP servers. Maybe something like SER would suffice? Or SER as a proxy in front of Asterisk is the way to go? -- TIA Roman. smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Hi Steve, Thanks again for the response-- the answer you gave was more or less the answer that I was expecting. I was logging all packets to and from the phone, and I never saw an ACK from the phone for the OK to Asterisk on the VM calls -- not an ACK directed to a different location, just no ACK period. I noted in my other reply that as a test I had added a call to Ringing() followed by Wait(1) before dropping into Voicemail for the voicemail extension in the dialplan, since I noticed that the only difference that appeared to exist between a SIP-POTS or SIP-SIP call and a SIP-Voicemail call, aside from the missing ACK from the phone is that Asterisk reported session progress of 100 Trying and 180 Ringing to the phone, where it didn't report either of these when calling Voicemail, instead jumping straight to 200 OK with session description. In the 24 hours since I did that we haven't been able to get any of dozens of calls to Voicemail to fail, when normally it would borderline on greater than one in every two call. I'm still not convinced it's fixed, but I'm feeling fairly good about the solution, so it seems to my untrained eye like there may be an issue in the Cisco 79x1 firmware if the PBX accepts a call without providing any intermediate status? That seems like it would manifest itself in other places, and I'm kind of grasping at straws but... Thanks again to everyone who took the time to read and or respond to this issue -- I'll post again if it turns out that that wasn't actually the fix, but for now management is happy that they can actually listen to their entire voicemail messages. Lincoln -- Lincoln King-Cliby, CTS Applications Engineer ControlWorks Consulting, LLC V: 440.729.4640 x1107 F: 440.729.0884 I:http://www.controlworks.com Crestron Authorized Independent Programmer -Original Message- From: Steven J. Douglas [mailto:stev...@moij.biz] Sent: Wednesday, February 04, 2009 12:43 AM To: Lincoln King-Cliby Cc: 'Asterisk Users Mailing List - Non-Commercial Discussion' Subject: Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail Hi Lincoln, The fact that you can hear and respond to the voice mail (even if its for the first 20 seconds), means that your phone has received the OK message properly. The problem is the missing ACK after receiving OK. When asterisk did not receive the ACK after a few retries of the OK, it terminated the call. This resulted in your RTP streams getting the icmp error messages. Assuming that you are capturing every packet that goes on between Asterisk and the phone, there are two possibilities. 1. The phone has a bug. 2. The ACK was sent somewhere else. Normally the ACK message destination is constructed from the response to the INVITE. In this case, it will be the OK message. If you suspect its the second case, you can capture the traffic for both a good voicemail call and a failed voicemail call. Then by comparing the messages, you might get a hint. If you need help, you can send the packet capture to me privately (not through the list as it might be a large file) and I can help vet it for you. Unfortunately there is no flag that you can set to confirm a session based on OK being transmitted and not wait for ACK. Regards, Steve snipped my original reply ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Hi Lincoln, Asterisk was expecting ACK after sending the 200 OK message. After repeated attempts at sending the 200 OK message and not receiving ACK, it terminated the call. Are you able to do a packet capture on the phone end? Mostly likely the phone is sending the ACK, but its either sent to somewhere else or your firewall is blocking it (not likely since you are able to receive the call in the first place). The packet capture on the phone end will probably show you the smoking gun. Regards, Steve Lincoln King-Cliby wrote: Hi All, I posted this a couple weeks ago with no response, I'm hoping that someone will see it this time around and be so kind as to offer advice for resolving this issue (or point me in the direction of a better place to ask) Some (but not all) calls on one of our Asterisk boxes are being dropped in Voicemail -- only in voicemail -- after about 20 seconds with the error logged [Jan 19 14:33:26] WARNING[27458]: chan_sip.c:1980 retrans_pkt: Hanging up call 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 - no reply to our critical packet (see doc/sip-retransmit.txt).. We're running Asterisk 1.4.22 built from source and Cisco 7961G phones with the SIP firmware image. I've tried most of the recent firmware versions for the phones with no real impact on the issue. Strange thing is that while all of the phones use a variation on the same config file (with the only changes being the SIP account details and speed dial keys) but one user in particular seems to suffer the issue far more frequently. I would appreciate any assistance since I'm stumped. The output of SIP DEBUG for the extension most frequently affected by the issue is below; starting with one call to voicemail that was successfully completed, followed by a 2nd call that was dropped after approximately 18 seconds. The issue is consistently inconsistent - it doesn't happen on every call to Voicemail, but those that it does happen on it's always within the first approximately 20 seconds of the call; once you pass the 25 second mark you're free and clear for that call-it will not be dropped. It also seems like it's possible to reproduce the issue by making several calls to Voicemail in short order, but this isn't the only trigger as sometimes the first call to voicemail in 12+ hours will also trigger it. I'm also baffled by the fact that this ONLY crops up on calls to Voicemail on the local box; SIP to SIP calls on the same Asterisk box, SIP to SIP calls from this Asterisk box to an Asterisk Appliance at a remote site, SIP to POTS, and POTS to SIP calls are completely unaffected. Again, any advice/suggestions/things to look at/etc are greatly appreciated! Thanks in advance, Lincoln Scheduling destruction of SIP dialog '001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203' in 32000 ms (Method: INVITE) Sending to 10.2.0.203 : 5060 (no NAT) Using INVITE request as basis request - 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 18 Found RTP audio format 101 Peer audio RTP is at port 10.2.0.203:24394 Found audio description format PCMU for ID 0 Found audio description format PCMA for ID 8 Found audio description format G729 for ID 18 Found audio description format telephone-event for ID 101 Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 10.2.0.203:24394 Looking for Voicemail in internal (domain 10.2.0.2) list_route: hop: sip:1...@10.2.0.203:5060;transport=udp cworks-phones1*CLI --- Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Length: 0 Audio is at 10.2.0.2 port 13256 Adding codec 0x4 (ulaw) to SDP Adding codec 0x8 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP --- Reliably Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2;tag=as53449c29 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Type:
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
-Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users- boun...@lists.digium.com] On Behalf Of Steve J. Douglas Sent: Tuesday, February 03, 2009 3:30 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail Hi Lincoln, Asterisk was expecting ACK after sending the 200 OK message. After repeated attempts at sending the 200 OK message and not receiving ACK, it terminated the call. Are you able to do a packet capture on the phone end? Mostly likely the phone is sending the ACK, but its either sent to somewhere else or your firewall is blocking it (not likely since you are able to receive the call in the first place). The packet capture on the phone end will probably show you the smoking gun. Hi Steve, as I noted in an earlier reply the * box and the phone are on the same switch, subnet, and VLAN -- there's no routing or firewall between the two. I enabled port mirroring on the switch for the port that the phone is plugged into and ran Wireshark while a call was placed. I'm not really 100% sure of what I -should- be seeing so I'm not sure if what I'm seeing is correct or not. The call progress that I'm seeing is starting at 16.550698 seconds into the capture: 1237 Phone - Asterisk: INVITE sip:voicem...@10.2.0.2 1238 Asterisk - Phone: 407 Proxy Authentication Required 1239 Phone - Asterisk: ACK sip:voicem...@10.2.0.2 1240 Asterisk - Phone: 100 Trying 1241 Asterisk - Phone: 200 OK, with session description At that point a ton of RTP packets are exchanged with a couple ARP lookups from the phone asking for the Asterisk server. (packets 1245-1247 @ 16.6066 seconds, 1295-1297 @ 17.5701 seconds) Then there's 1299 Asterisk - Phone: 200 OK, with session description (@ 17.520362 seconds) With more RTP packets (including a couple with DTMF payloads) followed by 1402 Asterisk - Phone: 200 OK, with session description (@ 18.572025 seconds) More RTP packets and DTMF follows with 1607 Asterisk - Phone: 200 OK, with session description (@ 20.570493 seconds) More RTP and at 21.570456 seconds there's a RTCP Sender Report Source Description from Asterisk to the phone, and at 21.745548 there's an NTP sync from the Phone to one of our network time servers. Much more RTP follows with 2011 Asterisk - Phone: 200 OK, with session description (@ 24.573025 seconds) Much more RTP follows with one more RTCP Sender Report Source Description and then there's 2412 Asterisk - Phone: 200 OK, with session description (@ 28.570687 seconds) --- you get the idea --- 2814 Asterisk - Phone: 200 OK, with session description (@ 32.570784 seconds) Then starting at packet 3217 there are a series 6 of ICMP Destination unreachable (Port Unreachable) messages from the Asterisk server to the phone, with an RTP packet from the Phone to the Asterisk server before each Destination unreachable message. After that series the phone sends a series of 44 RTP packets to the * Box without getting anything back. There's then a lone ICMP Destination Unreachable (Port Unreachable) message. This sequence repeats about 10 times until the user hangs up, at which point: 3721 Phone - Asterisk: BYE sip:voicem...@10.2.0.2 (@46.335605 seconds) 3722 Asterisk - Phone: Status: 481 Call/leg transaction does not exist Now, on the other hand, a phone-to-phone call (actually the user calling my phone to let me know it failed), I do see an ACK very early on That process is Phone-Asterisk Invite Asterisk-Phone 407 Proxy Authentication Required Phone-Asterisk ACK Phone-Asterisk Invite Asterisk-Phone 100 Trying Asterisk-Phone 180 Ringing Asterisk-Phone 200 OK with session description (RTP Packets are exchanged) Phone-Asterisk ACK (RTP Packets are exchanged) Any idea why the phone would be ACKing phone-to-phone calls but not ACKing phone-to-voicemail calls? Any way to make Asterisk not drop a call just because it wasn't ACKed even though packets are still going back and forth? Thanks again for any help! Lincoln ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Lincoln King-Cliby wrote: -Original Message- Then starting at packet 3217 there are a series 6 of ICMP Destination unreachable (Port Unreachable) messages from the Asterisk server to the phone, with an RTP packet from the Phone to the Asterisk server before each Destination unreachable message. Wouldn't this suggest that either Asterisk couldn't open the port, or opened it and then closed it? Or I suppose that perhaps the phone and asterisk didn't negotiate the port properly? Does your packet capture show that the phone is consistently using the correct port to communicate with the * server? There's no change or anything, right? You don't happen to have a corresponding sip debug to this wireshark capture do you? You might be able to correlate info from the two. In your original post, I thought I read that you could reproduce this issue by increasing load on the asterisk server. What does the caller experience in the first 20 seconds when a call to voicemail is going to fail? Just ringing? Any chance there's anything in Asterisk's or the OSes logs about some failure of the network stack? What OS is this? Mark ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
-Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users- boun...@lists.digium.com] On Behalf Of Mark Wiater Sent: Tuesday, February 03, 2009 2:25 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail Wouldn't this suggest that either Asterisk couldn't open the port, or opened it and then closed it? Or I suppose that perhaps the phone and asterisk didn't negotiate the port properly? Since the RTP packets had up until that point been flowing in both directions, I'm guessing it's the middle (opened it and then closed it); no change in ports in the log, and this would seem to correspond roughly to the point at which Asterisk gives up on retrying the packet In your original post, I thought I read that you could reproduce this issue by increasing load on the asterisk server. What does the caller experience in the first 20 seconds when a call to voicemail is going to fail? Just ringing? I guess I should have been a little bit more clear on that one: Asterisk always answers calls to Voicemail more or less instantaneously. Reproducing it has been very hit-or-miss with no real correlation to network activity, call volume, time of day, day of week, phase of moon, etc. However, more often than not you can force the issue to manifest itself by by making several rapid-fire calls to voicemail from the same phone. The first 20 seconds of a call that ultimately fails is indistinguishable from a call that doesn't fail - Comedian Mail answers, accepts DTMF input from users, starts playing back messages, etc., and then all of a sudden at about the 20 second mark the audio dies. The phone still thinks that it's in a call but no more audio gets sent to the phone, DTMF input is ignored, etc. Any chance there's anything in Asterisk's or the OSes logs about some failure of the network stack? What OS is this? This is Ubuntu Server 8.1.0; as far as logs go, please excuse me -- my background is primarily Windows so I'm not sure where I would find those (but I'll Google that now ;) ) Also, an interesting side note: While I don't want to call the issue fixed yet based on how intermittent it has been, since I noticed that Asterisk indicated Ringing to the phone on SIP-to-SIP calls (that have never failed) I added: Voicemail,2,Ringing() Voicemail,3,Wait(1) To the Voicemail extension in the dialplan (I literally use Voicemail as the extension that the Messages button on the phone dials), and so far I have not been able to reproduce my issue... I don't like it because the user hears a ring cycle before the VM attendant answers, but if it keeps them from being bounced out of VM in the middle of listening to a message, I can live with it. Anyone with more knowledge of the inner workings of things want to tell me if I should or shouldn't be surprised if the issue reappears with this in place? Thanks again for the help! Lincoln ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
I'm not familiar with packets specific to Asterisk, but do have some familiarity with general Ethernet traffic. The Host unreachable messages you are getting is from the protocol stack in the Linux computer, and generally means the traffic is being sent to a port that is not open--i.e. no program in the computer has requested that port to be used for listening. In this case the most likely scenario is the SIP phone has been given the wrong port for * or * is not running. It is possible there is a firewall or other security issue. I'm not as familiar with that. Wilton ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Hi Lincoln, The fact that you can hear and respond to the voice mail (even if its for the first 20 seconds), means that your phone has received the OK message properly. The problem is the missing ACK after receiving OK. When asterisk did not receive the ACK after a few retries of the OK, it terminated the call. This resulted in your RTP streams getting the icmp error messages. Assuming that you are capturing every packet that goes on between Asterisk and the phone, there are two possibilities. 1. The phone has a bug. 2. The ACK was sent somewhere else. Normally the ACK message destination is constructed from the response to the INVITE. In this case, it will be the OK message. If you suspect its the second case, you can capture the traffic for both a good voicemail call and a failed voicemail call. Then by comparing the messages, you might get a hint. If you need help, you can send the packet capture to me privately (not through the list as it might be a large file) and I can help vet it for you. Unfortunately there is no flag that you can set to confirm a session based on OK being transmitted and not wait for ACK. Regards, Steve Lincoln King-Cliby wrote: -Original Message- From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users- boun...@lists.digium.com] On Behalf Of Steve J. Douglas Sent: Tuesday, February 03, 2009 3:30 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail Hi Lincoln, Asterisk was expecting ACK after sending the 200 OK message. After repeated attempts at sending the 200 OK message and not receiving ACK, it terminated the call. Are you able to do a packet capture on the phone end? Mostly likely the phone is sending the ACK, but its either sent to somewhere else or your firewall is blocking it (not likely since you are able to receive the call in the first place). The packet capture on the phone end will probably show you the smoking gun. Hi Steve, as I noted in an earlier reply the * box and the phone are on the same switch, subnet, and VLAN -- there's no routing or firewall between the two. I enabled port mirroring on the switch for the port that the phone is plugged into and ran Wireshark while a call was placed. I'm not really 100% sure of what I -should- be seeing so I'm not sure if what I'm seeing is correct or not. The call progress that I'm seeing is starting at 16.550698 seconds into the capture: 1237 Phone - Asterisk: INVITE sip:voicem...@10.2.0.2 1238 Asterisk - Phone: 407 Proxy Authentication Required 1239 Phone - Asterisk: ACK sip:voicem...@10.2.0.2 1240 Asterisk - Phone: 100 Trying 1241 Asterisk - Phone: 200 OK, with session description At that point a ton of RTP packets are exchanged with a couple ARP lookups from the phone asking for the Asterisk server. (packets 1245-1247 @ 16.6066 seconds, 1295-1297 @ 17.5701 seconds) Then there's 1299 Asterisk - Phone: 200 OK, with session description (@ 17.520362 seconds) With more RTP packets (including a couple with DTMF payloads) followed by 1402 Asterisk - Phone: 200 OK, with session description (@ 18.572025 seconds) More RTP packets and DTMF follows with 1607 Asterisk - Phone: 200 OK, with session description (@ 20.570493 seconds) More RTP and at 21.570456 seconds there's a RTCP Sender Report Source Description from Asterisk to the phone, and at 21.745548 there's an NTP sync from the Phone to one of our network time servers. Much more RTP follows with 2011 Asterisk - Phone: 200 OK, with session description (@ 24.573025 seconds) Much more RTP follows with one more RTCP Sender Report Source Description and then there's 2412 Asterisk - Phone: 200 OK, with session description (@ 28.570687 seconds) --- you get the idea --- 2814 Asterisk - Phone: 200 OK, with session description (@ 32.570784 seconds) Then starting at packet 3217 there are a series 6 of ICMP Destination unreachable (Port Unreachable) messages from the Asterisk server to the phone, with an RTP packet from the Phone to the Asterisk server before each Destination unreachable message. After that series the phone sends a series of 44 RTP packets to the * Box without getting anything back. There's then a lone ICMP Destination Unreachable (Port Unreachable) message. This sequence repeats about 10 times until the user hangs up, at which point: 3721 Phone - Asterisk: BYE sip:voicem...@10.2.0.2 (@46.335605 seconds) 3722 Asterisk - Phone: Status: 481 Call/leg transaction does not exist Now, on the other hand, a phone-to-phone call (actually the user calling my phone to let me know it failed), I do see an ACK very early on That process is Phone-Asterisk Invite Asterisk-Phone 407 Proxy Authentication Required Phone-Asterisk ACK Phone-Asterisk Invite Asterisk-Phone 100 Trying Asterisk-Phone 180
[asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Hi All, I posted this a couple weeks ago with no response, I'm hoping that someone will see it this time around and be so kind as to offer advice for resolving this issue (or point me in the direction of a better place to ask) Some (but not all) calls on one of our Asterisk boxes are being dropped in Voicemail -- only in voicemail -- after about 20 seconds with the error logged [Jan 19 14:33:26] WARNING[27458]: chan_sip.c:1980 retrans_pkt: Hanging up call 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 - no reply to our critical packet (see doc/sip-retransmit.txt).. We're running Asterisk 1.4.22 built from source and Cisco 7961G phones with the SIP firmware image. I've tried most of the recent firmware versions for the phones with no real impact on the issue. Strange thing is that while all of the phones use a variation on the same config file (with the only changes being the SIP account details and speed dial keys) but one user in particular seems to suffer the issue far more frequently. I would appreciate any assistance since I'm stumped. The output of SIP DEBUG for the extension most frequently affected by the issue is below; starting with one call to voicemail that was successfully completed, followed by a 2nd call that was dropped after approximately 18 seconds. The issue is consistently inconsistent - it doesn't happen on every call to Voicemail, but those that it does happen on it's always within the first approximately 20 seconds of the call; once you pass the 25 second mark you're free and clear for that call-it will not be dropped. It also seems like it's possible to reproduce the issue by making several calls to Voicemail in short order, but this isn't the only trigger as sometimes the first call to voicemail in 12+ hours will also trigger it. I'm also baffled by the fact that this ONLY crops up on calls to Voicemail on the local box; SIP to SIP calls on the same Asterisk box, SIP to SIP calls from this Asterisk box to an Asterisk Appliance at a remote site, SIP to POTS, and POTS to SIP calls are completely unaffected. Again, any advice/suggestions/things to look at/etc are greatly appreciated! Thanks in advance, Lincoln Scheduling destruction of SIP dialog '001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203' in 32000 ms (Method: INVITE) Sending to 10.2.0.203 : 5060 (no NAT) Using INVITE request as basis request - 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 18 Found RTP audio format 101 Peer audio RTP is at port 10.2.0.203:24394 Found audio description format PCMU for ID 0 Found audio description format PCMA for ID 8 Found audio description format G729 for ID 18 Found audio description format telephone-event for ID 101 Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 10.2.0.203:24394 Looking for Voicemail in internal (domain 10.2.0.2) list_route: hop: sip:1...@10.2.0.203:5060;transport=udp cworks-phones1*CLI --- Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Length: 0 Audio is at 10.2.0.2 port 13256 Adding codec 0x4 (ulaw) to SDP Adding codec 0x8 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP --- Reliably Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2;tag=as53449c29 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Type: application/sdp Content-Length: 256 v=0 o=root 27452 27452 IN IP4 10.2.0.2 s=session c=IN IP4 10.2.0.2 t=0 0 m=audio 13256 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Retransmitting #1 (no NAT) to 10.2.0.203:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2;tag=as53449c29 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
On Mon, Feb 2, 2009 at 12:39 PM, Lincoln King-Cliby linc...@controlworks.com wrote: Hi All, I posted this a couple weeks ago with no response, I'm hoping that someone will see it this time around and be so kind as to offer advice for resolving this issue (or point me in the direction of a better place to ask) Some (but not all) calls on one of our Asterisk boxes are being dropped in Voicemail -- only in voicemail -- after about 20 seconds with the error logged [Jan 19 14:33:26] WARNING[27458]: chan_sip.c:1980 retrans_pkt: Hanging up call 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 - no reply to our critical packet (see doc/sip-retransmit.txt).. We're running Asterisk 1.4.22 built from source and Cisco 7961G phones with the SIP firmware image. I've tried most of the recent firmware versions for the phones with no real impact on the issue. Strange thing is that while all of the phones use a variation on the same config file (with the only changes being the SIP account details and speed dial keys) but one user in particular seems to suffer the issue far more frequently. I would appreciate any assistance since I'm stumped. The output of SIP DEBUG for the extension most frequently affected by the issue is below; starting with one call to voicemail that was successfully completed, followed by a 2nd call that was dropped after approximately 18 seconds. The issue is consistently inconsistent - it doesn't happen on every call to Voicemail, but those that it does happen on it's always within the first approximately 20 seconds of the call; once you pass the 25 second mark you're free and clear for that call-it will not be dropped. It also seems like it's possible to reproduce the issue by making several calls to Voicemail in short order, but this isn't the only trigger as sometimes the first call to voicemail in 12+ hours will also trigger it. I'm also baffled by the fact that this ONLY crops up on calls to Voicemail on the local box; SIP to SIP calls on the same Asterisk box, SIP to SIP calls from this Asterisk box to an Asterisk Appliance at a remote site, SIP to POTS, and POTS to SIP calls are completely unaffected. Again, any advice/suggestions/things to look at/etc are greatly appreciated! Thanks in advance, Lincoln Scheduling destruction of SIP dialog '001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203' in 32000 ms (Method: INVITE) Sending to 10.2.0.203 : 5060 (no NAT) Using INVITE request as basis request - 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 18 Found RTP audio format 101 Peer audio RTP is at port 10.2.0.203:24394 Found audio description format PCMU for ID 0 Found audio description format PCMA for ID 8 Found audio description format G729 for ID 18 Found audio description format telephone-event for ID 101 Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 10.2.0.203:24394 Looking for Voicemail in internal (domain 10.2.0.2) list_route: hop: sip:1...@10.2.0.203:5060;transport=udp cworks-phones1*CLI --- Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Length: 0 Audio is at 10.2.0.2 port 13256 Adding codec 0x4 (ulaw) to SDP Adding codec 0x8 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP --- Reliably Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2;tag=as53449c29 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Type: application/sdp Content-Length: 256 v=0 o=root 27452 27452 IN IP4 10.2.0.2 s=session c=IN IP4 10.2.0.2 t=0 0 m=audio 13256 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Retransmitting #1 (no NAT) to 10.2.0.203:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Thanks to everyone who has replied so far; to answer a few of the follow up questions that have been posed: Dave - Which firmware load? We had all kinds of trouble with 8.4.x, after being stable for a few months on 8.3.x. Going back to 8.3.x made all of the weirdness disappear. While we're on the Cisco note, I have script to remotely reboot the SIP firmware load Ciscos and to provision the phones based on active directory if you're interested... back on topic: Hmm... very interesting with regard to the script. For firmware I've tried everything from 8.3.5 up to 8.4.2 with no concrete change (there was one version of 8.3.x that seemed to be a little worse, but with how hit or miss it is who knows what reality was) The other thing that's been driving me crazy is we have an Asterisk Appliance in one of our remote offices, and while the Appliance is a PITA to admin, neither of the users over there have reported any issues with any of the FW images I've pushed out. Have you run a packet cap on a mirror of the switchport the phone this is happening on is connected to? Anything strange? What's happening on the switch backplane (network backbone) at large when you notice the problems? Major transfers/lots of traffic? Anything else running on the * server? I'll need to set something up to do a packet cap; the network itself is relatively quiet, and I've been able to reproduce the issue after hours so user-generated traffic isn't in play. The * server also hosts Flash Operator Panel and Zaptel (4 FXO lines) but that's it. There are only 5.5 FTEs and 7 sets in this office so I can't imagine that we're putting that much stress on the box. Alex - Sounds like there's some sort of firewall in place or something else that is preventing an ACK from being received in response to the 200 OK. Notice that the 200 OK keeps being retransmitted. Nope, Asterisk box and phones are on the same subnet and VLAN with no routing or firewalling between the two. In fact, the phone that experiences the issue most frequently is connected to the same physical switch as the Asterisk box. Steve- I have a customer with the same complaint and I am trying to figure it out as well. I have not caught the debug action yet though. First, are you using FreePBX? Second, are you using the announce feature. No to the FreePBX question... Just plain ole regular Asterisk 1.4.22 built from source running on Ubuntu. Not sure how to answer the announce question -- when I searched voicemail.conf nothing was found. Thanks again! Lincoln ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Sounds like there's some sort of firewall in place or something else that is preventing an ACK from being received in response to the 200 OK. Notice that the 200 OK keeps being retransmitted. Lincoln King-Cliby wrote: Hi All, I posted this a couple weeks ago with no response, I'm hoping that someone will see it this time around and be so kind as to offer advice for resolving this issue (or point me in the direction of a better place to ask) Some (but not all) calls on one of our Asterisk boxes are being dropped in Voicemail -- only in voicemail -- after about 20 seconds with the error logged [Jan 19 14:33:26] WARNING[27458]: chan_sip.c:1980 retrans_pkt: Hanging up call 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 - no reply to our critical packet (see doc/sip-retransmit.txt).. We're running Asterisk 1.4.22 built from source and Cisco 7961G phones with the SIP firmware image. I've tried most of the recent firmware versions for the phones with no real impact on the issue. Strange thing is that while all of the phones use a variation on the same config file (with the only changes being the SIP account details and speed dial keys) but one user in particular seems to suffer the issue far more frequently. I would appreciate any assistance since I'm stumped. The output of SIP DEBUG for the extension most frequently affected by the issue is below; starting with one call to voicemail that was successfully completed, followed by a 2nd call that was dropped after approximately 18 seconds. The issue is consistently inconsistent - it doesn't happen on every call to Voicemail, but those that it does happen on it's always within the first approximately 20 seconds of the call; once you pass the 25 second mark you're free and clear for that call-it will not be dropped. It also seems like it's possible to reproduce the issue by making several calls to Voicemail in short order, but this isn't the only trigger as sometimes the first call to voicemail in 12+ hours will also trigger it. I'm also baffled by the fact that this ONLY crops up on calls to Voicemail on the local box; SIP to SIP calls on the same Asterisk box, SIP to SIP calls from this Asterisk box to an Asterisk Appliance at a remote site, SIP to POTS, and POTS to SIP calls are completely unaffected. Again, any advice/suggestions/things to look at/etc are greatly appreciated! Thanks in advance, Lincoln Scheduling destruction of SIP dialog '001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203' in 32000 ms (Method: INVITE) Sending to 10.2.0.203 : 5060 (no NAT) Using INVITE request as basis request - 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 18 Found RTP audio format 101 Peer audio RTP is at port 10.2.0.203:24394 Found audio description format PCMU for ID 0 Found audio description format PCMA for ID 8 Found audio description format G729 for ID 18 Found audio description format telephone-event for ID 101 Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x10c (ulaw|alaw|g729)/video=0x0 (nothing), combined - 0xc (ulaw|alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Peer audio RTP is at port 10.2.0.203:24394 Looking for Voicemail in internal (domain 10.2.0.2) list_route: hop: sip:1...@10.2.0.203:5060;transport=udp cworks-phones1*CLI --- Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Length: 0 Audio is at 10.2.0.2 port 13256 Adding codec 0x4 (ulaw) to SDP Adding codec 0x8 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP --- Reliably Transmitting (no NAT) to 10.2.0.203:5060 --- SIP/2.0 200 OK Via: SIP/2.0/UDP 10.2.0.203:5060;branch=z9hG4bK2343a87a;received=10.2.0.203 From: Jim Felderman sip:1...@10.2.0.2;tag=001d45b61d4906959ea33ab4-af2b7b8b To: sip:voicem...@10.2.0.2;tag=as53449c29 Call-ID: 001d45b6-1d490088-46ef7ed6-adbeb...@10.2.0.203 CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:voicem...@10.2.0.2 Content-Type: application/sdp Content-Length: 256 v=0 o=root 27452 27452 IN IP4 10.2.0.2 s=session c=IN IP4 10.2.0.2 t=0 0 m=audio 13256 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv
Re: [asterisk-users] No Reply to Our Critical Packet SIP Calls Dropped in Voicemail
Which firmware load? We had all kinds of trouble with 8.4.x, after being stable for a few months on 8.3.x. Going back to 8.3.x made all of the weirdness disappear. While we're on the cisco note, I have script to remotely reboot the SIP firmware load Ciscos and to provision the phones based on active directory if you're interested... back on topic: Have you run a packet cap on a mirror of the switchport the phone this is happening on is connected to? Anything strange? What's happening on the switch backplane (network backbone) at large when you notice the problems? Major transfers/lots of traffic? Anything else running on the * server? --Dave snip We're running Asterisk 1.4.22 built from source and Cisco 7961G phones with the SIP firmware image. I've tried most of the recent firmware versions for the phones with no real impact on the issue. Strange thing is that while all of the phones use a variation on the same config file (with the only changes being the SIP account details and speed dial keys) but one user in particular seems to suffer the issue far more frequently. /snip ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
-- Executing [EMAIL PROTECTED]:2] VoiceMailMain(SIP/17865221569-b6b03f60, 3523782778|s) in new stack -- SIP/17865221569-b6b03f60 Playing 'vm-youhave' (language 'en') app5*CLI --- SIP read from 74.170.252.213:5060 --- ACK sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bKaf5e8319A2DD152C From: 17865221569 sip:[EMAIL PROTECTED];tag=329CAFE3-451838A4 To: sip:[EMAIL PROTECTED];user=phone;tag=as530e3156 CSeq: 2 ACK Call-ID: [EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED] Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Proxy-Authorization: Digest username=17865221569, realm=netjdn.com, nonce=01c73ede, uri=sip:[EMAIL PROTECTED]:5060;user=phone, response=7b07733275a9401cc5d8bbdfcd4028b4, algorithm=MD5 Max-Forwards: 70 Content-Length: 0 - --- (12 headers 0 lines) --- -- SIP/17865221569-b6b03f60 Playing 'digits/1' (language 'en') Retransmitting #2 (NAT) to 74.170.252.213:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK36ec371e46AEDA45;received=74.170.252.213 From: 17865221569 sip:[EMAIL PROTECTED];tag=329CAFE3-451838A4 To: sip:[EMAIL PROTECTED];user=phone;tag=as530e3156 Call-ID: [EMAIL PROTECTED] CSeq: 2 INVITE User-Agent: HardenedSipServer-4.x Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:[EMAIL PROTECTED] Content-Type: application/sdp Content-Length: 291 v=0 o=root 26803 26803 IN IP4 74.124.208.137 s=session c=IN IP4 74.124.208.137 t=0 0 m=audio 10624 RTP/AVP 18 0 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv --- app5*CLI --- SIP read from 74.170.252.213:5060 --- ACK sip:[EMAIL PROTECTED] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bKaf5e8319A2DD152C From: 17865221569 sip:[EMAIL PROTECTED];tag=329CAFE3-451838A4 To: sip:[EMAIL PROTECTED];user=phone;tag=as530e3156 CSeq: 2 ACK Call-ID: [EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED] Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Proxy-Authorization: Digest username=17865221569, realm=netjdn.com, nonce=01c73ede, uri=sip:[EMAIL PROTECTED]:5060;user=phone, response=7b07733275a9401cc5d8bbdfcd4028b4, algorithm=MD5 Max-Forwards: 70 Content-Length: 0 - --- (12 headers 0 lines) --- -- SIP/17865221569-b6b03f60 Playing 'vm-INBOX' (language 'en') -- SIP/17865221569-b6b03f60 Playing 'vm-and' (language 'en') -- SIP/17865221569-b6b03f60 Playing 'digits/8' (language 'en') app5*CLI --- SIP read from 74.170.252.213:5060 --- REGISTER sip:sip02.netjdn.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bKe9cfe68bDC7AD066 From: 17865221569 sip:[EMAIL PROTECTED];tag=256F3E05-5ECA57DE To: sip:[EMAIL PROTECTED] CSeq: 6105 REGISTER Call-ID: [EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED];methods=INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Authorization: Digest username=17865221569, realm=netjdn.com, nonce=3a435c0d, uri=sip:sip02.netjdn.com:5060, response=9e6d6128a5e6e4508dca68b29c2c277c, algorithm=MD5 Max-Forwards: 70 Expires: 30 Content-Length: 0 - --- (12 headers 0 lines) --- Using latest REGISTER request as basis request Sending to 74.170.252.213 : 5060 (NAT) --- Transmitting (NAT) to 74.170.252.213:5060 --- SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bKe9cfe68bDC7AD066;received=74.170.252.213 From: 17865221569 sip:[EMAIL PROTECTED];tag=256F3E05-5ECA57DE To: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 6105 REGISTER User-Agent: HardenedSipServer-4.x Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: sip:[EMAIL PROTECTED] Content-Length: 0 app5*CLI --- Transmitting (NAT) to 74.170.252.213:5060 --- SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bKe9cfe68bDC7AD066;received=74.170.252.213 From: 17865221569 sip:[EMAIL PROTECTED];tag=256F3E05-5ECA57DE To: sip:[EMAIL PROTECTED];tag=as5e3cef8a Call-ID: [EMAIL PROTECTED] CSeq: 6105 REGISTER User-Agent: HardenedSipServer-4.x Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Expires: 60 Contact: sip:[EMAIL PROTECTED];expires=60 Date: Wed, 08 Oct 2008 20:14:48 GMT Content-Length: 0 Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in 32000 ms (Method: REGISTER) -- SIP/17865221569-b6b03f60 Playing 'vm-Old' (language 'en') Retransmitting #3 (NAT) to 74.170.252.213:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.54;branch=z9hG4bK36ec371e46AEDA45;received=74.170.252.213 From: 17865221569 sip:[EMAIL PROTECTED];tag=329CAFE3-451838A4 To: sip:[EMAIL PROTECTED];user=phone;tag=as530e3156 Call-ID: [EMAIL
[asterisk-users] No reply to our critical packet
I am using a Polycom 501 SIP phone behind NAT. Asterisk server is public with no NAT... everything works on the Asterisk end just fine EXCEPT that I can never check voice mail After about 30 seconds the call drops with these messagess: [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 2 (Critical Response) [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1972 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. It seems to me that the problem is the way Asterisk is handling this critical packet -- of course it can not be sent to 192.168.1.54, the phone is at that IP behind a NAT and the Asterisk server is not. I can make any other phone call from this same phone as long as it is not voicemail and I can be on the line for hours with no problem. I am really at a loss here. I have searched a bit and come up with nothing other than blaming the UA. I know the Polycoms dont have the best NAT support but besides this it works problem-free. It's odd I can make a call anywhere else even for hours and not have any issues at all but 30 seconds into a voicemail call it just drops app5*CLI sip show peer 17865221569 app5*CLI * Name : 17865221569 Secret : Set MD5Secret: Not set Context : blended-lcr Subscr.Cont. : sla_stations Language : en AMA flags: Unknown Transfer mode: closed CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : Mailbox : 17865221569 VM Extension : 14193016245 LastMsgsSent : 0/0 Call limit : 2 Dynamic : Yes Callerid : CENSORED MaxCallBR: 256 kbps Expire : 63 Insecure : no Nat : Always ACL : No T38 pt UDPTL : Yes CanReinvite : No PromiscRedir : No User=Phone : Yes Video Support: No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 74.CENSORED.213 Port 5060 Defaddr-IP : 0.0.0.0 Port 5060 Reg. exten : Def. Username: 17865221569 SIP Options : (none) Codecs : 0x104 (ulaw|g729) Codec Order : (g729:20,ulaw:20) Auto-Framing: No Status : OK (130 ms) Useragent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Reg. Contact : sip:[EMAIL PROTECTED] app5*CLI core show version Asterisk 1.4.21.1 built by root @ app5 on a i686 running Linux on 2008-07-09 01:41:43 UTC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
This message is usually caused by Asterisk not receiving an ACK after about 30 seconds of attempts. There are countless misconfigured UAs and proxies out there that don't handle ACK well, so it would be nice to be able to turn this 'feature' off. What's annoying is that the explanation has always been If we can't get an ACK, we can't send any RTP data. This is patently false, as the RTP will often work fine even if ACK handling is misconfigured (we see it all the time). But alas. As far as I can tell, there's no way to disable this check. I suppose I could code around it, but not being the world's most proficient C coder, I'm always afraid I'll break something else. ;) N. Andrew Joakimsen wrote: I am using a Polycom 501 SIP phone behind NAT. Asterisk server is public with no NAT... everything works on the Asterisk end just fine EXCEPT that I can never check voice mail After about 30 seconds the call drops with these messagess: [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 2 (Critical Response) [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1972 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. It seems to me that the problem is the way Asterisk is handling this critical packet -- of course it can not be sent to 192.168.1.54, the phone is at that IP behind a NAT and the Asterisk server is not. I can make any other phone call from this same phone as long as it is not voicemail and I can be on the line for hours with no problem. I am really at a loss here. I have searched a bit and come up with nothing other than blaming the UA. I know the Polycoms dont have the best NAT support but besides this it works problem-free. It's odd I can make a call anywhere else even for hours and not have any issues at all but 30 seconds into a voicemail call it just drops app5*CLI sip show peer 17865221569 app5*CLI * Name : 17865221569 Secret : Set MD5Secret: Not set Context : blended-lcr Subscr.Cont. : sla_stations Language : en AMA flags: Unknown Transfer mode: closed CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : Mailbox : 17865221569 VM Extension : 14193016245 LastMsgsSent : 0/0 Call limit : 2 Dynamic : Yes Callerid : CENSORED MaxCallBR: 256 kbps Expire : 63 Insecure : no Nat : Always ACL : No T38 pt UDPTL : Yes CanReinvite : No PromiscRedir : No User=Phone : Yes Video Support: No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 74.CENSORED.213 Port 5060 Defaddr-IP : 0.0.0.0 Port 5060 Reg. exten : Def. Username: 17865221569 SIP Options : (none) Codecs : 0x104 (ulaw|g729) Codec Order : (g729:20,ulaw:20) Auto-Framing: No Status : OK (130 ms) Useragent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Reg. Contact : sip:[EMAIL PROTECTED] app5*CLI core show version Asterisk 1.4.21.1 built by root @ app5 on a i686 running Linux on 2008-07-09 01:41:43 UTC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
The odd thing is on this particular phone it only happens when you call voicemail. It is certainly a bug in Asterisk, not the UA. Asterisk is trying to send to 192.168.1.x which obviously is not possible. Something in the NAT support is not working right. On Mon, Oct 6, 2008 at 3:06 PM, SIP [EMAIL PROTECTED] wrote: This message is usually caused by Asterisk not receiving an ACK after about 30 seconds of attempts. There are countless misconfigured UAs and proxies out there that don't handle ACK well, so it would be nice to be able to turn this 'feature' off. What's annoying is that the explanation has always been If we can't get an ACK, we can't send any RTP data. This is patently false, as the RTP will often work fine even if ACK handling is misconfigured (we see it all the time). But alas. As far as I can tell, there's no way to disable this check. I suppose I could code around it, but not being the world's most proficient C coder, I'm always afraid I'll break something else. ;) N. Andrew Joakimsen wrote: I am using a Polycom 501 SIP phone behind NAT. Asterisk server is public with no NAT... everything works on the Asterisk end just fine EXCEPT that I can never check voice mail After about 30 seconds the call drops with these messagess: [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 2 (Critical Response) [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1972 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. It seems to me that the problem is the way Asterisk is handling this critical packet -- of course it can not be sent to 192.168.1.54, the phone is at that IP behind a NAT and the Asterisk server is not. I can make any other phone call from this same phone as long as it is not voicemail and I can be on the line for hours with no problem. I am really at a loss here. I have searched a bit and come up with nothing other than blaming the UA. I know the Polycoms dont have the best NAT support but besides this it works problem-free. It's odd I can make a call anywhere else even for hours and not have any issues at all but 30 seconds into a voicemail call it just drops app5*CLI sip show peer 17865221569 app5*CLI * Name : 17865221569 Secret : Set MD5Secret: Not set Context : blended-lcr Subscr.Cont. : sla_stations Language : en AMA flags: Unknown Transfer mode: closed CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : Mailbox : 17865221569 VM Extension : 14193016245 LastMsgsSent : 0/0 Call limit : 2 Dynamic : Yes Callerid : CENSORED MaxCallBR: 256 kbps Expire : 63 Insecure : no Nat : Always ACL : No T38 pt UDPTL : Yes CanReinvite : No PromiscRedir : No User=Phone : Yes Video Support: No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 74.CENSORED.213 Port 5060 Defaddr-IP : 0.0.0.0 Port 5060 Reg. exten : Def. Username: 17865221569 SIP Options : (none) Codecs : 0x104 (ulaw|g729) Codec Order : (g729:20,ulaw:20) Auto-Framing: No Status : OK (130 ms) Useragent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Reg. Contact : sip:[EMAIL PROTECTED] app5*CLI core show version Asterisk 1.4.21.1 built by root @ app5 on a i686 running Linux on 2008-07-09 01:41:43 UTC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] No reply to our critical packet
On Tue, Oct 7, 2008 at 2:22 AM, Andrew Joakimsen [EMAIL PROTECTED] wrote: The odd thing is on this particular phone it only happens when you call voicemail. It is certainly a bug in Asterisk, not the UA. Asterisk is trying to send to 192.168.1.x which obviously is not possible. Something in the NAT support is not working right. Hi, You should get SIP traces to see why Asterisk is trying to reply to 192.168.1.x. To do this, enter sip set debug on in asterisk CLI, and post us a log of call reaching voicemail and disconnecting. Regards, Atis On Mon, Oct 6, 2008 at 3:06 PM, SIP [EMAIL PROTECTED] wrote: This message is usually caused by Asterisk not receiving an ACK after about 30 seconds of attempts. There are countless misconfigured UAs and proxies out there that don't handle ACK well, so it would be nice to be able to turn this 'feature' off. What's annoying is that the explanation has always been If we can't get an ACK, we can't send any RTP data. This is patently false, as the RTP will often work fine even if ACK handling is misconfigured (we see it all the time). But alas. As far as I can tell, there's no way to disable this check. I suppose I could code around it, but not being the world's most proficient C coder, I'm always afraid I'll break something else. ;) N. Andrew Joakimsen wrote: I am using a Polycom 501 SIP phone behind NAT. Asterisk server is public with no NAT... everything works on the Asterisk end just fine EXCEPT that I can never check voice mail After about 30 seconds the call drops with these messagess: [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 2 (Critical Response) [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1972 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. It seems to me that the problem is the way Asterisk is handling this critical packet -- of course it can not be sent to 192.168.1.54, the phone is at that IP behind a NAT and the Asterisk server is not. I can make any other phone call from this same phone as long as it is not voicemail and I can be on the line for hours with no problem. I am really at a loss here. I have searched a bit and come up with nothing other than blaming the UA. I know the Polycoms dont have the best NAT support but besides this it works problem-free. It's odd I can make a call anywhere else even for hours and not have any issues at all but 30 seconds into a voicemail call it just drops app5*CLI sip show peer 17865221569 app5*CLI * Name : 17865221569 Secret : Set MD5Secret: Not set Context : blended-lcr Subscr.Cont. : sla_stations Language : en AMA flags: Unknown Transfer mode: closed CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : Mailbox : 17865221569 VM Extension : 14193016245 LastMsgsSent : 0/0 Call limit : 2 Dynamic : Yes Callerid : CENSORED MaxCallBR: 256 kbps Expire : 63 Insecure : no Nat : Always ACL : No T38 pt UDPTL : Yes CanReinvite : No PromiscRedir : No User=Phone : Yes Video Support: No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 74.CENSORED.213 Port 5060 Defaddr-IP : 0.0.0.0 Port 5060 Reg. exten : Def. Username: 17865221569 SIP Options : (none) Codecs : 0x104 (ulaw|g729) Codec Order : (g729:20,ulaw:20) Auto-Framing: No Status : OK (130 ms) Useragent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Reg. Contact : sip:[EMAIL PROTECTED] app5*CLI core show version Asterisk 1.4.21.1 built by root @ app5 on a i686 running Linux on 2008-07-09 01:41:43 UTC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Atis Lezdins, VoIP Project Manager / Developer, [EMAIL PROTECTED] Skype:
[asterisk-users] No reply to our critical packet
I am using a Polycom 501 SIP phone behind NAT. Asterisk server is public with no NAT... everything works on the Asterisk end just fine EXCEPT that I can never check voice mail After about 30 seconds the call drops with these messagess: [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1950 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 2 (Critical Response) [Sep 30 23:47:48] WARNING[26819]: chan_sip.c:1972 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. It seems to me that the problem is the way Asterisk is handling this critical packet -- of course it can not be sent to 192.168.1.54, the phone is at that IP behind a NAT and the Asterisk server is not. I can make any other phone call from this same phone as long as it is not voicemail and I can be on the line for hours with no problem. I am really at a loss here. I have searched a bit and come up with nothing other than blaming the UA. I know the Polycoms dont have the best NAT support but besides this it works problem-free. It's odd I can make a call anywhere else even for hours and not have any issues at all but 30 seconds into a voicemail call it just drops app5*CLI sip show peer 17865221569 app5*CLI * Name : 17865221569 Secret : Set MD5Secret: Not set Context : blended-lcr Subscr.Cont. : sla_stations Language : en AMA flags: Unknown Transfer mode: closed CallingPres : Presentation Allowed, Not Screened Callgroup: Pickupgroup : Mailbox : 17865221569 VM Extension : 14193016245 LastMsgsSent : 0/0 Call limit : 2 Dynamic : Yes Callerid : CENSORED MaxCallBR: 256 kbps Expire : 63 Insecure : no Nat : Always ACL : No T38 pt UDPTL : Yes CanReinvite : No PromiscRedir : No User=Phone : Yes Video Support: No Trust RPID : No Send RPID: No Subscriptions: Yes Overlap dial : No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 74.CENSORED.213 Port 5060 Defaddr-IP : 0.0.0.0 Port 5060 Reg. exten : Def. Username: 17865221569 SIP Options : (none) Codecs : 0x104 (ulaw|g729) Codec Order : (g729:20,ulaw:20) Auto-Framing: No Status : OK (130 ms) Useragent: PolycomSoundPointIP-SPIP_501-UA/3.0.1.0032 Reg. Contact : sip:[EMAIL PROTECTED] app5*CLI core show version Asterisk 1.4.21.1 built by root @ app5 on a i686 running Linux on 2008-07-09 01:41:43 UTC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] no reply to our critical packet
Hello My asterisk is receiving calls from OpenSER but all calls hangup in 20 seconds. This only happens because Im using Asterisk2Billing's AGI (without A2Billing it doesnt hang up). does someone knows whats the problem?? Here is my Asterisk debug: (xxx.xxx.xxx.xxx - the phone's IP) Apr 10 02:03:02 WARNING[6996]: res_musiconhold.c:508 monmp3thread: Unable to spawn mp3player Apr 10 02:04:18 NOTICE[8349]: rtp.c:331 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: xxx.xxx.xxx.xxx Apr 10 02:04:19 WARNING[7007]: chan_sip.c:1228 retrans_pkt: Maximum retries exceeded on transmission [EMAIL PROTECTED] for seqno 12282 (Critical Response) Apr 10 02:04:19 WARNING[7007]: chan_sip.c:1245 retrans_pkt: Hanging up call [EMAIL PROTECTED] - no reply to our critical packet. Apr 10 02:06:01 NOTICE[8360]: rtp.c:331 process_rfc3389: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: xxx.xxx.xxx.xxx Thanks for the help Regards Joao Pereira ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
