[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Early media as an endpoint application
> What if it sees four legs of speech and one of ringing?
You have a talking donkey touring a poor sound engineer?
Keith
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Christer Holmberg
> Sent: Sunday, August 24, 2008 9:52 PM
> To: Dean Willis
> Cc: SIP IETF
> Subject: Re: [Sip] Early media as an endpoint application
>
>
> 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
> sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip