[asterisk-bugs] [Asterisk 0013531]: Hold logic broken?

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13531 
====================================================================== 
Reported By:                sgofferj
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13531
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0-rc6 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-09-22 04:53 CDT
Last Modified:              2008-10-09 17:28 CDT
====================================================================== 
Summary:                    Hold logic broken?
Description: 
I have the following symptoms:

Call X-lite / Nokia E51
X-lite press hold: Nokia DOES hear MOH
Nokia press hold: X-lite does NOT hear MOH

Call X-lite / SCCP phone
MOH works as supposed

Call SCCP phone / Nokia E51
SCCP press hold: Nokia DOES hear MOH
Nokia press hold: X-lite does NOT hear MOH

In addition, the BLF on the SCCP phones does NOT show the hinted SIP
extension on hold.

With 1.4 latest, everything worked as supposed.
As this problem appears also between SIP clients, it is NOT a
chan_sccp-related issue.

====================================================================== 

---------------------------------------------------------------------- 
 (0093427) putnopvut (administrator) - 2008-10-09 17:28
 http://bugs.digium.com/view.php?id=13531#c93427 
---------------------------------------------------------------------- 
Okay, I think I see what the problem is. Asterisk checks the version string
in the o line of the SDP to see if it has increased when a new SDP arrives.
Asterisk converts this into an integer and compares this to the previous
version number to determine if there has been a change.

Now, if you look at the version number used in the reINVITE sent to
Asterisk in the nokia_calls_xlite.txt file, you'll see that the new version
number is 63390173789561876 (the old version number is one less). This is
much larger than what a 32-bit integer can hold. I ran a test program where
I used sscanf to convert these strings to integers and found that even
though the strings are different, sscanf converted both to -151378924.
They're both the same! Asterisk therefore doesn't recognize that the
version has changed in the SDP and does ignores the contents.

Considering that RFC 2327 does not give any sort of limit on the value of
version numbers and even recommends using NTP timestamps for the version
(which are 64-bit fixed-point numbers), it appears that Asterisk should
either use a 64-bit integer datatype for comparing versions or should use
string comparisons when comparing the versions. I will write a patch which
accomplishes one of these methods. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-09 17:28 putnopvut      Note Added: 0093427                          
======================================================================