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
