Re: [rtcweb] Minimal SDP negotiation mechanism

Hi, 

>In SIP it's possible to get two or more different answers 
>back for one offer, due to forking.  I'm not sure you 
>want/need to handle that case, but it can and does 
>in-practice happen in SIP.

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.

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

Regards,

Christer

> 
> Also, in SIP it's technically possible to generate SDP which 
> is neither an offer nor an answer, but is rather 
> "capabilities".  This is described in RFC 3264 section 9, and 
> used in responses to SIP OPTIONS requests by some devices.  
> As Cullen noted in some earlier email in the mailing list, 
> this could probably be hacked around with a fake SDP answer 
> or error, but ya may want to keep things clean and just 
> handle this case explicitly instead.
> 
> -hadriel
> 
> 
> On Sep 19, 2011, at 12:59 PM, Harald Alvestrand wrote:
> 
> > I am looking at the WEBRTC API spec, which specifies a 
> rudimentary negotiation framework: SDP objects prefixed by 
> the string "SDP".
> > 
> > It seems clear to me that this needs at least information 
> about whether something is an offer or an answer, and some 
> way to complete the transaction when an offer is sent and 
> something prevents it from completing.
> > Until we know we need more, what about the following, to be 
> specified in the WEBRTC API?
> > 
> > SDP objects are sent through the API, prefixed with either of
> > 
> > SDP OFFER
> > SDP ANSWER
> > 
> > Alternatively, one can pass
> > 
> > SDP ERROR
> > 
> > to reply to an SDP OFFER when something goes wrong.
> > 
> > If one gets an OFFER and sends out an ANSWER, state changes.
> > If OFFER gets an ANSWER back, state changes.
> > In all other cases, state is as before.
> > 
> > We need to handle glare - when one sends an OFFER and gets 
> back an OFFER, reply with SDP ERROR, enter a "glare" state, 
> wait a bit, and send out an offer again.
> > 
> > Do we really have to have anything else?
> > 
> > 
> > 
> > 
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 