Re: [rtcweb] Minimal SDP negotiation mechanism

[Cullen Jennings <[e-mail]>]

I think this sounds about right to me - I have been thinking about a draft along the lines of this and showing how it maps to SIP. Keep in mind there are also cases where one sides sends an OFFER, gets an ANSWER, but that ANSWER has an error. I think another key component is that a signaling GW needs to pass along an opaque blob that gets passed back to it so you can signaling GW that are only transaction state full and don't have to retain state for the duration of the communications. You also need some identifier information so that a JS application participating in multiple sessions can know what session a given piece of SDP goes with. 


On Sep 19, 2011, at 10:59 AM, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb