SendText causes Retransmission errors

Home » Asterisk Users » SendText causes Retransmission errors
Asterisk Users 5 Comments

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

..

The text message is sent and the call is connected, but Asterisk keeps resending OK for the INVITE, and eventually drops the call after Transmission timeout.

If I insert a WAIT after SendText, the order of the OKs changes, and everything works:

same => n,SendText(hi)
same => n,Wait(1)

same => n,SLAStation(line1234)

Here is the SIP message flow with WAIT (4 and 5 above are swapped):

1 phone => Asterisk INVITE
2 Asterisk => phone Trying
3 Asterisk => phone MESSAGE
4 phone => Asterisk OK (for the MESSAGE at 3)
5 Asterisk => phone OK (for the INVITE at 1)

Is there anything else I can do other than using WAIT (which might not be a consistent solution anyway)?

Thanks,
Matt

5 thoughts on - SendText causes Retransmission errors

  • 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, 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

  • Why did Asterisk CANCEL the call here?

    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.

  • 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)

    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).