Subject: [siprec] what to put in the message header to indicate metadata snapshot request

From: "Henry Lum" <[email-masked]>
Date: Fri, 15 Jul 2011 08:11:32 -0700

Hi,

In the latest protocol draft revision (05) I proposed a mechanism to
request for metadata snapshot request. This is outlined in section 5.5.
I want to get some comments on whether the proposed mechanism is
sufficient.

Thanks

Henry

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jul 2011 09:44:37 +0200

Henry,

At the last interim it was minuted:
"Slide 8: Concerning the nature of a snapshot request, Charles thought this could be just a simple request, with no parameters. The discussion seemed to lean towards something in the header, rather than in the body. To be continued on the list."
I don't recall much discussion on the list, but the proposal in 05 for a body part seems to go against the meeting's general preference for something in the header.

I also don't recall anything in either the metadata draft or in the protocol draft to help the SRS determine whether it has lost a metadata update (and therefore needs to request a snapshot). Some sort of sequence numbering is perhaps required.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henry Lum
> Sent: 15 July 2011 16:12
> To: [email-masked]
> Subject: [siprec] what to put in the message header to 
> indicate metadata snapshot request
> 
> Hi,
> 
>  
> 
> In the latest protocol draft revision (05) I proposed a 
> mechanism to request for metadata snapshot request. This is 
> outlined in section 5.5. I want to get some comments on 
> whether the proposed mechanism is sufficient.
> 
>  
> 
> Thanks
> 
> Henry
> 
>  
> 
> 
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities. 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 18 Jul 2011 15:41:53 -0700

I was initially thinking of this from the perspective of wanting to
avoid requiring metadata processing on the behalf of the SRS or SRC in
order to request a snapshot. In this case, a SIP header is appealing.

Another option, and the one implied by section 5.5 of the draft, is to
enable generic metadata error handling. If you want to do this,
requesting a snapshot could be a type of error reported by the SRS, and
sending a snapshot could be a recovery mechanism used by the SRC. More
complex error reporting and recovery would probably involve some sort of
metadata sequence number and an indication of the last sequence number
processed properly on the SRS. This would enable the SRC to send updates
based on an intermediate point in the recording.

I am thinking the former mechanism is sufficient. The latter mechanism,
though definitely much more efficient in many cases, is more complex.
The cynic/realist in me thinks that with either method, the odds are
high that once an error is encountered any recovery mechanism (e.g. a
snapshot, an intermediate update, etc.) has a high probability of
failing. The important thing is to be able to debug the failure. For
example, it may be that the update resulted in a parsing error on the RS
within some participant element. I see some value in having this in some
SIP or metadata message, but having it enable auto-recovery is not
likely.
As I do not see any error handling within the current metadata
model/format, I am thinking it is best to leave the snapshot request
outside of the context of the metadata.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
> Sent: Monday, July 18, 2011 12:45 AM
> To: Henry Lum; [email-masked]
> Subject: Re: [siprec] what to put in the message header to
indicatemetadata snapshot request
> "Slide 8: Concerning the nature of a snapshot request, Charles thought
this could be just a simple
> request, with no parameters. The discussion seemed to lean towards
something in the header, rather
> than in the body. To be continued on the list."
> I don't recall much discussion on the list, but the proposal in 05 for
a body part seems to go against
> the meeting's general preference for something in the header.
> 
> I also don't recall anything in either the metadata draft or in the
protocol draft to help the SRS
> determine whether it has lost a metadata update (and therefore needs
to request a snapshot). Some sort
> of sequence numbering is perhaps required.
> 
> John
> 
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jul 2011 11:10:33 -0400

> order to request a snapshot. In this case, a SIP header is appealing.

I agree that it would be good to simplify the processing the SRC must do 
to recognize the request.

This could be done using a sip header, but also by using a body with a 
different content type from that of the metadata. That body might not be 
xml - it might simply be text with a very simple syntax.

> based on an intermediate point in the recording.

IMO many of the primary use cases for recording are likely to be 
paranoid about recording as much as possible even in the face of errors. 
This probably translates into capturing the incoming media from the 
negotiated RS media streams even if the metadata is missing or 
malformed. And maybe capturing the metadata even if it is malformed.

Another priority is probably to simply SRCs, since they are likely to be 
grafted onto lots of things. I don't think it is a good idea to expect 
the SRC to maintain a lot of data to facilitate error recovery.

As a result, I don't see complex error recovery mechanisms as helpful. 
Simple ones are probably all that we should expect an SRC to be able to 
handle, and are all that would be very useful.

I've also been pondering what "full" means for metadata in contrast to 
"partial". I am coming to the conclusion that to the SRS there is really 
no difference - "full" metadata is processed exactly the same way as 
"partial" is. It is just likely to contain data that would be redundant 
if all had gone well before. From the perspective of the SRC, a request 
for a snapshot simply means "send everything you currently know about 
all the media streams you currently are sending to the SRS, and then 
continue sending updates after that."

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 20 Jul 2011 13:59:59 -0700

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Wednesday, July 20, 2011 11:11 AM
To: [email-masked]
Subject: Re: [siprec] what to put in the message header to
indicatemetadata snapshot request

[hlum] I agree there should be little processing SRC needs to do to
recognize the request and that is my intent in the draft. It is
basically a text body and not inheriting any XML from the metadata; to
me it's little difference compared to a SIP header with text. The text
is basically a status string and the SRC does not even need to care
about the content if it does not want to. To clarify, the processing of
the content is entirely optional for the SRC; as long as the SRC
recognizes that the format type then the SRC knows that the SRS is
asking for a snapshot request. 

[hlum] I agree we don't need to get into complex mechanism such as
keeping track of sequence numbers and synchronizing states. My thinking
this is the former mechanism and not trying to come up with a recovery
mechanism. The snapshot request basically just ask the SRC to send
everything SRC knows right now (I guess we are calling it "full"
metadata?) and resume operation. In the case where the SRS can't really
figure out what is going on then the SRS can simply terminate the
recording session. Anyways I think we are in agreement but it looks like
the wording in section 5.5 is a bit terse to give the impression that it
is proposing a synchronization/recovery mechanism.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Jul 2011 10:50:00 +0200

> Sent: 20 July 2011 22:00
> To: Paul Kyzivat; [email-masked]
> [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> > complex error reporting and recovery would probably involve 
> some sort
> of
> if all had gone well before. 
[JRE] Not exactly. If partial metadata omits an element (a Participant element, say), the SRS must assume that element is unchanged, whereas if complete metadata omits an element, the SRS must assume that element has been deleted.

> From the perspective of the SRC, 
> a request 
[JRE] I think sequence numbers are required only so that the SRS can detect that something has been lost, so that it can then request the complete metadata.

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> > example, it may be that the update resulted in a parsing 
> error on the
> RS
> --------------------------------------------------------------
> -----------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jul 2011 09:24:25 -0400

> [JRE] Not exactly. If partial metadata omits an element (a Participant element, say), the SRS must assume that element is unchanged, whereas if complete metadata omits an element, the SRS must assu…

Yes, that does seem right.
But it only means that henceforth. It doesn't change what happened in 
the past.

	Thanks,
	Paul