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
