Inception: SIP Library Integration (2006/402) Submitter: Venu Iyer Owner: Jim Carlson SUMMARY ======= * Spec update: change it so that there is no layering * Spec update: interfaces to be committed * Spec update: list examples in the documentation * MC clarifications * errno vagueness ISSUES ====== eg-1 20q-13 "Evolving" is an obsolete classification. Do you want Committed or Uncommitted? * This will be committed. eg-2 20q18 What are the conditions under which a recursive callback would cause a thread to be created? What is the impact if this happens? Is "unlikely" sufficient protection? * If this creates a thread, it will create a message and a callback. We will document what the constraints are on what a callback can/cannot do. jdc-1 20q11: "any" release? (I suspect you are aiming for a patch/micro release binding, despite the answer to 20q1, but I'm not sure.) * Right now there is no requirement but project team doesn't see why it couldn't be in the update. jdc-2 what does the project do with libscf and libuutil? * The P-team is not using any of these and are not linking any of them either. * Understand what the direct/indirect dependencies are before commitment. jdc-3 20q13: please add meaningful prefixes to all symbols that don't have them. * Will add. jdc-4 20q18: are there scaling or memory footprint targets? * This should be clarified in the documentation. jdc-5 20q18: are callbacks ever done from within the timer thread used by the library? (If so, then applications are forced to be MT.) jdc-6 Is the library actually "Safe" or "MT-Safe" or something else? (See atttributes(5).) * This is MT safe. jdc-7 sip_sendmsg (and others): does the library actually return errnos as integers in-line or does it return -1 and set errno? (Why return errnos directly?) * Most of the APIs return the -1. jdc-8 20q5:nit: usually, things in /usr/include/protocols are protocol definitions, not library interfaces. * This might be better just in /usr/include. wes-0 relationship with 2005/451 SIP Session Initiation Protocol (SIP) API? * 2005/451 was created because the project team wasn't sure about the APIs that were proposed. Now that there is feedback, the project team has created this new project. wes-1 is "layer" really the right term here for all of these components? (I'd think that, at the very least, the timer management piece wasn't a "layer") * Most of these are components so not sure that layer is the correct wording. This may need to change. wes-2 are any of these components (e.g., timer manager; refcounted message structures, etc.,) separable/reusable for other userspace protocol implementations or are they tightly bound to SIP in a not entirely hypothetical case: if we were to reimplement IKE, is there any functionality I could reuse? * The answer right now is that the project team is not sure right now with where the project is currently at. There might be but the P team does not want to commit to it right now. wes-3 MD5 hash for transaction: is this part of the protocol, or are you just using MD5 as a hash function? Is this subject to attack (MD5 is definitely past its sell-by date and is rapidly approaching its use-by date). If you're just using this for an internal hash function, could you salt the hash function to avoid bucket-collision attacks? * This is just a hash function. * Project team should consider using a stronger hash function. wes-4 is SIP timer (T1/T3/T4/alphabet soup) naming here straight from the specification, or is it something we cooked up? * This is straight out of the spec. Other issues ------------ * seb-1 I/O issue? NEXT STEP ========== * Project team will go back and resolve all issues from today's review. * ARC would like to see an updated spec.