In the course of some (off-list) exchanges debugging our alpha test 4.1.6 system (yes - the developers have for some time been running the development branch on our production phone system; mostly it's been good, but this week is turning out to be one of those that causes us to discourage anyone else from such foolishness :-( ), the following comment was posted:
> > To my stupefactiopn, the proxy and > > phones seem to be able to cope with URIs of the format > > <sip:UNKNOWN-URL-SCHEME:[email protected]:5060;x-sipX-privcontact=192.1 > > 68.1.104>!!?!? > > scheme: sip > user: UNKNOWN-URL-SCHEME > password: 2002 > host: 99.165.237.28 > port: 5060 > URI-parameter: x-sipX-privcontact=192.168.1.104 This is a result of some C++ code path that parsed a string to construct a Url object (either using the Url class constructor, or by calling the Url::fromString method), and then did not check to see if the input string was valid. This is a serious bug! We don't throw exceptions in the sipXtackLib code, so a constructor (which just internally calls fromString) can't indicate a parsing error directly. At present, to check whether or not a Url object is valid after parsing a string into it, you MUST test: Url url( inputString ); if ( Url::UnknownUrlScheme != url.getScheme() ) { // url inputString was valid } else { // url inputString was not valid } of course, in many cases, you may want a more restrictive test (is the Url a sip or sips scheme, for example, depending on what you're going to do with it. Any time we see UNKNOWN-URL-SCHEME in a generated Url value, it means that we've been through a code path that is not checking for a valid parse - this is VERY BAD, and every time it happens we need to track down that code path and fix it. At present, the Url class doesn't internally do any enforcement of this - as demonstrated above, it will cheerfully go ahead and generate valid-looking results for the methods that access parts, and even generate a full URL string value. We should probably decide whether or not that's really what we want it to do, but for the time being let's at least hunt down any of these that we see and fix them. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
