session rehydration clarification?

256 views
Skip to first unread message

Brendan Miller

unread,
May 17, 2013, 9:17:37 PM5/17/13
to discuss...@googlegroups.com
In JSEP (http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03) section 3.6 talks about session rehydration:
"
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
   session.
"
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
   been lost).
"
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).

Thanks,
Brendan Miller

Justin Uberti

unread,
May 23, 2013, 10:31:06 PM5/23/13
to discuss-webrtc
On Fri, May 17, 2013 at 6:17 PM, Brendan Miller <catp...@catphive.net> wrote:
In JSEP (http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-03) section 3.6 talks about session rehydration:
"
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
   session.
"
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
   been lost).
"
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:

Yes, this is what I was referring to. 

1. It sounds like ID's are just UUID's generated to uniquely identify a media stream?

They are opaque IDs, not necessarily UUIDs.
 
2. If the mediastream ID attribute is readonly, how do I create a media stream with the correct ID during rehydration?

Unfortunately, this isn't yet supported. But for a browser-browser case, it's not that critical - the remote side, when it sees the new offer, can detach from the previous streams and hook up to the new ones.
 
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).


 
Thanks,
Brendan Miller

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Reply all
Reply to author
Forward
0 new messages