[asterisk-users] SendText causes Retransmission errors

[Matt Hamilton]

> Date: Mon, 19 Mar 2012 10:31:52 -0500

> From: kpfleming at digium.com



> > 502 10.0.1.103 10.0.1.57 Request: CANCEL sip:104 at 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 at 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).
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120320/ab98d193/attachment.htm>