Re: [rtcweb] Minimal SDP negotiation mechanism

["Olle E. Johansson" <[e-mail]>]

20 sep 2011 kl. 15:15 skrev Christer Holmberg:

> 
> Hi, 
> 
>>> Once we start requiring that the PeerConnection know the 
>>> difference between "early" media and "late" media, it seems 
>>> to me we're slipping down a slippery slope.
>> 
>> The difference between early and late media is purely a 
>> billing decision in PSTN. I don't think we should separate 
>> these on the rtcweb side. It's a PSTN gateway issue, not 
>> something to be bothered with in rtcweb.
> 
> It's not about knowing the difference between "early" and "late" media - it's about whether the API and browser need to support multiple SIMULTANOUS SDP answers - or whether we assume that the JS SIP app will always, at any given time, only provide ONE SDP answer to the API and browser.

I just wanted to get rid of the early/late media discussion. As you state, the forking issue with getting multiple responses is a separate issue.

Do we have any use cases using forking? Is forking a desired feature or something that SIP brought in?

To give an example to those of you with no SIP history:

In SIP you can send one OFFER and get multiple ANSWERs in 200 OK from different devices. This means that you actually have multiple calls and need to hang up all of those that you do not want, or just mix them somehow and live with it. 

With early media, it gets even more confusing, because you will get an SDP answer before the call is in up state (in 180/183 response) then another SDP answer from another device at 200 OK. In this case you have an early dialog with early media with the device sending the first answer, a dialog that terminates at 200 OK. 

Supporting this behaviour adds complexity. And not all SIP devices support these situations properly, as we've proven at SIPit testing. 

Which leads to an unshameful plug: SIPit in Monaco is now open for registration - for all SIP developers to attend :-)

/O