[Home]

Summary:ASTERISK-06399: Retransmission of SIP-INFO DTMF causes invalid CSeq error on Cisco 5300
Reporter:element (element)Labels:
Date Opened:2006-02-22 16:39:55.000-0600Date Closed:2006-03-15 02:17:09.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Invalid_Cseq_Number_trace2.txt
Description:I am attempting to connect to a cisco 5300 connected to an IVR some distance from my Asterisk server and there is some intermittent packetloss that makes DTMF via rfc2833 not an option for my application. SIP-INFO does work but there is a problem when a INFO message is resent. What seems to be happening is the info message is sent and received by the cisco, the cisco then responds with a 200 "ok" but that packet is lost. Asterisk then re-sends the packet with the same Cseq #. The cisco then sees a new packet with a duplicated Cseq # and rejects the call with a SIP/2.0 481 Invalid CSeq Number. I think this is improper handling of the call by the cisco according to the RFC:

    However, the INFO message MUST NOT change the state of the SIP call, or the sessions initiated by SIP.

I looked more closely and found that on the Asterisk re-transmitted SIP-INFO packets the Resent Packet flag was always: "Resent Packet: False". Could this be why the Cisco is rejecting the messages? Is it reading it like "i've received 2 messages with the same CSeq number/method/callid which do not appear to be retransmitted packets and this is not allowed"?



****** ADDITIONAL INFORMATION ******

Attached is a detailed ethereal output of a call where a 200 OK message following a SIP-INFO message is missing causing asterisk to re-send the SIP-INFO message with the same call id and "CSeq: 108 INFO". The resent 108 INFO message is set to "Resent Packet: False". (packet at line 1168)

In the attached trace xxx.xxx.xxx.xxx = the asterisk server and yyy.yyy.yyy.yyy = the cisco 5300.
Comments:By: Olle Johansson (oej) 2006-02-23 06:12:12.000-0600

While ethereal dumps are cool, I really need to get a standard Asterisk SIP debug output. Set debug to 4, verbose to 4, turn on siphistory, dumphistory and SIP debugging. capture that into a file. It will show me quite a lot on what is happening on the asterisk side.
By: mikma (mikma) 2006-02-28 18:34:17.000-0600

Reading the trace it looks like Asterisk sends the INFO requests out of sequence. The request with CSeq "108 INFO" is resent after "109 INFO" and "110 INFO" have been sent. I don't think it complies with RFC 3261 Section 12.2.1.1.

  Requests within a dialog MUST contain strictly monotonically
  increasing and contiguous CSeq sequence numbers (increasing-by-one)
  in each direction (excepting ACK and CANCEL of course, whose numbers
  equal the requests being acknowledged or cancelled).
By: Olle Johansson (oej) 2006-03-04 05:44:19.000-0600

Still waiting for SIP debug output... I need to see where we are doing this and the complete signalling of this call. THanks. Will close if I don't get reply.
By: element (element) 2006-03-15 01:38:00.000-0600

Please close the ticket. I have tested numerous times and have not been able to duplicate the packet loss scenario that was happening when first connecting with the cisco to get the additional debug- sorry. Please go ahead and close this ticket.
By: Olle Johansson (oej) 2006-03-15 02:17:09.000-0600

Please re-open a bug report if it happens again and you can trace it. Thanks!