[Home]

Summary:ASTERISK-02446: asterisk SIP ignores SIP packets from peer in "early" state
Reporter:liamk (liamk)Labels:
Date Opened:2004-09-22 06:30:01Date Closed:2004-10-14 19:08:22
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) budgetoneProblem.pcap
Description:When using a budgetone SIP phone with asterisk, the budgetone phone sends an INFO packet when it considers itself in the early state of the dialog and so uses the same sequence number  as the previous packet it sent. This looks to be legal behaviour from the RFC - asterisk will ignore this packet though treating it as a retry - this looks like an error ...?
So in chan_sip.c:handle_request at around line 6870 of revision 1.460 the check:

} else if (p->icseq && (p->icseq == seqno)) {
                       /* ignore means "don't do anything with it" but still have to
                          respond appropriately.  We do this if we receive a repeat of
                          the last sequence number  */
                       ignore=1;
               }

should probably also include a clause which checks whether the received packet includes a 'To' tag - if it doesnt the sender probably still considers himself in the early state and so the packet should probably not be considered a retry in this case.

I enclosed a pcap file which gives an example of this problem.
Packet number 7 in this pcap trace is ignored by asterisk's SIP channel as it considers the packet a retry - note that while I think this is a probably a real problem in the asterisk code, the budgetone phone doesnt behave very well either as it still considers itself in the early state 3 seconds after the dialog has been finalised by asterisk at packet 6 - I think there is also probably a bug in the grandstream phone - my guess is it fails to treat a 183 packet as a dialog finaliser when it probably should.

In any case it looks like asterisk is not handling packets in the "early" state of the dialog correctly.

(Disclaimer - Im no expert on SIP :) )
Comments:By: liamk (liamk) 2004-09-24 05:59:25

After examining the SIP spec in more detail, Im no longer convinced that the change I request in the description here should be implemented.
I orginally got feedback from grandstream which put me on this track, but I can not find explicitly in the SIP spec where it indicates that the client can reuse the numeric part of the sequence number for further requests during the early state of the dialog.
In fact it looks like the numeric part should still be incremented as normal. (So this may be purely a grandstream issue)
If any of the SIP experts can clarify further, that would be nice.
Otherwise Im happy to have this bug closed.
Sorry for any time wasted ....
By: Mark Spencer (markster) 2004-09-25 12:56:16

It's hard to find a very clear answer to this, however according to  Section 12.2.1.1 of RFC3261:

<pre>
  The Call-ID of the request MUST be set to the Call-ID of the dialog.
  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).  Therefore, if
  the local sequence number is not empty, the value of the local
  sequence number MUST be incremented by one, and this value MUST be
  placed into the CSeq header field.  If the local sequence number is
  empty, an initial value MUST be chosen using the guidelines of
  Section 8.1.1.5.  The method field in the CSeq header field value
  MUST match the method of the request.
</pre>
However, section 12.2.2 also says:
<pre>
  If the remote sequence number is empty, it MUST be set to the value
  of the sequence number in the CSeq header field value in the request.
  If the remote sequence number was not empty, but the sequence number
  of the request is lower than the remote sequence number, the request
  is out of order and MUST be rejected with a 500 (Server Internal
  Error) response.  If the remote sequence number was not empty, and
  the sequence number of the request is greater than the remote
  sequence number, the request is in order.  It is possible for the
  CSeq sequence number to be higher than the remote sequence number by
  more than one.  This is not an error condition, and a UAS SHOULD be
  prepared to receive and process requests with CSeq values more than
  one higher than the previous received request.  The UAS MUST then set
  the remote sequence number to the value of the sequence number in the
  CSeq header field value in the request.

</pre>

And as such glaringly omits what you do if it the Cseq is the *same* as the remote sequence number.

I'll keep looking.
By: Mark Spencer (markster) 2004-10-14 14:37:53

At this point, we don't believe that it is valid to send packets in the way that Grandstream is doing so.  If you have something in an RFC to suggest otherwise, I'd certainly be willing to reopen this bug.