Re: [rtcweb] Minimal SDP negotiation mechanism

[Christer Holmberg <[e-mail]>]

Hi, 

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

That's not what I am suggesting. But, forking also have impacts on the media plane.


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

The JS SIP app can decide that, but my point was that the JS SIP app needs to be able to "replace" the SDP answer with anohter one (received on another early dialog) - *IF* it chooses to do so.


> Note that "199" response tries to "help" a bit:
> 
>   "SIP Response Code for Indication of Terminated Dialog"
>   http://tools.ietf.org/html/rfc6228

That's such a great piece of RFC :)

And, it does help the JS SIP app to make a decission, but the API still needs to allow to "replace" the SDP answer.


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

Yes, the JS app can make the decision - but, again, the API still needs to allow the JS app to enforce that decision.
 
>BTW: would be possible to render various at the same time by 
>mixing the incoming audio?.

Well, that is what my first question was more or less about.

Regards,

Christer