With rehydration, the current signaling state is persisted somewhere
outside of the page, perhaps on the application server, or in browser
local storage. The page is then reloaded, the saved signaling state
is retrieved, and a new PeerConnection object is created for the
What exactly constitutes the "signaling state" here. Originally I was thinking they were talking about the offer/answer pair, but then it says:
a new offer is
generated by the new PeerConnection; this offer will have new ICE and
possibly new SDES credentials (since the old ICE and SRTP state has
So, aside from the offer/answer SDP pairs, what signaling data is there? There's some hint in this paragraph:
The previously obtained MediaStreams are re-acquired, and
are given the same IDs as the original session; this ensures the IDs
in use by the remote side continue to work.
I wasn't sure what "ID" they were referring to at first, but it seems to be on the one in this document: (http://dev.w3.org/2011/webrtc/editor/webrtc.html#mediastream
). It would be good for there to be an explicit cross reference here. Anyway, my questions are:
1. It sounds like ID's are just UUID's generated to uniquely identify a media stream?
2. If the mediastream ID attribute is readonly, how do I create a media stream with the correct ID during rehydration?
3. Is there other information I need to serialize in order to rehydrate a stream? MediaStreamTracks also seem to have ID's, do I need to serialize these as well, or does the MediaStream ID cover those somehow?
4. Finally, I'd like to know if session rehydration is possible with existing webrtc implementation (chrome, firefox).