Hi, >>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.
At least in environments with gating, SBCs and/or bandwidth/radio resource reservation procedures I don't think those devices would work very well, because the media sent before the SDP answer would most likely be terminated somewhere. >Not that they work well, mind you. So, the first step would then be: make sure you don't send media until you have sent an SDP answer :) >>>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. Probably the easiest to implement also. Because, if you would use separate SIP sessions, you would need to somehow "transfer" the ICE/SRTP/resource reservation state between them. ...unless you want to perform separate ICE/SRTP/resource reservation on the early- and the full dialog sessions, which would be really bad. >>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. They do currently forward all 200 OK responses, but there will of course only be multiple 200 OK responses if they were sent before the CANCEL sent by the forking proxy arrived. >>>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. If you want to get rid of 100-rel there is also another way: get rid of UDP ;) >>> 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. What if it sees four legs of speech and one of ringing? I agree that you could make the life of the UAC easier, and better control that the media sent towards the UAC "fits" within the negotiated UAC-proxy bandwidth etc, using this kind of forking-b2bua. But, it would require a big box, media mixing and possibly transcoding, in the network, and someone told me that IETF is about UA-to-UA-with-nothing-but-stupid-cable in between :) >>>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. Yes, but saying that is not politically correct, is it? :) >>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. Eventhough it doesn't solve the problem, I think many things would work much better if people implemented and used RFC 3841 (and RFC 3840). It e.g. allows you to indicate that you don't wish parallel forking to occur. Regards, Christer _______________________________________________ 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
