Subject: [siprec] Metadata Re-Sync

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 7 Mar 2011 17:40:33 +0100

Hi All,

I have a couple of questions/observations regarding the issue of a re-sync of metadata between the SRC and SRS.

The current draft (draft-portman-siprec-protocol-03) section 6.3.1. talks about the SRS requesting a metadata snapshot and by snapshot I assume we mean what is in the metadata model at the moment in time that the snapshot is created.  I am therefore assuming there is no requirement for the SRC to hold on to any historical information about for example past participants in a CS. Therefore when we talk about a the SRS requesting a re-sync what it is actually asking for is a current snapshot. Do people agree on that ?

Also give that a RS (Recording Session) can relate to many CS's then to make the re-sync manageable it might be a good idea if the SRS could request a snapshot for a given CS.

It would therefore probably make sense to separate the metadata for different CS's even when it is carried in the same RS. So would it be sensible to split the metadata for each CS in to different bodies in whatever SIP Request we agree will carry the metadata.

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Mar 2011 13:05:49 -0500

Andrew,

Its pretty important to get this right, and there are subtleties to it.

IMO we must make the assumption that the SRC retains a minimum of 
historical information. It is shipping data to the SRS so that it *can* 
forget about it. So when there is a need for the SRC to do a "snapshot", 
what that really means is to send what it still knows, possibly 
including "some" stuff that it remembers. There is a likelihood that 
stuff will get lost in this process.

For the mechanisms we are currently discussing, the SRC is assigning IDs 
to things in order that it can refer back to them later. For instance, 
IDs for CSs, CS-groups, media-sessions, participants, etc. We are 
currently expecting these to be dynamically assigned UUIDs.

Hence, if the SRC establishes a CS and a CS-group, each will have an 
associated ID, and the message that says the CS is a member of the 
CS-group will contain both IDs.

Clearly if the SRC wants to retain the option of adding additional CSs 
to a CS-group it will need to remember the ID of the CS-group. It can 
forget this when there is no longer any need to reference it.

If asked to send a snapshot, the SRC will hopefully remember the IDs for 
the CSs that are still active. And it will probably remember the IDs of 
the CS-groups those CSs were assigned to. (I'm not certain if that is 
necessary.)

But it might not retain much metadata info about those things that was 
sent in the past. It might just remember "I have CS-group IDs for these 
CSs". When sending a "snapshot" it might just be sending metadata 
describing current state of active sessions with reference to IDs 
created in the past. If the SRS did not get or properly process the 
metadata that first defined those IDs it might not be able to properly 
process the new snapshot.

An alternative is that when asked for a "snapshot" the SRC might 
intentially forget all the old IDs it had. Instead it could start "from 
scratch" assigning new IDs to everything it currently knows about, and 
sending metadata definitions of those, even if those definitions lack a 
lot of desirable information. The advantage is that there is no reliance 
on anything sent previously, and so corruption issues are minimized.

Obviously this is a bit difficult to discuss in the abstract, since it 
is tied pretty tightly to specific implementation approaches.

Nothing is cast in stone here. So we can discuss pro/cons of different 
approaches.

	Thanks,
	Paul

On 3/7/2011 11:40 AM, Hutton, Andrew wrote:
> Hi All,
> I have a couple of questions/observations regarding the issue of a
> re-sync of metadata between the SRC and SRS.
> The current draft (draft-portman-siprec-protocol-03) section 6.3.1.
> talks about the SRS requesting a metadata snapshot and by snapshot I
> assume we mean what is in the metadata model at the moment in time that
> the snapshot is created. I am therefore assuming there is no requirement
> for the SRC to hold on to any historical information about for example
> past participants in a CS. Therefore when we talk about a the SRS
> requesting a re-sync what it is actually asking for is a current
> snapshot. Do people agree on that ?
> Also give that a RS (Recording Session) can relate to many CS's then to
> make the re-sync manageable it might be a good idea if the SRS could
> request a snapshot for a given CS.
> It would therefore probably make sense to separate the metadata for
> different CS's even when it is carried in the same RS. So would it be
> sensible to split the metadata for each CS in to different bodies in
> whatever SIP Request we agree will carry the metadata.
> Regards
> Andy
>
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 11 Mar 2011 15:08:51 +0100

Hi Paul,

Thanks for sharing your thoughts on this.

I think we are thinking along the same lines I think a snapshot relates to the state at the moment in time it is asked for and would not want the SRC to have to remember any metadata from the past that is not relevant to the current state of the CS or CS's.

So it if fine for the SRC to have to remember the ID's for things like the CS Groups as long as these relate to currently active CS groups and not some historical information. 

I don't think the SRC should have to reset the ID's just because of a SRS asks for a snapshot this might be problematic if for example the SRC was sending the metadata to multiple SRS.

Regards
Andy

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 07 March 2011 18:06
> To: [email-masked]
> Subject: Re: [siprec] Metadata Re-Sync
> 
> Andrew,
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Mar 2011 09:22:05 -0500

Andy - I agree that it sounds like we are mostly in agreement. The devil 
is in the details. But its better to have some agreement on direction 
before investing further effort in the details.

	Thanks,
	Paul