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

[Christer Holmberg <[e-mail]>]

Hi, 

>> 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 
>>de. 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.

I am not sure whether the JS app would be able to make better decisions than the gateway - and I've never seen a SIP client which would allow the user to choose which early media to listen to. 

And, sometimes SBGs, eventhough they allow multiple early dialogs to pass towards the user, still only allow media associted with one of the early dialogs to pass.

In my opinion the best thing would be if we could come up with some common BCP, e.g. saying that media associated with the early dialog on which the latest SDP answer was received is considered "active", and will be presented to the user etc. 

Or something like that...

The network will then have to make sure that SDP answers are forwarded towards the user in a way that the "correct" media will be accepted and presented.

That was, once again, my input for the annual how-to-support-early-media debate :)

>>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. 

We need to keep in mind that supporting forking and supporting media from multiple locations are two different things, and I think we need to be very clear about what we mean when discussing.

Regards,

Christer