Re: [rtcweb] Minimal SDP negotiation mechanism

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.

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