Re: [asterisk-users] SendText causes Retransmission errors
On 03/20/2012 01:08 PM, Matt Hamilton wrote: > Date: Mon, 19 Mar 2012 10:31:52 -0500 > From: kpflem...@digium.com > > 502 10.0.1.103 10.0.1.57 Request: CANCEL sip:104@10.0.1.57:5060 > > Why did Asterisk CANCEL the call here? I assume it's part of the SLA implementation. As I mentioned in my original email, I'm using SendText to send a text message when the user picks up a line in a SLA setup. In this case, ext 124 is calling 104, and one of the lines on 104 is picking it up. Asterisk is connecting to that line and cancelling the first request?? (just guessing) same => n,SendText(hi) same => n,SLAStation(4*104_line104) > > > *503 (for 493) 10.0.1.57 10.0.1.103 Status: 200 OK* > > 524 (503) 10.0.1.57 10.0.1.103 Request: ACK > > sip:8*104_line104@10.0.1.103:5060 > > This appears to be broken. The listing here claims this ACK is in > response to the '200 OK' in packet 503, which itself was a final > response to the MESSAGE request in packet 493. However, MESSAGE requests > do not use ACK for a three-way handshake like INVITE requests do. In > addition, this packet is going the wrong direction to be an ACK for > packet 503, since it's going the same direction as packet 503 did. I use Wireshark to capture the packets, and Wireshark is reporting it that way; i.e. saying that Request Frame for the ACK is the OK (for MESSAGE). I guess it's incorrect. The order and direction of messages I posted in my previous email are taken directly from Wireshark. Frame 15 is MESSAGE Frame 19 is OK (for MESSAGE) Frame 20 is ACK (Wireshark is saying the Request Frame is 20 ??) I tried to post the full SIP capture here, but it got rejected because of the size of the post (about 280k). Yep, that's a lot. The next step is probably to open an issue in our issue tracker and upload the capture file there (feel free to compress it first to save time and space). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _ -- 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
Re: [asterisk-users] SendText causes Retransmission errors
> Date: Mon, 19 Mar 2012 10:31:52 -0500 > From: kpflem...@digium.com > > 502 10.0.1.103 10.0.1.57 Request: CANCEL sip:104@10.0.1.57:5060 > > Why did Asterisk CANCEL the call here? I assume it's part of the SLA implementation. As I mentioned in my original email, I'm using SendText to send a text message when the user picks up a line in a SLA setup. In this case, ext 124 is calling 104, and one of the lines on 104 is picking it up. Asterisk is connecting to that line and cancelling the first request?? (just guessing) same => n,SendText(hi) same => n,SLAStation(4*104_line104) > > > *503 (for 493) 10.0.1.57 10.0.1.103 Status: 200 OK* > > 524 (503) 10.0.1.57 10.0.1.103 Request: ACK > > sip:8*104_line104@10.0.1.103:5060 > > This appears to be broken. The listing here claims this ACK is in > response to the '200 OK' in packet 503, which itself was a final > response to the MESSAGE request in packet 493. However, MESSAGE requests > do not use ACK for a three-way handshake like INVITE requests do. In > addition, this packet is going the wrong direction to be an ACK for > packet 503, since it's going the same direction as packet 503 did. I use Wireshark to capture the packets, and Wireshark is reporting it that way; i.e. saying that Request Frame for the ACK is the OK (for MESSAGE). I guess it's incorrect. The order and direction of messages I posted in my previous email are taken directly from Wireshark. Frame 15 is MESSAGE Frame 19 is OK (for MESSAGE) Frame 20 is ACK (Wireshark is saying the Request Frame is 20 ??) I tried to post the full SIP capture here, but it got rejected because of the size of the post (about 280k). -- _ -- 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
Re: [asterisk-users] SendText causes Retransmission errors
On 03/18/2012 08:07 PM, Matt Hamilton wrote: Kevin,thanks for your response. Here is the more detailed Wireshark capture of the SIP traffic between phone (10.0.1.57) and Asterisk (10.0.1.103). The numbers between parentheses are Request Frames. I don't see an ACK for the 200 OK to the INVITE (491) for the dialplan that gives us Retransmission errors (without WAIT), but there is also no ACK for the same INVITE for the dialplan that works (with WAIT). If you still want to take a look at the full packet capture, I'll post it. Matt - Without WAIT(1) - we get Retransmisson errors 486 10.0.1.57 10.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 487 10.0.1.103 10.0.1.57 Status: 401 Unauthorized 490 (486) 10.0.1.57 10.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103 491 10.0.1.57 10.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 492 10.0.1.103 10.0.1.57 Status: 100 Trying 493 10.0.1.103 10.0.1.57 Request: MESSAGE sip:104@10.0.1.57:5060 (text/plain) *500 (for 491) 10.0.1.103 10.0.1.57 Status: 200 OK, with SDP* 501 10.0.1.103 10.0.1.57 Request: NOTIFY sip:104@10.0.1.57:5060 502 10.0.1.103 10.0.1.57 Request: CANCEL sip:104@10.0.1.57:5060 Why did Asterisk CANCEL the call here? *503 (for 493) 10.0.1.57 10.0.1.103 Status: 200 OK* 524 (503) 10.0.1.57 10.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 This appears to be broken. The listing here claims this ACK is in response to the '200 OK' in packet 503, which itself was a final response to the MESSAGE request in packet 493. However, MESSAGE requests do not use ACK for a three-way handshake like INVITE requests do. In addition, this packet is going the wrong direction to be an ACK for packet 503, since it's going the same direction as packet 503 did. Whatever method you used to generate this report seems to be broken. I can't tell you exactly how it is broken without seeing the headers in the messages, though. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _ -- 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
Re: [asterisk-users] SendText causes Retransmission errors
Kevin, thanks for your response. Here is the more detailed Wireshark capture of the SIP traffic between phone (10.0.1.57) and Asterisk (10.0.1.103). The numbers between parentheses are Request Frames. I don't see an ACK for the 200 OK to the INVITE (491) for the dialplan that gives us Retransmission errors (without WAIT), but there is also no ACK for the same INVITE for the dialplan that works (with WAIT). If you still want to take a look at the full packet capture, I'll post it. Matt - Without WAIT(1) - we get Retransmisson errors 48610.0.1.5710.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 48710.0.1.103 10.0.1.57Status: 401 Unauthorized 490 (486) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103 49110.0.1.5710.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 49210.0.1.103 10.0.1.57Status: 100 Trying 49310.0.1.103 10.0.1.57Request: MESSAGE sip:104@10.0.1.57:5060 (text/plain) 500 (for 491) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP 50110.0.1.103 10.0.1.57Request: NOTIFY sip:104@10.0.1.57:5060 50210.0.1.103 10.0.1.57Request: CANCEL sip:104@10.0.1.57:5060 503 (for 493) 10.0.1.5710.0.1.103 Status: 200 OK 524 (503) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 525 (501) 10.0.1.5710.0.1.103 Status: 200 OK 52610.0.1.5710.0.1.103 Status: 487 Request Terminated 527 (for 502) 10.0.1.5710.0.1.103 Status: 200 OK 528 (502) 10.0.1.103 10.0.1.57Request: ACK sip:104@10.0.1.57:5060 585 (524) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP (resend of 500) 588 (524) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 803 (588) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP (resend of 500) 806 (588) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 1223 (806) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP (resend of 500) 1229 (806) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 2042 (1229) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP (resend of 500) 204410.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 288610.0.1.103 10.0.1.57Status: 200 OK, with SDP 288810.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 375210.0.1.103 10.0.1.57Status: 200 OK, with SDP 375510.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 - with WAIT(1). There is no more messages beyond 672 until the call is over. Everything is normal. There is no ACK for the OK for INVITE in 430 here either. 42510.0.1.5710.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 42610.0.1.103 10.0.1.57Status: 401 Unauthorized 429 (425) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103 43010.0.1.5710.0.1.103 Request: INVITE sip:8*104_line104@10.0.1.103, with SDP 43110.0.1.103 10.0.1.57Status: 100 Trying 43210.0.1.103 10.0.1.57Request: MESSAGE sip:104@10.0.1.57:5060 (text/plain) 443 (for 432) 10.0.1.5710.0.1.103 Status: 200 OK 645 (for 430) 10.0.1.103 10.0.1.57Status: 200 OK, with SDP 64610.0.1.103 10.0.1.57Request: NOTIFY sip:104@10.0.1.57:5060 64710.0.1.103 10.0.1.57Request: CANCEL sip:104@10.0.1.57:5060 667 (443) 10.0.1.5710.0.1.103 Request: ACK sip:8*104_line104@10.0.1.103:5060 668 (646) 10.0.1.5710.0.1.103 Status: 200 OK 67010.0.1.5710.0.1.103 Status: 487 Request Terminated 671 (647) 10.0.1.5710.0.1.103 Status: 200 OK 672 (for 647) 10.0.1.103 10.0.1.57Request: ACK sip:104@10.0.1.57:5060 > Date: Fri, 16 Mar 2012 10:22:49 -0500 > From: kpflem...@digium.com > To: asterisk-users@lists.digium.com > Subject: Re: [asterisk-users] SendText causes Retransmission errors > > On 03/16/2012 0
Re: [asterisk-users] SendText causes Retransmission errors
On 03/16/2012 09:43 AM, Matt Hamilton wrote: Hi, I'm using SendText to send a text message when the user picks up a line in a SLA setup (even though I'm not sure the problem is related to SLA). I'm on Asterisk 10.2.1 (same in 1.8.9) [from-office] .. same => n,SendText(hi) same => n,SLAStation(line1234) .. Here is a simplified version of the SIP messages: 1 phone => Asterisk INVITE 2 Asterisk => phone Trying 3 Asterisk => phone MESSAGE 4 Asterisk => phone OK (for the INVITE at 1) 5 phone => Asterisk OK (for the MESSAGE at 3) 6 Asterisk => phone OK (for the INVITE at 1)*** RESEND of 4 7 Asterisk => phone OK (for the INVITE at 1)*** RESEND of 4 .. Did the phone send an ACK for message 4? If not, that explains why Asterisk is retransmitting the '200 OK'. Posting a packet capture of this problem occurring would probably provide the details necessary to figure out what is going on. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org -- _ -- 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
