Christer, > The important thing is that people get the relatively small number of core > specifications correct - specs like 3261, 3264 etc. If you don't get those > right, it doesn't matter if you have implemented every other SIP related > specification out there...
I could not agree with you more. Incidentally, we have also published such a short list in "Simple SIP Usage Scenario for Applications in the Endpoints" http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-03.txt We could compare notes, though our I-D is tailored to the usage scenario where all applications reside in the endpoints and only the rendezvous and session setup of SIP are used. This usage scenario is of interest when combining SIP with Rich Internet Applications (RIA) in the Web browser. So many apps are in the browser already, so why not add SIP apps? Could you help out and share what the short list of key SIP standards may be for other usage scenarios? This is of interest to a larger audience. Henry On 8/26/08 12:01 AM, "Christer Holmberg" <[EMAIL PROTECTED]> wrote: > > Hi Henry, > > As I've said before, I don't think the number of standards is the problem. > > Many of the extension specifications simply specify ways (headers, parameters > etc) to transport specific data. Those normally don't have big impact on the > core SIP state machine, and whether they are implemented or not depends on the > requirements of the network environment in which they are to be used. If there > are no requirement, it doesn't matter whether you have implemented header X > and I haven't (the header should simply be ignored). > > The important thing is that people get the relatively small number of core > specifications correct - specs like 3261, 3264 etc. If you don't get those > right, it doesn't matter if you have implemented every other SIP related > specification out there... > > Regards, > > Christer > > > > -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: 26. elokuuta 2008 1:05 > To: Paul Kyzivat > Cc: Christer Holmberg; Dean Willis; SIP IETF; Cullen Jennings > Subject: Re: [Sip] Fixing SIP with OS reference implementations for UA and > server > > Paul, > > I really love your way of arguing, but feel it's too apologetic of the present > way of doing business as usual, since SIP has become an ecosystem in its own > right and has spawned a global VoIP industry. This implies far greater sense > of responsibility that can only be met by using the most successful examples > of software development in academia and R&D: > > The same person(s) to write both the code and papers in parallel and publish > them along with ample test results. It's much of a looped process. There are > plenty of such sites, for example in the open source community. There are bug > fixes, lists of know issues, etc. We all know them and have the responsibility > to apply such engineering _discipline_ here as well. > > * When seeing over 100 standards, how is one going to know SIP in adequate > depth? > * What is the cost of this complexity? > * When proposing an extension what are the unintended consequences? > * When seeing dissent among the leading SIP experts, where to go for guidance, > except in some test environment? > > That explains my insistence on running code and testing as part and parcel of > further SIP development, and also for fixing the problems currently discussed > here - but not mainly by discussions :-) > > The endless flow of I-Ds without running code and test results has to stop > somewhere IMO, but I don't want to belabor it since we probably disagree. > > Thanks again for your thoughtful comments. > My two cents, > > Henry > > > On 8/24/08 9:31 PM, "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > >> Henry, >> >> Its interesting that you have drawn parallels here with physics. >> In physics there are theorists and experimentalists. I think most of >> them agree that progress in physics requires both - the >> experimentalists require a theory to verify, and the theorists need >> observed violations of the theory and data that is unexplained by existing >> theories. >> >> I agree that experimentalists are useful in our business too. I in >> general agree with your implied assertion that we (the IETF >> sip-related >> WGs) are theorists. >> >> Its not entirely clear to me whether we need *more* experimentalists >> than we already have, or if they could or should be more closely >> affiliated with the IETF than they already are. We do already have SIP >> Forum, running SIPit. We hear the results of that. And clearly there >> are plenty of participants here that speak for implementations. >> >> Based on what you have said before, I gather you think there is too >> much standardization done in relation to the amount of implementation done. >> There certainly are cases when that is true. But remember that most of >> the documents we are producing are only drafts - they aren't even >> complete theories ready to be tested. Even the RFCs we produce are >> only Proposed Standards, and so are probably good candidates for testing. >> >> If one person, or a very few working closely together, are doing all >> the design and implementation of something, then you *might* be able >> to get by just implementing without first specifying what is being >> implemented. >> Some of the agile methods advocate that kind of approach. If what you >> are attempting has too many moving parts for that, then its still >> necessary to write a spec. Doing an open source implementation doesn't >> change that. It may just change which group does the specification. In >> a way this is like having the experimental physicists develop the theories. >> >> Bottom line - IMO it would be good to get more early implementation >> experience than we seem to get now. An open reference implementation >> is one way to get that. But I don't think we should make some sort of >> rule that you can't submit a draft without a reference implementation, >> or even that you can't have an RFC without a reference implementation. >> (There is already a requirement for multiple implementations before a >> *Draft* standard.) >> >> Thanks, >> Paul >> >> Henry Sinnreich wrote: >>> Christer, >>> >>> I agree with both you and Dean and should have also specified that >>> the SIP standard should be amended step by step, based on testing the >>> reference implementation. There is nothing wrong with an I-D with >>> fixes for SIP based on testing a reference implementation. >>> >>> Sorry for not having been clear also on the need to fix the standard >>> document by adding an amendment RFC. >>> >>> Henry >>> >>> >>> On 8/24/08 3:19 PM, "Christer Holmberg" >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> Hi Henry, >>>> >>>> Based on what criteria would you choose the reference >>>> implementation(s), and what is it that you really want to test? >>>> Offer/answer? >>>> >>>> Because, eventhough there seems to be problems implementing >>>> offer/answer correctly, the early media/forking problem, raised by >>>> Dean, is more of a "bi product" of the way we designed the protocol. >>>> In other words, even if you have an implementation which works 100% >>>> according to the specs, it doesn't solve the problem which may come >>>> up when you, due to forking, receive early media from multiple >>>> locations :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> -----Alkuperäinen viesti----- >>>> Lähettäjä: Henry Sinnreich [mailto:[EMAIL PROTECTED] >>>> Lähetetty: su 24.8.2008 22:01 >>>> Vastaanottaja: Dean Willis; Christer Holmberg >>>> Kopio: SIP IETF; Cullen Jennings >>>> Aihe: Fixing SIP with OS reference implementations for UA and server >>>> >>>> (changed the subject line) >>>> I have followed this discussion and am convinced that (though I >>>> started it) the issues raised here and in countless other >>>> SIPPING/SIP related discussions cannot be solved by apparent logic, >>>> no matter how long and how thorough. Just like the physics cannot be >>>> proven by discussions but only by experiment. This is the whole >>>> difference between engineering/science and beliefs/opinions. >>>> >>>> The only way IMO to fix the SIPPING/SIP issues discussed here is to >>>> have an open reference implementation running in a test bed (such as >>>> one provided maybe by the SIP Forum) and cooperate in LUNIX-style >>>> with testing (why not in SIPit events as well) and fixing the code. >>>> Any fruitful discussions must be part of fixing running code based >>>> on test results. This is actually pretty plain, so forgive my rant... >>>> >>>> Selecting a reference SIP implementation: >>>> There are quite a few SIP UA and and SIP server OS code sites >>>> available and the next step could be selecting the best candidate(s). >>>> If asked, I would be only to happy to recommend some candidates. >>>> >>>> Continuing such discussions without a reference implementation is >>>> fruitless and the SIP issues discussed here will not get fixed so as >>>> to meet the requirements for a good standard. This applies to all SIP >>>> related WGs. >>>> >>>> Any comments? >>>> >>>> Thanks, Henry >>>> >>>> >>>> On 8/24/08 2:30 PM, "Dean Willis" <[EMAIL PROTECTED]> wrote: >>>> >>>>> On Aug 24, 2008, at 7:25 AM, Christer Holmberg wrote: >>>>> >>>>>> The "media before answer" (if you refer to SDP answer) can be >>>>>> solve by simply saying that one must send an SDP answer must be >>>>>> sent before media is sent. >>>>>> >>>>>> The >>>>>> you-must-be-able-to-receive-media-once-you-have-sent-the-INVITE >>>>>> doesn't work, because today media sent before SDP answer will >>>>>> often be discarded anyway. >>>>>> >>>>> Perhaps not, but it's how ever device and service I currently have >>>>> works. >>>>> >>>>> Not that they work well, mind you. >>>>> >>>>>>> It also makes ICE and SRTP much easier to deal with. By making >>>>>>> the transition to "regular" session a re-invite the gateway can >>>>>>> transition from send-only to send-receive (if needed), the >>>>>>> billing system (if it cares) can start the meter running, etc. >>>>>> So, just to clarify, you are still talking about a single SIP >>>>>> session, right? >>>>> That's one of the two possible approaches, and probably the easiest >>>>> to explain. >>>>> >>>>> >>>>>> The issue with that solution is of course that a forking proxy, as >>>>>> currently defined, would terminate all other legs once the first >>>>>> 200 OK (establishing the early media path of the session) arrives. >>>>> One could of course change that behavior and have the forking proxy >>>>> return ALL responses. >>>>> >>>>> >>>>>> >>>>>> But, that would minimize multiple early media streams, which again >>>>>> in my opinion shows that the main problem is not offer/answer, but >>>>>> forking :) >>>>> The two certainly play poorly with each other. >>>>> >>>>>> >>>>>>> Plus we can drop all the 100-rel and preconditions cruft out of >>>>>>> the state machine completely, making life MUCH better for the coder. >>>>>> If you separate the offer/answer state machine from the SIP >>>>>> transaction state machine it shouldn't really matter in what SIP >>>>>> messages the offers and answers are carried. >>>>> Perhaps true, but the SIP 100-rel state machine is profoundly ugly >>>>> all by itself. >>>>> >>>>>> >>>>>> And, eventhough we probably would be able to remove SDP from >>>>>> provisional responses, I think provisional responses would still >>>>>> be useful for other things (indicating ringing etc). >>>>> Yes, and provisionals also impact the resend timers. We need them. >>>>> We just don't need 100-rel. >>>>> >>>>>> >>>>>> But, of course we could have instead have used something like >>>>>> UPDATE (or even INFO) to indicate "ringing" etc, instead of >>>>>> provisional responses. >>>>>> >>>>>>> Think of it this way -- If I'm calling a PSTN gateway, do I >>>>>>> really want to wait until the PSTN side connection completes >>>>>>> before I do the setup work for SRTP? I think I'd rather get that >>>>>>> out of the way before the called party answers, or before I even >>>>>>> see early media coming back unprotected. >>>>>> What prevents you from doing the SRTP negotiation using reliable >>>>>> provisional responses, in the same way you are able to perform >>>>>> preconditions before the called party answers? >>>>> In my case, mostly the desire to avoid reliable provisional responses. >>>>> >>>>> And when you cross-factor reliable provisional, SRTP, and forking, >>>>> you get a real mess. >>>>> >>>>>> >>>>>>> Now, lets think about forking. When we fork in a proxy, the UAC >>>>>>> can only deal with one "best answer", and early media is >>>>>>> anybody's guess as to how it might work or what might happen (it >>>>>>> pretty much turns to soup, especially if you get multiple early media >>>>>>> channels). >>>>>> Correct. And, that will be a problem as long as it is possible for >>>>>> the UAC to receive multiple early streams - no matter how they are >>>>>> negotiated. >>>>>> >>>>>>> Consider instead that a forking node is really a "forking >>>>>>> gateway", not a proxy. It takes one call in, establishes a >>>>>>> fully-negotiated "early session", then sends out its multiple >>>>>>> INVITES. As those sessions (which might have early media) >>>>>>> connect up, the forking gateway deals with the multiple media >>>>>>> streams (by bridging, discarding, whatever). >>>>>> Doesn't that simply move the >>>>>> how-to-choose-which-early-media-stream- >>>>>> to-listen-to from the UAC to the forking proxy/gateway? >>>>> It allows the forking gateway to either mix all the streams into >>>>> one (a boon to the bandwidth-restricted UAC), or more intelligently >>>>> choose which one to relay based on media-analysis. For example, >>>>> ringing can easily be differentiated from speech, so if a >>>>> forking-b2bua sees four legs of ringing and one of speech, it could >>>>> quite reasonably choose the speech channel to send back to the UAC. >>>>> >>>>>> >>>>>>> When a forked session matures to a "regular session", the forking >>>>>>> gateway can re-invite the UAC to >make that session a "regular >>>>>>> session", >>>>>> Today it does that again by sending 200 OK. >>>>> Right -- assuming you did your media setup in provisional (and >>>>> keying in reliable provisional, which is messy) >>>>> >>>>>> Again, I agree that many things probably could be done in a >>>>>> "cleaner" way, but I think the main problem still exists: if there >>>>>> are multiple early media streams (due to forking proxy or forking >>>>>> gateway), how do I choose which one to play? >>>>>> >>>>> I'm not aware of a perfect asnwer, but (as above) can say there are >>>>> definitely several "better" answers than what we have now. >>>>> >>>>> >>>>>>> or can even arrange to drop itself out of the media path if needed. >>>>>> How would that work? It would be able to change the local contact >>>>>> from itself to the called party, but it would not be able to add >>>>>> the possible Record-Routes between itself and the called user. >>>>> Media path, not signaling. Fall back to 3PCC setup techniques on a >>>>> reinvite sequence. >>>>> >>>>>> Not being able to modify the signaling path during a session (read: >>>>>> update the Record-Route) is a "bug" in the protocol, I think, but >>>>>> it's a separate issue :) >>>>>> >>>>> yeah, re-invite should be abele to re-route. >>>>> >>>>> >>>>>>> If we have to have forking, and we have to have media before >>>>>>> there's a final answer, then I think something like this is >>>>>>> needed to make it work. >>>>>> Again, it could make the signaling flows a little more nicer, and >>>>>> it would move some decissions from the UAC to the forking gateway, >>>>>> but the problem with multiple media streams (no matter whether you >>>>>> call them early or not :) would still exist. >>>>> Perhaps. However, one of the more profound problems today (as with >>>>> mobile nets) is limited bandwidth to the UA. Dealing with mixing, >>>>> recoding, and selection-from-alternatives in a "server" is much easier. >>>>> >>>>>> In my opinion, the only solution, using what we have today, is to >>>>>> make sure there is only one early media stream sent. >>>>> Yep. That's quite true. It's also very difficult, if anything forks. >>>>> Our greatest power is our greatest problem. >>>>> >>>>> -- >>>>> Dean >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>>>> This list is for NEW development of the core SIP Protocol Use >>>>> [EMAIL PROTECTED] for questions on current sip Use >>>>> [EMAIL PROTECTED] for new developments on the application of sip >>>> >>> >>> _______________________________________________ >>> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol Use >>> [EMAIL PROTECTED] for questions on current sip Use >>> [EMAIL PROTECTED] for new developments on the application of sip >>> > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
