Subject: [rtcweb] media rollback and glare

From: Andrea Dixon <[email-masked]>
Date: Thu, 8 Aug 2013 11:16:30 +0100

The Webrtc spec states:

“This API changes the local media state. In order to successfully handle
scenarios where the application wants to offer to change from one media
format to a different, incompatible format, the
RTCPeerConnection<http://www.w3.org/TR/webrtc/#idl-def-RTCPeerConnection>must
be able to simultaneously support use of both the old and new local
descriptions (e.g. support codecs that exist in both descriptions) until a
final answer is received, at which point the
RTCPeerConnection<http://www.w3.org/TR/webrtc/#idl-def-RTCPeerConnection>can
fully adopt the new local description, or roll back to the old
description if the remote side denied the change.

Issue 8

ISSUE: how to indicate to roll back?”

When will rollback be added to webrtc? Is it imminent? We need it to
resolve glare scenarios where both peers renegotiate at the same time. Or
is there another way of resolving glare in webrtc? This is becoming a
pressing concern.

Regards

--------------------
Note: The information contained in this message may be privileged and confidential 
and protected from disclosure. If the reader of this message is not the intended 
recipient, or an employee or agent responsible for delivering this message to the 
intended recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message and 
deleting it from your computer. Thank you. Thrupoint, Inc.
nXaR2cC3

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 8 Aug 2013 14:51:00 +0000

Hi,

+1

In the Open Mobile Alliance, a REST API is being defined, intended to be exposed by a gateway that offers WebRTC access to IMS (or even PSTN). 
For that work, it is also necessary to understand how rollback will work in the PeerConnection API.
 
Kind regards,
Uwe Rauschenbach

--
Dr. Uwe Rauschenbach
Senior Specialist 
NSN, Technology & Innovation
St.-Martin-Str. 76, D-81541 Munich, Germany 
Tel.: +49 89 5159 29751
Mobile: +49 173 3083573 

Nokia Siemens Networks Management International GmbH 
Geschäftsleitung / Board of Directors: Andreas Sauer, Ralf Dietzel 
Sitz der Gesellschaft: München / Registered office: Munich 
Registergericht: München / Commercial registry: Munich, HRB 198081

--------------------------------------------
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Andrea Dixon
Sent: Thursday, August 08, 2013 12:17 PM
To: [email-masked]
Subject: [rtcweb] media rollback and glare

The Webrtc spec states:
"This API changes the local media state. In order to successfully handle scenarios where the application wants to offer to change from one media format to a different, incompatible format, the RTCPeerConnection must be able to simultaneously support use of both the old and new local descriptions (e.g. support codecs that exist in both descriptions) until a final answer is received, at which point the RTCPeerConnection can fully adopt the new local description, or roll back to the old description if the remote side denied the change.
Issue 8
ISSUE: how to indicate to roll back?"
When will rollback be added to webrtc? Is it imminent? We need it to resolve glare scenarios where both peers renegotiate at the same time. Or is there another way of resolving glare in webrtc? This is becoming a pressing concern.
Regards

--------------------

---

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Aug 2013 13:34:39 -0700

The thinking has been to pass in a SessionDescription of type "rollback" to
the API. See 4.2.3.2 in http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03
.

On Thu, Aug 8, 2013 at 7:51 AM, Rauschenbach, Uwe (NSN - DE/Munich) <
[email-masked]> wrote:

> Hi,
>
> +1
>
> In the Open Mobile Alliance, a REST API is being defined, intended to be
> exposed by a gateway that offers WebRTC access to IMS (or even PSTN).
> "This API changes the local media state. In order to successfully handle
> format to a different, incompatible format, the RTCPeerConnection must be
> able to simultaneously support use of both the old and new local
> final answer is received, at which point the RTCPeerConnection can fully
> adopt the new local description, or roll back to the old description if the
> remote side denied the change.
> Issue 8
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>