Henry,
I've been thinking about this a bit recently. (But not too much or too
deeply.)
In the open source world, in some sense there is only one
implementation. If that is the implementation of a distributed
application, then the protocol connecting the pieces is embedded in the
implementation, rather than being an external interface. (Though I guess
it *could* be an external interface if it was sufficiently documented,
but that would tie down the evolution of the application.)
If you would like to enable *multiple* implementations of different
components of that application, e.g. using different languages or for
different OSs, then for them to able to remain consistent with the rest
I guess they must be merged into the same open source initiative. That
is one way to do things, but not everybody wants to work that way.
In a sense, the IETF is also an open source initiative. But what is
being developed is interface specs rather than running code. The
assumption being that those interfaces are the stable part, while the
implementations are many, varied, and changing over time.
If the goal is to have everybody working on and using a single
implementation then an open source approach is probably better and
quicker. If the goal is to facilitate a multiplicity of interoperable
implementations, then the IETF process may be better.
In any case I still think there is a valid distinction between theory
and experiment. Do you want a crypto implementation that hasn't had its
algorithm designed by a crypto theorist? Do you want a communication
protocol that has been implemented for the common cases but hasn't had
all the subtle cases considered? (There is a reason we make fun of
implementors that implement to the use cases rather than the spec. Its
even worse if all you have is the use cases and the code - no spec.) It
is much easier to examine those kinds of issues with a high level spec
than a piece of executable code.
There is no doubt a place for all these techniques. The process of
writing the spec first is slow - no doubt about it. Its not appropriate
for everything - only for critical stuff that is going to be implemented
lots of times. Just doing an open source project without a separate spec
may be more practical for more narrowly focused goals. And of course you
can always have an open source project to implement a spec that is
developed alongside that project.
Thanks,
Paul
Henry Sinnreich wrote:
> 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
