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

[Hadriel Kaplan <[e-mail]>]

On Sep 23, 2011, at 1:06 AM, Christer Holmberg wrote:

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

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.

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?


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

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.

-hadriel