From jw137282@sac.sfbay.sun.com Sun May 3 22:22:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n445MlqQ014293 for ; Sun, 3 May 2009 22:22:47 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n445MiT8020558; Mon, 4 May 2009 13:22:46 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ300A01TLXZP00@brm-avmta-1.central.sun.com>; Sun, 03 May 2009 23:22:45 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ3005ZRTLXR4D0@brm-avmta-1.central.sun.com>; Sun, 03 May 2009 23:22:45 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n445Mh3Y013365; Sun, 03 May 2009 22:22:43 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n445Mcx5014288; Sun, 03 May 2009 22:22:38 -0700 (PDT) Received: (from jw137282@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n445Mc3W014284; Sun, 03 May 2009 22:22:38 -0700 (PDT) Date: Sun, 03 May 2009 22:22:38 -0700 (PDT) From: James Walker Subject: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] To: LSARC-ext@sun.com Cc: simon.sun@sun.com Message-id: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3115 I'm sponsoring this familiarity case for Simon Sun. The requested release binding is minor. The man page has been posted in the materials directory. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libosip2 1.2. Name of Document Author/Supplier: Author: Simon Sun 1.3 Date of This Document: 03 May, 2009 4. Technical Description 4. Technical Description: oSIP is an implementation of SIP. SIP stands for the Session Initiation Protocol and is described by the rfc3261 (wich deprecates rfc2543). This library aims to provide multimedia and telecom software developers an easy and powerful interface to initiate and control SIP based sessions in their applications. SIP is a open standard replacement from IETF for H323. The GNU oSIP library is written in C and get no dependencies except the standard C library. oSIP is thread safe and will generally be used in a multi-threaded application. Nevertheless, this is optional. oSIP is little in size and code and thus could be use to implement IP soft-phone as well as embedded SIP software. oSIP is not limited to endpoint agents, and can also be used to implement "SIP proxy". oSIP does not intend to provide a high layer API for controlling "SIP Session" at this step. Instead, it currently provides an API for the SIP message parser, SDP message parser, and library to handle "SIP transactions" as defined by the SIP document. oSIP 2-3.3.0 will be delivered as SUNWlibosip2 via the SFW consolidation. A minor release binding is requested. 5. Interfaces Exported interface Classification Interface type ============================= ============== ============== SUNWlibosip2 Uncommitted Package name /usr/include/osip2/ Uncommitted Header files /usr/include/osipparser2/ Uncommitted Header files /usr/lib/ /usr/lib/{amd64 | sparcv9}/ libosip2.so.4.2.0 Uncommitted libosip2 library libosipparser2.so.4.2.0 Uncommitted libosipparser2 library /usr/lib/ /usr/lib/{amd64 | sparcv9}/ libosip2.so Uncommitted sym link libosip2.so.4 Uncommitted sym link libosipparser2.so Uncommitted sym link libosipparser2.so.4 Uncommitted sym link /usr/lib/pkgconfig/libosip2.pc Uncommitted pkg config file Imported interface Classification Interface type ============================= ============== ============== SUNWlibmsr Committed Math Libraries (Root) Appendix A - References [1] http://http://www.gnu.org/software/osip/ OSR ID# 10948 RFE ID# 6826484 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Mon May 4 04:14:17 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n44BEHTp009251 for ; Mon, 4 May 2009 04:14:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n44BEDcR008209 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.Com>; Mon, 4 May 2009 12:14:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ400I019VR2O00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 04 May 2009 04:14:15 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ400B2A9VQTW70@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 04 May 2009 04:14:14 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n44BECEH019193; Mon, 04 May 2009 07:14:12 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n44BDRwg014107; Mon, 04 May 2009 07:13:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n44BDRpH014104; Mon, 04 May 2009 07:13:27 -0400 (EDT) Date: Mon, 04 May 2009 07:13:27 -0400 From: James Carlson Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> To: James Walker Cc: LSARC-ext@sun.com, Simon.Sun@sun.com Message-id: <18942.52695.592135.904713@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> Status: RO Content-Length: 778 James Walker writes: > oSIP is little in size and code and thus could be use to implement IP > soft-phone as well as embedded SIP software. oSIP is not limited to endpoint > agents, and can also be used to implement "SIP proxy". What (if anything) will be done with the existing SIP library and SIP proxy that are already in OpenSolaris? Will the documentation say anything about the duplication? How should developers working on SIP applications on OpenSolaris choose between them? Is there anything that uses or will use this new library? -- James Carlson, Solaris Networking 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 From Simon.Sun@sun.com Tue May 5 16:56:11 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n45NuAGm013248 for ; Tue, 5 May 2009 16:56:10 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n45Nu2YQ019492 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 6 May 2009 07:56:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ7009033TIJL00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 16:56:06 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ7002TT3THLB50@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 05 May 2009 16:56:06 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n45Nu5S0011613 for ; Tue, 05 May 2009 23:56:05 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJ700A003QHJJ00@mail-apac.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 06 May 2009 07:56:04 +0800 (SGT) Received: from [192.168.1.100] ([unknown] [129.150.144.16]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJ7004R13TFRL30@mail-apac.sun.com>; Wed, 06 May 2009 07:56:04 +0800 (SGT) Date: Wed, 06 May 2009 07:55:51 +0800 From: Simon Sun Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <18942.52695.592135.904713@gargle.gargle.HOWL> Sender: Simon.Sun@sun.com To: James Carlson Cc: James Walker , LSARC-ext@sun.com Message-id: <4A00D207.5020504@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 1228 Hi James, Below is my answer to your concern. If there's anything improper, please let me know. Sorry for the late reply. cheers, Simon James Carlson wrote: > James Walker writes: > >> oSIP is little in size and code and thus could be use to implement IP >> soft-phone as well as embedded SIP software. oSIP is not limited >> to endpoint >> agents, and can also be used to implement "SIP proxy". >> > > What (if anything) will be done with the existing SIP library and SIP > proxy that are already in OpenSolaris? > Nothing needed for the current SIP stuff since there's no conflict between each other. > Will the documentation say anything about the duplication? I'm not sure since it's difficult to describe this very clearly. If needed, any suggestion? > How should > developers working on SIP applications on OpenSolaris choose between > them? > oSIP is an GNU open-source project and the interfaces are quite different from which in SIP. The end user can make the decision on using which. With libosip2 integrated, we provide the end user another choice. > Is there anything that uses or will use this new library? > Another library named libexosip2 will use it after being put back. From carlsonj@phorcys.east.sun.com Wed May 6 06:07:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n46D7K1F018644 for ; Wed, 6 May 2009 06:07:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46D7JGE010725 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Wed, 6 May 2009 14:07:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ800D0F4G69500@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 06 May 2009 06:07:18 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ8005NB4G4SD80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 06 May 2009 06:07:17 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n46D7Fre061038; Wed, 06 May 2009 09:07:15 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n46D6S2u022471; Wed, 06 May 2009 09:06:28 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n46D6Sj7022468; Wed, 06 May 2009 09:06:28 -0400 (EDT) Date: Wed, 06 May 2009 09:06:28 -0400 From: James Carlson Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <4A00D207.5020504@sun.com> To: Simon Sun Cc: James Walker , LSARC-ext@sun.com Message-id: <18945.35668.430278.289528@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> Status: RO Content-Length: 2200 Simon Sun writes: > James Carlson wrote: > > What (if anything) will be done with the existing SIP library and SIP > > proxy that are already in OpenSolaris? > > > Nothing needed for the current SIP stuff since there's no conflict > between each other. What happens if someone tries to use both SIP proxies on a single system? What happens if a process ends up with both SIP libraries linked into it due to library dependencies? (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?) > > Will the documentation say anything about the duplication? > I'm not sure since it's difficult to describe this very clearly. If > needed, any suggestion? At a minimum, we have to tell people which implementations are the preferred and supported ones. See the PAC advice delivered as part of PSARC 2009/147 ("tcpdump"): When delivering multiple implementations of a single feature, and where an extended period of co-existence rather than eventual replacement is expected, the Solaris PAC and the management of the on-going "familiarity" project are advised that the ARC requires explicit information regarding which of the co-existing implementations is regarded as "preferred." The short answer is that OpenSolaris is supposed to be a coherent system, not just a random assemblage of parts. > > How should > > developers working on SIP applications on OpenSolaris choose between > > them? > > > oSIP is an GNU open-source project and the interfaces are quite > different from which in SIP. The end user can make the decision on using > which. With libosip2 integrated, we provide the end user another choice. Or just architectural confusion. It's unclear which we get. > > Is there anything that uses or will use this new library? > > > Another library named libexosip2 will use it after being put back. Is there any _application_ that will be using it? -- James Carlson, Solaris Networking 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 From Simon.Sun@sun.com Tue May 12 03:47:10 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4CAhPZL001532 for ; Tue, 12 May 2009 03:47:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4CAhONx063909 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 12 May 2009 04:43:25 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJJ00A0J1SBWP00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 12 May 2009 03:43:23 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJJ00MBN1S9NPF0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 12 May 2009 03:43:22 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4CAhLRR021597 for ; Tue, 12 May 2009 10:43:21 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJJ00D001S5DP00@mail-apac.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 12 May 2009 18:43:21 +0800 (SGT) Received: from [129.158.218.131] ([unknown] [129.158.218.131]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJJ00COZ1S81U20@mail-apac.sun.com>; Tue, 12 May 2009 18:43:21 +0800 (SGT) Date: Tue, 12 May 2009 18:35:40 +0800 From: Simon Sun Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <18945.35668.430278.289528@gargle.gargle.HOWL> Sender: Simon.Sun@sun.com To: James Carlson Cc: James Walker , LSARC-ext@sun.com Message-id: <4A0950FC.2020302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.0 (X11/20070423) Status: RO Content-Length: 4314 Hi James, Please see my in-line comments below. cheers, Simon James Carlson wrote: > Simon Sun writes: > >> James Carlson wrote: >> >>> What (if anything) will be done with the existing SIP library and SIP >>> proxy that are already in OpenSolaris? >>> >> Nothing needed for the current SIP stuff since there's no conflict >> between each other. >> > > What happens if someone tries to use both SIP proxies on a single > system? > 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. Usually the port number can be changed in configuration file in the proxy to prevent this from happening. For example, the Sip Express Router(ser) which has been included in Solaris has a configuration file /etc/sfw/ser/ser.cfg which is with the below section: # # port to listen on. default is 5060 # #port=5090 > What happens if a process ends up with both SIP libraries linked into > it due to library dependencies? > > (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. If it's proper, we can strongly suggest the user not to use the two library at the same time and includes that in man page. > >>> Will the documentation say anything about the duplication? >> I'm not sure since it's difficult to describe this very clearly. If >> needed, any suggestion? >> > At a minimum, we have to tell people which implementations are the > preferred and supported ones. See the PAC advice delivered as part of > PSARC 2009/147 ("tcpdump"): > > When delivering multiple implementations of a single > feature, and where an extended period of co-existence rather > than eventual replacement is expected, the Solaris PAC and > the management of the on-going "familiarity" project are > advised that the ARC requires explicit information regarding > which of the co-existing implementations is regarded as > "preferred." > > 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. 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. >>> How should >>> developers working on SIP applications on OpenSolaris choose between >>> them? >>> >> oSIP is an GNU open-source project and the interfaces are quite >> different from which in SIP. The end user can make the decision on >> using which. With libosip2 integrated, we provide the end user >> another choice. >> > 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. > >>> Is there anything that uses or will use this new library? >>> >> Another library named libexosip2 will use it after being put back. >> > 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/ From carlsonj@phorcys.east.sun.com Tue May 12 05:50:34 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4CCkmLR000924 for ; Tue, 12 May 2009 05:50:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4CCklg8004873 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Tue, 12 May 2009 13:46:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJJ00E157HZPU00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 12 May 2009 05:46:47 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJJ004YF7HYY1D0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 12 May 2009 05:46:47 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4CCgu28026322; Tue, 12 May 2009 08:42:56 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4CCg5LU007466; Tue, 12 May 2009 08:42:05 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4CCg5aA007463; Tue, 12 May 2009 08:42:05 -0400 (EDT) Date: Tue, 12 May 2009 08:42:05 -0400 From: James Carlson Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <4A0950FC.2020302@sun.com> To: Simon Sun Cc: James Walker , LSARC-ext@sun.com Message-id: <18953.28317.770727.576039@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> Status: RO Content-Length: 5667 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 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 From Simon.Sun@sun.com Wed May 13 05:06:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4DC6mAZ012615 for ; Wed, 13 May 2009 05:06:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4DC5Ylg026487 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 13 May 2009 13:06:47 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJL00F110B6S700@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 06:06:42 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJL00E6P0B4YYE0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 06:06:41 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4DC6dEg026396 for ; Wed, 13 May 2009 12:06:39 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KJL00K0009HVX00@mail-apac.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 20:06:39 +0800 (SGT) Received: from [192.168.1.100] ([unknown] [129.150.144.12]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KJL009WP0B1Y8K0@mail-apac.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 20:06:39 +0800 (SGT) Date: Wed, 13 May 2009 20:06:14 +0800 From: Simon Sun Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <18953.28317.770727.576039@gargle.gargle.HOWL> Sender: Simon.Sun@sun.com To: James Carlson Cc: Jim Walker , LSARC-ext@sun.com Message-id: <4A0AB7B6.4000805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> <18953.28317.770727.576039@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 7235 Hi James, Please check my in line comments below. cheers, Simon James Carlson wrote: > 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. > I'd express it explicitly in man page of libopsip2 like this: Solaris provides another library named libsip for SIP development purpose. We'd suggest you to consider using it instead. Please check the man page libsip(3LIB) for more info and refer to the developer guide at http://docs.sun.com/app/docs/doc/820-0643. > 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? > Since I'm not quite clear the criterion of ARC, my suggestion is like this. If it's an existing application and depends on libosip2, no need to let he/she change to libsip since it means the code should be rewritten from the beginning. If not and it's a brand new project for SIP, ARC can ask them to use libsip. > >> 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. > Thanks for making it clear. The point is we do provide a way for user to develop their application before libusb is put back. Then we put back libusb to provide another way. > 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? > I don't think so. With libsip, it means Solaris provides that part of functionality support for developer to write SIP components and applications. > 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? > I guess at least fore part of the assertion is still true. For a brand new project on SIP, the developer can surely implement it with libsip. No needs libosip2. > >>> 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? > These application will not be delivered by this case and I'm not sure if someone is working on porting them. None of them works with 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.) > By putting back libosip2, it's pretty straight forward for some GNU project based on oSIP. Just compile it and that's done. From carlsonj@phorcys.east.sun.com Wed May 13 05:41:21 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4DCfLoc012856 for ; Wed, 13 May 2009 05:41:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4DCfJVo007264 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Wed, 13 May 2009 05:41:21 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJL00J0B1WWB100@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 06:41:20 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJL00EUZ1WVZ0E0@brm-avmta-1.central.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 06:41:20 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4DCfIWO033510; Wed, 13 May 2009 08:41:18 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4DCeRVY011408; Wed, 13 May 2009 08:40:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4DCeROJ011405; Wed, 13 May 2009 08:40:27 -0400 (EDT) Date: Wed, 13 May 2009 08:40:27 -0400 From: James Carlson Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <4A0AB7B6.4000805@sun.com> To: Simon Sun Cc: Jim Walker , LSARC-ext@sun.com Message-id: <18954.49083.768692.627709@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> <18953.28317.770727.576039@gargle.gargle.HOWL> <4A0AB7B6.4000805@sun.com> Status: RO Content-Length: 1850 Simon Sun writes: > > Please indicate which one of these two will be "preferred" and what > > the documentation will say. > > > I'd express it explicitly in man page of libopsip2 like this: > > Solaris provides another library named libsip for SIP development > purpose. We'd suggest you to consider using it instead. Please check > the man page libsip(3LIB) for more info and refer to the developer guide > at http://docs.sun.com/app/docs/doc/820-0643. That seems reasonable; thanks. > > 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? > > > Since I'm not quite clear the criterion of ARC, my suggestion is like > this. If it's an existing application and depends on libosip2, no need > to let he/she change to libsip since it means the code should be > rewritten from the beginning. If not and it's a brand new project for > SIP, ARC can ask them to use libsip. OK. That's the bit of policy information I was looking for. > > Are these being delivered by this or by some other project? And do > > any of them work with the existing libsip? > > > These application will not be delivered by this case and I'm not sure if > someone is working on porting them. None of them works with libsip. I urge the project team to consider bringing in at least one application that makes use of this library. Libraries without consumers are, in my opinion, just baggage. And in this case, given that the library also represents functional duplication, it doesn't provide much of an offsetting gain. -- James Carlson, Solaris Networking 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 From James.Walker@sun.com Wed May 13 13:10:08 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4DKA7uY022277 for ; Wed, 13 May 2009 13:10:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4DKA3a4018494 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 13 May 2009 13:10:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJL00G0PMOTXW00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:10:06 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJL00FWEMOT9D00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:10:05 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4DKA5Uh022731 for ; Wed, 13 May 2009 20:10:05 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJL00500M92CP00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:10:05 -0600 (MDT) Received: from c-67-166-22-238.hsd1.co.comcast.net ([unknown] [129.150.34.241]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJL00DBGMOJ6230@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:09:55 -0600 (MDT) Date: Wed, 13 May 2009 14:09:55 -0600 From: Jim Walker Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <18954.49083.768692.627709@gargle.gargle.HOWL> Sender: James.Walker@sun.com To: James Carlson Cc: Simon Sun , LSARC-ext@sun.com Reply-to: James.Walker@sun.com Message-id: <4A0B2913.2090506@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> <18953.28317.770727.576039@gargle.gargle.HOWL> <4A0AB7B6.4000805@sun.com> <18954.49083.768692.627709@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 757 James Carlson wrote: > >>> Are these being delivered by this or by some other project? And do >>> any of them work with the existing libsip? >>> >> These application will not be delivered by this case and I'm not sure if >> someone is working on porting them. None of them works with libsip. > > I urge the project team to consider bringing in at least one > application that makes use of this library. Libraries without > consumers are, in my opinion, just baggage. And in this case, given > that the library also represents functional duplication, it doesn't > provide much of an offsetting gain. > We are looking into this already. I plan to submit the libexosip2 case after this one which is required by many of the osip2 apps. Cheers, Jim From carlsonj@phorcys.east.sun.com Wed May 13 13:23:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4DKNXvg022433 for ; Wed, 13 May 2009 13:23:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4DKNW13043523 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@Sun.COM>; Wed, 13 May 2009 14:23:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJL00D0NNB6JZ00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 13:23:30 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJL008HPNB5P1A0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 13:23:30 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4DKNUuN020651; Wed, 13 May 2009 16:23:30 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n4DKMdje013248; Wed, 13 May 2009 16:22:39 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n4DKMdtZ013245; Wed, 13 May 2009 16:22:39 -0400 (EDT) Date: Wed, 13 May 2009 16:22:39 -0400 From: James Carlson Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <4A0B2913.2090506@sun.com> To: James.Walker@sun.com Cc: Simon Sun , LSARC-ext@sun.com Message-id: <18955.11279.28457.163061@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> <18953.28317.770727.576039@gargle.gargle.HOWL> <4A0AB7B6.4000805@sun.com> <18954.49083.768692.627709@gargle.gargle.HOWL> <4A0B2913.2090506@sun.com> Status: RO Content-Length: 913 Jim Walker writes: > James Carlson wrote: > > I urge the project team to consider bringing in at least one > > application that makes use of this library. Libraries without > > consumers are, in my opinion, just baggage. And in this case, given > > that the library also represents functional duplication, it doesn't > > provide much of an offsetting gain. > > > > We are looking into this already. > > I plan to submit the libexosip2 case after this one which is > required by many of the osip2 apps. We already went through that ... libexosip2 isn't an application, either. I'm suggesting that having a library as the top level deliverable isn't necessarily an interesting thing. -- James Carlson, Solaris Networking 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 From James.Walker@sun.com Wed May 13 13:49:22 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4DKnLae023260 for ; Wed, 13 May 2009 13:49:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n4DKn68S013858 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 13 May 2009 21:49:20 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJL00F05OI61X00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 13:49:18 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJL008UIOI5P5C0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 13:49:18 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4DKnJ2T017965 for ; Wed, 13 May 2009 20:49:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJL00200NFP3F00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:49:19 -0600 (MDT) Received: from c-67-166-22-238.hsd1.co.comcast.net ([unknown] [129.150.34.241]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJL00GYHOI6E3D0@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 13 May 2009 14:49:18 -0600 (MDT) Date: Wed, 13 May 2009 14:49:17 -0600 From: Jim Walker Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <18955.11279.28457.163061@gargle.gargle.HOWL> Sender: James.Walker@sun.com To: James Carlson Cc: Simon Sun , LSARC-ext@sun.com Reply-to: James.Walker@sun.com Message-id: <4A0B324D.4040608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> <18942.52695.592135.904713@gargle.gargle.HOWL> <4A00D207.5020504@sun.com> <18945.35668.430278.289528@gargle.gargle.HOWL> <4A0950FC.2020302@sun.com> <18953.28317.770727.576039@gargle.gargle.HOWL> <4A0AB7B6.4000805@sun.com> <18954.49083.768692.627709@gargle.gargle.HOWL> <4A0B2913.2090506@sun.com> <18955.11279.28457.163061@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 1077 James Carlson wrote: > Jim Walker writes: >> James Carlson wrote: >>> I urge the project team to consider bringing in at least one >>> application that makes use of this library. Libraries without >>> consumers are, in my opinion, just baggage. And in this case, given >>> that the library also represents functional duplication, it doesn't >>> provide much of an offsetting gain. >>> >> We are looking into this already. >> >> I plan to submit the libexosip2 case after this one which is >> required by many of the osip2 apps. > > We already went through that ... libexosip2 isn't an application, > either. I'm suggesting that having a library as the top level > deliverable isn't necessarily an interesting thing. I understand. We should have a candidate osip2 / exosip2 app soon. The initial app that was driving this case got lost somewhere? I'm still searching the email ;) Maybe these were on the FOSS 500 list. The libraries themselves seemed useful enough to warrant porting on their own. But it is better let the consumer apps drive things more. Cheers, Jim From James.Walker@sun.com Tue May 19 16:15:33 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n4JNFX89025381 for ; Tue, 19 May 2009 16:15:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n4JNFWDN029204 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 19 May 2009 16:15:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJW00I0XZ9T7E00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 19 May 2009 17:15:29 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJW00N04Z9R4HE0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 19 May 2009 17:15:27 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n4JNFRhD014089 for ; Tue, 19 May 2009 23:15:27 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KJW00A00Z6V8L00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 19 May 2009 17:15:27 -0600 (MDT) Received: from [172.20.25.153] ([unknown] [172.20.25.153]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KJW002LSZ9PV720@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 19 May 2009 17:15:26 -0600 (MDT) Date: Tue, 19 May 2009 17:26:42 -0600 From: Jim Walker Subject: Re: libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009] In-reply-to: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> Sender: James.Walker@sun.com To: LSARC-ext@sun.com Cc: Simon.Sun@sun.com Reply-to: James.Walker@sun.com Message-id: <4A134032.1010209@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200905040522.n445Mc3W014284@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 204 This case was approved at the LSARC meeting today. The project team plans to update the libosip man page to indicate that libsip is the current preferred sip library on Solaris/OpenSolaris. Cheers, Jim