session rehydration clarification?

[Brendan Miller]

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]

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.