Re: [rtcweb] Minimal SDP negotiation mechanism

On 09/20/2011 10:08 PM, Cullen Jennings wrote:
> 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.
Yes, I discussed this at our team yesterday - it seems to me that the 
offer/answer model only gives you 2 options here:
- Send another OFFER  and hope for a more appropriate ANSWER
- Give up and signal that the connection is closed

We don't have a message that fits in the SDP offer/answer model that 
allows you to inform the correspondent that the ANSWER was erroneous; 
this may argue that the PeerConnection needs to inform the Javascript 
layer and let that layer decide what to do.
>   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.
Certainly desirable (for gateways that don't want to mess with blob 
internals). So far, it has seemed to us that the operation line + the 
SDP blob forms exactly that type of blob.
>   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.
When the message goes between JS and PeerConnection, there is such an 
identifier: The PeerConnection object itself. Do we need more?
If the ID needs to be passed outside of the JS execution context, we 
need a globally unique identifier. But I'm not sure we need one all the 
time, and if a specific application needs it, it can generate one.
>
> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>