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
