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

[Christer Holmberg <[e-mail]>]

Hi, 

>> Sure, but it would be good if network applications, that 
>> provide the early media, could make assumptions on how the end user is going to 
>> process it. It would make life easier both for the network 
>> application designer and the client application designer - AND the SBC 
>> designer, btw, if the SBC will have to make decisions on which media 
>> to forward towards the user :)
> 
> If the "network application" you're talking about is provided 
> by the same domain that runs the rtcweb server, then 
> obviously they can "control" it, since they wrote the JS script.
>
> If you're talking about when rtcweb domain A calls SIP/rtcweb 
> domain B, and domain B wants to control it, then obviously 
> they can because domain B can use an SBC, or control the 
> offer/answer and media on their side some similar way, and we 
> don't need to say anything about that.

Sure, you can control the offer/answer. My point was that it would be good if everyone had a common understanding on how the offer/answers will be controlled.

But, of course, as long as the JS app and the network application is provided by the same provider, things would work.


> But that wasn't my point... the discussion was around whether 
> the rtcweb system as a whole (browser or browser+JS) had to 
> be able to support media forking cases, or not.  And my point 
> was yes, they do, because if they talk SIP to domain B then 
> they cannot *mandate* B not media fork calls, because that's 
> like mandating B not send re-INVITEs.  It's part of basic 
> SIP, part of its base spec.  Even from a practical standpoint 
> it's not something imaginary like S/MIME; media forking 
> happens in practice all the time.

I agree that we somehow need to support forking, meaning that we on the signalling level need to be able to handle multiple early dialogs.

On the media plane, we also need to be able to switch from one remote media source to another, but the question is still whether the browser, and the PeerConnection API, needs to support *simultanous* media from multiple remote sources.


> Obviously my employer would be better off if SBCs were 
> mandated for all SIP communications, but it's not right to 
> require them in an IETF spec/architecture.  People should use 
> them if they have a need to, not just because browsers are 
> too lazy to handle real SIP scenarios. 
> 
> Imagine if Google deployed rtcweb, and Columbia University 
> deployed a SIP service for all their students, with multiple 
> contacts, forking, etc.  Columbia goes to Google and says 
> "can we peer using SIP"?  And Google says "sure, but you'll 
> have to deploy something to hide media forking, re-INVITEs, 
> etc."  Columbia says "but I thought you guys peer with SIP?" 
> and Google says "oh we do, but it's a lighter SIP granted to 
> us by the IETF, because we use browsers".  Do you see how 
> crazy that would be?

Yes, and I am not suggesting anything like that :)


>>  The browser doesn't need to keep state - it only does what 
>> the JS app tells it to do. 
>> But, the JS app needs to keep state, so that it can then 
>> provide the SDP answer associated with Bob to the browser 
>> when the 200 OK comes.
> 
> I'm with you there, but methinks we've lost that battle 
> already.  The browser's going to be the SDP offer/answer 
> engine, so now I'm at least hoping it's a real/full one and 
> not some hybrid.

I am not sure I understand what you mean by the browser being the SDP offer/answer engine.

Just because we would use offer/answer between the browser and the JS app, it doesn't mean we have to support multiple dialogs on that interface.


>As a side note, I'm not actually sure what would happen to 
>ICE processing with peers if the browser only has one media 
>state at a given time, and switches from Robert's SDP to 
>Bob's and back to Robert's.  Someone should try it with the 
>chromium prototype, in different timing scenarios.  Like what 
>happens if the browser's ICE to Robert gets to a completed 
>state, then the browser switches to Bob, and later back to 
>Robert and the browser thinks ICE starts again with Robert 
>but Robert thinks it's over.

ICE is one of the impacts that we would need to consider, because what might happen is that when you switch from one remote media source to another everything (ICE, media security etc) is lost.

...unless, of course, the gateway relays all media, and handles the switching between remote media sources.


Regards,

Christer