Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

[Hadriel Kaplan <[e-mail]>]

On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:

> That said, I think that doing both forking and early media is hard. Lets assume we are using a signaling gateway that is not a media gateway to translate between a SIP call on one side and whatever is happening over on the browser side. The basic issue is the browser initiating the communications needs to be able to start receiving multiple RTP streams before it even has signaling information to tell it how many it might receive.

Not really - there will be signaling, because there has to be SDP answers even just to get ICE to work before the media starts flowing in many NAT cases.  And even in practice in SIP there're usually SDP answers in 18x to open "gates", and to get upstream DTMF.  So if the concern is just that there's no signaling to tell the browser there are multiple RTP streams coming, I think that can be allayed.  

The really hard part is knowing which stream to use/render/send-to, imho.  And putting that decision in the gateway isn't good - the best decider of that is probably the JS in the browser.


> To simplify this problem, Cary and my draft proposes not allowing forking on the SIP side of the signaling gateway but still allowing early media. If you wanted to do do forking in this case, one would need a SBC that processed media and turned the forked medial legs into one media leg. 

Obviously you can request that a request not be forked, using caller-prefs, but you can't "not allow" forking on the SIP side.  That would make it not SIP.  I know forking is hard, but that's life.  It's not appropriate for this WG to make fundamental changes/limitations to the SIP protocol, just because some of it's "hard" for a browser. 

-hadriel