The SIPSorcery.Net.SDP parser currently expects the announcement version in the o= line to be a 32bit Integer.
However there are a number of UAs that use much larger sizes.
For example rtpengine uses an unsigned long long (64bit) populated with SSL_random. For example:
o=- 7324961500924375862 7324961500924375862 IN IP4 10.0.0.20
The parser loads this token with the Int32.TryParse method and does not check the result. Since the value above exceeds an Int32 it fails and the default value (0) is used.
The result of ToString() after loading the above o= line is:
o=- 7324961500924375862 0 IN IP4 10.0.0.20
The SDP RFC grammar does not state a size, just that it is a sequence of digits. It does however recommend using NTP timestamps, which are 64bit.
This means code processing SDP updates may ignore the update because the version field does not appear to be incremented.
The class/parser should be updated to use a 64-bit type instead. UInt64 would seem appropriate.
SteveAyre
commented
1 month ago
The SIPSorcery.Net.SDP parser currently expects the announcement version in the o= line to be a 32bit Integer.
However there are a number of UAs that use much larger sizes.
For example rtpengine uses an unsigned long long (64bit) populated with SSL_random. For example:
o=- 7324961500924375862 7324961500924375862 IN IP4 10.0.0.20The parser loads this token with the Int32.TryParse method and does not check the result. Since the value above exceeds an Int32 it fails and the default value (0) is used.
The result of ToString() after loading the above o= line is:
o=- 7324961500924375862 0 IN IP4 10.0.0.20The SDP RFC grammar does not state a size, just that it is a sequence of digits. It does however recommend using NTP timestamps, which are 64bit.
This means code processing SDP updates may ignore the update because the version field does not appear to be incremented.
The class/parser should be updated to use a 64-bit type instead. UInt64 would seem appropriate.