Re: [rtcweb] Minimal SDP negotiation mechanism

[Iñaki Baz Castillo <[e-mail]>]

2011/9/20 Christer Holmberg <[e-mail]>:
> Whether we want the browser to support forking is one thing, and I guess it much depends on whether we want to be able to do things on the media plane during the early phase of a session establishment.

I hope. If not, let's forget about integrating WebRTC in any telephony
environment.

The point here is that *media sessions* are "independant" of
signaling. If we make WebRTC just to deal with media plane, the
signaling (coded in JavaScript by a custom or native library) could
handle early media sessions with no problem.

But if we impose a signaling protocol (built-in within the browser
WebRTC stack) then we'll be limited to adopted design constrains,
which is not good.



> But, at least the API needs to allow a JS SIP app to "replace" a previously received SDP with a new one (if the SIP app, in the forking case, for example chooses to always use the latest received SDP answer).

There is no a magic solution for that case: which media to render when
parallel forking occurs and more than one branch replies a 180/183
with SDP?
Note that "199" response tries to "help" a bit:

  "SIP Response Code for Indication of Terminated Dialog"
  http://tools.ietf.org/html/rfc6228

If we let it at the JS application level, the developer could handle
those cases and decide which media session to render.

BTW: would be possible to render various at the same time by mixing
the incoming audio?.


Regards.


-- 
Iñaki Baz Castillo
<[e-mail]>