Simon Sun writes: > By default, the port 5060 is for SIP use. If two instances of one SIP > proxy were started up, the latter one should fail since the default port > has been occupied by the first instance. Same thing will happen to the > two different proxies. It has nothing do with the library underneath. > For this case, we just want to put back the library into SFW gate at > this moment.
I'm aware of what you're asking. I'm not sure what users will be told through the documentation. > > (I'm guessing the answers are that things may break, and, since it's > > just an "option," we don't really care. Is that right?) > > > It's incorrect. We do care the user's feeling. > > Actually there's no dependency between libsip and libosip2. All the > interfaces and implementation are quite different from each other. There > is almost certainly no sane reason to use both at once since it will > definitely increase the complexity of the program. I'm not asking about what someone may do intentionally, but rather what may *happen*. Accidentally having incompatible libraries loaded at the same time is unfortunately quite common -- it happens because libraries themselves have dependencies, as do plug-in modules. I looked at the source code for both, and it appears there's no symbol overlap, so the chance of failure seems pretty low. > > The short answer is that OpenSolaris is supposed to be a coherent > > system, not just a random assemblage of parts. > > > > > Yes, absolutely. Since we've provided SIP support in Solaris, by adding > another one which is more commonly used by OpenSource community, we can > attract more user who is based on oSIP to Solars and lose nothing. Later > on, we can port other application based on oSIP on other platform into > Solaris. The policy I cited from PSARC 2009/147 said that the preferred implementation needs to be pointed out to users so that when there are duplicates, users know what they're getting. Please indicate which one of these two will be "preferred" and what the documentation will say. In particular: when future projects come to the ARC and propose to be dependent on libosip2, should we tell them that they need to use libsip instead? > It's similar to the libusb. Even through in Solaris we provide the > USBA, we still put back libusb into Solaris to provide the end user > another choice. I don't think this situation is similar at all. USBA provides kernel interfaces to allow you to write a native driver for a USB device. libusb(3LIB) provides a way to write a user-space driver for USB. In contrast, what we're talking about are two user-space libraries with substantially the same functionality and just different names. Let's stick to SIP. Analogies like this to other cases tend to break down in the details. > > Or just architectural confusion. It's unclear which we get. > > > They are two different implementations which are compliant with the RFC > 3261. The user can choose the one he/she is more familiar with. That part is not true, and that's the problem I'm trying to get at. The idea of having a coherent system architecture is immiscible with the notion of allowing users to pick and choose random internal components to construct the system. We don't allow (for instance) users to pick and choose between Sun's libc and GNU's glibc. It's not that users don't want that kind of choice -- undoubtedly some do want it -- we don't do it because allowing this sort of choice for developers would lead to chaos for end users. The two libraries are not just plug-in replacements for each other. Allowing users to pick and choose among foundational libraries such as SIP is similarly suspicious. It causes at _best_ a fork in the road, where some common features and bug fixes are available with some applications but not with others, and all seemingly at random, depending only on the whim of the developer. Worse, it causes confusion for future projects because we're left without an actual system architecture of record. In this case, you're not really talking about "users," because real users neither know nor care about libraries. They're not runnable, and users don't actually get to "choose" in any meaningful sense. You're talking instead about _developers_, and that leads inevitably to the question of applications and about system architecture. So, did we err by letting in PSARC 2006/402 and the follow-on cases? The assertions of the developers in that project were that applications would *not* need libosip2, and that Sun's libsip would provide the necessary SIP functionality, and that it would be ported to other platforms. Has that changed? > > Is there any _application_ that will be using it? > > > > > partysip: A Linux SIP proxy based on osip2 (LGPL) > http://www.nongnu.org/partysip/partysip.html > > SFLphone: A multiplatform, open source SIP user agent. It is based on > several libraries: cc++, ccRTP, osip2+eXosip: > http://www.sflphone.org/ > > GNU SIP Witch - call and registration server for the SIP protocol > GNU Bayonne - telephony server > http://www.gnu.org/software/gnucomm/ Are these being delivered by this or by some other project? And do any of them work with the existing libsip? (One of the assertions of the libsip project team was that they'd work with application providers to make sure that those applications were ported and worked on Solaris.) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
