Re: [rtcweb] Minimal SDP negotiation mechanism

Harald,

I really appreciate your addressing the need to explicitly distinguish 
offers from answers - it is important. SIP did a really bad job of that. 
In SIP one just sends the SDP and the determination of whether it is an 
offer or answer is contextual. That was a bad decision.

On 9/19/11 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?

Since, afaik, this is async messaging, I think you should have something 
used to identify an offer and then to refer back to it when sending the 
answer, to ensure that a received answer was indeed an answer to the 
offer you thought it was.

And that is part of the rtcweb-o/a protocol you are defining. It will 
also need some rules to prevent sending two offers without getting an 
answer first, or at least define what you do if that happens. (If one 
side sends an offer and fails to get an answer back, what should it do?)

	Thanks,
	Paul

> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>