[asterisk-dev] [Code Review] RFC3261 Section 8.1.1.5. The sequence number value MUST be expressible as a 32-bit unsigned integer

[Alec Davis]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1699/
-----------------------------------------------------------

(Updated Jan. 27, 2012, 1:41 p.m.)


Review request for Asterisk Developers.


Changes
-------

renabled the limit to 2^^31

But then there's debate about section 12.2.1.1

      With a length of 32 bits, a client could generate, within a single
      call, one request a second for about 136 years before needing to
      wrap around.  The initial value of the sequence number is chosen
      so that subsequent requests within the same call will not wrap
      around.  A non-zero initial value allows clients to use a time-
      based initial sequence number.  A client could, for example,
      choose the 31 most significant bits of a 32-bit second clock as an
      initial sequence number.


Summary
-------

By defining INITIAL_CSEQ to values near the maximum, it can clearly be seen that asterisk will represent the cseqno as negative numbers as %d is used in most places.

//#define INITIAL_CSEQ              101    /*!< Our initial sip sequence number */
#define INITIAL_CSEQ              2147483640 /*!< Our initial sip sequence number */
#define INITIAL_CSEQ              4294967290UL   /*!< Our initial sip sequence number */ 

Examples below after a few messages with INITIAL_CSEQ set to 214783640

...
Call-ID: d469d55c9e9e81ae at 192.168.y.yyy
CSeq: -2147483639 NOTIFY
User-Agent: Asterisk PBX SVN-trunk-r352864M
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 206

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="16" state="full" entity="sip:8612 at 192.168.x.xxx">

...
Call-ID: 7d1d964b7867eee008705e1e64386d4e at 192.168.x.xxx:5060
CSeq: -5 NOTIFY
User-Agent: Asterisk PBX SVN-trunk-r352864M
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 92

Messages-Waiting: no
Message-Account: sip:asterisk at 192.168.x.xxx
Voice-Message: 0/0 (0/0)


Diffs (updated)
-----

  trunk/channels/chan_sip.c 352913 
  trunk/channels/sip/include/dialog.h 352913 
  trunk/channels/sip/include/sip.h 352913 

Diff: https://reviewboard.asterisk.org/r/1699/diff


Testing
-------

Noted that Notify for BLF and MWI, that the CSeq numbers now wrapped around to 0.

After using the 2nd maximum of 2^32 minus a few (#define INITIAL_CSEQ              4294967290UL) phones, BLF and MWI still workign as normal.

Previously the BLF would stop functioning after the minus values were reached.
Now it wraps around from 4294967295 to 0, as below.

Call-ID: c2aaba2919cfcd4a at 192.168.y.yyy
CSeq: 4294967295 NOTIFY
User-Agent: Asterisk PBX SVN-trunk-r352864M
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 205

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:8612 at 192.168.x.xxx">
<dialog id="8612">

...
Call-ID: c2aaba2919cfcd4a at 192.168.y.yyy
CSeq: 0 NOTIFY
User-Agent: Asterisk PBX SVN-trunk-r352864M
Subscription-State: active
Event: dialog
Content-Type: application/dialog-info+xml
Content-Length: 205

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="5" state="full" entity="sip:8612 at 192.168.x.xxx">
<dialog id="8612">


Thanks,

Alec

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120127/d200c268/attachment-0001.htm>