Hey Scott,
I ran into this issue where an o’s sess-id causes an overflow, but couldn’t find in RFC 4566 where it states the max value is limited. The syntax for sess-id is 1*DIGIT. The only other note is that the value is *suggested* to be an NTP timestamp. I just wanted to clarify if the resip implementation is following best practice or a hard rule somewhere. This is the first I’ve come across it so I’m inclined to leave resip as is and push back on the vendor.
Thanks.
-justin
From: resiprocate-commit-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-commit-bounces@xxxxxxxxxxxxxxx] On Behalf Of svn@xxxxxxxxxxxxxxx
Sent: Saturday, February 20, 2010 1:18 PM
To: resiprocate-commit@xxxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate-commit] resiprocate 8751 sgodin: -added try/catch blocks around origin sessionid and version parsing - to insulate resip
Project | resiprocate |
New Revision | 8751 |
Committer | sgodin (Scott Godin) |
Date | 2010-02-20 12:17:31 -0600 (Sat, 20 Feb 2010) |
Log
-added try/catch blocks around origin sessionid and version parsing - to insulate resip
from implementations that do not correctly populate these (ie. sessionid or version > Uint64)
-fix to recon for participant replacement
Modified: