Subject: [siprec] Handling of element deletions

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 15:19:36 +0200

One thing that is not clear to me in the metadata draft is how to use partial updates to show deletion of an element, e.g., when a participant leaves a conference. Can somebody explain?

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Jul 2011 21:06:12 +0530

Hi John,

Currently "stop-time" attribute in the XML schema is used to indicate
the end/deletion of an element.
For example, in a conference if a participant leaves/drops, a metadata
with "stop-time" for that "participant" element will be sent from SRC to
SRS.

e.g.

<?xml version="1.0" encoding="UTF-8"?>
  <recording xmlns='urn:ietf:params:xml:ns:recording'>
    <participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
           <aor>sip:[email-masked]</aor>
           <stop-time>2011-07-14T23:41:07Z</stop-time>
        </participant>
  </recording>   

That is one of the reasons why we have start-time /stop-time for each of
the XML elements in the schema.

Regards,
Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Thursday, July 14, 2011 6:50 PM
> To: [email-masked]
> Subject: [siprec] Handling of element deletions
> 
> One thing that is not clear to me in the metadata draft is how to use
> partial updates to show deletion of an element, e.g., when a
> participant leaves a conference. Can somebody explain?
> 
> John
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 17:45:48 +0200

Ram,

So you are saying that that if the SRS receives an XML document showing an element with a stop time, it can implicitly consider that element deleted? The deletion would never be explicitly shown until the next time a complete snapshot is sent?

If this is a common understanding of the WG, I would suggest it merits some explanation in the draft.

John

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 14 July 2011 16:36
> To: Elwell, John; [email-masked]
> Subject: RE: [siprec] Handling of element deletions
> 
> Hi John,
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Jul 2011 21:32:34 +0530

John,
SRS can consider stop-time and mark an element has ended. It need not
wait for the next snapshot from SRC to find out that an element is
deleted.

Examples of how start-time / end-time may be calculated

- For RS element start-time /stop-time will be implicitly inferred by
SRS from the time at which SIP dialog is setup /disconnected
- For a group element (CS-Group)  start-time is when CS-Group is
started, stop-time is when CS-group ends
- For a session element (CS ) start-time is when the CS is setup,
stop-time is when CS ends
- For a participant start-time is the time at which he joins the
conference, stop-time is when he leaves conference.
- If we have an MS element ( having a unique id), the start/stop time of
the MS can be derived from the time of arrival of first participant,
time of departure of last participant. Assume here that the MS is mixed
stream.

Regards,
Ram
> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, July 14, 2011 9:16 PM
> To: Ram Mohan R (rmohanr); [email-masked]
> So you are saying that that if the SRS receives an XML document
showing
> an element with a stop time, it can implicitly consider that element
> deleted? The deletion would never be explicitly shown until the next
> time a complete snapshot is sent?
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 18:40:08 +0200

> Sent: 14 July 2011 17:03
[JRE] Yes, that is what I understood from your previous message.

> conference, stop-time is when he leaves conference.
[JRE] Yes, so you are saying here that the SRC could send a complete snapshot of metadata with a CSG, CS or participant removed, and implicitly the stop time for that entity would be the time of receipt of the snapshot. Alternatively it can indicate it implicitly by sending an update of the element with a stop time included.

> time of departure of last participant. Assume here that the 
[JRE] This concerns me. It seems to say that if both/all participants temporarily stop their involvement in a media stream (e.g., because of hold), that MS implicitly ceases and a new MS has to be created it they rejoin the stream? I had not appreciated that - is it what people really want?

John (as individual)

> > If this is a common understanding of the WG, I would 
> suggest it merits
> > some explanation in the draft.
> > 
> > John
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Jul 2011 22:23:37 +0530

Hi John,

Please see inline

> Sent: Thursday, July 14, 2011 10:10 PM
> [JRE] Yes, so you are saying here that the SRC could send a complete
> snapshot of metadata with a CSG, CS or participant removed, and
> implicitly the stop time for that entity would be the time of receipt
> of the snapshot. Alternatively it can indicate it implicitly by
sending
> an update of the element with a stop time included.

Correct.

> [JRE] This concerns me. It seems to say that if both/all participants
> temporarily stop their involvement in a media stream (e.g., because of
> hold), that MS implicitly ceases and a new MS has to be created it
they
> rejoin the stream? I had not appreciated that - is it what people
> really want?

I had given this example assuming MS is same across different CSs. I
just re-collected that we agreed in the last interim meeting to have MS
scope within a CS and have unique ID to take care of future cases. In
case of hold/resume, if its within a CS the same MS will be continued.
So in case of new CS, the old MS element has to be stopped by sending
stop-time. A new MS will be created for the new CS.

Thanks,
Ram

---

From: Michael Baj <[email-masked]>
Date: Thu, 14 Jul 2011 21:06:26 +0000

Hi,

>From portman-siprec-protocol section 5.4, it states that:

"For all basic metadata information such as communication session, participants, call identifiers and direction, they can be included in the initial INVITE request sent by the SRC.  Metadata can be included as content in the INVITE or UPDATE request."

Have you considered sending the final metadata update in the BYE terminating the recording dialog, or is the SRS to presume that all metadata items stop when the recording session stops?  Otherwise an UPDATE with stop times for all metadata items would be required to be sent prior to the BYE.

Thanks,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Thursday, July 14, 2011 12:54 PM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Handling of element deletions

Hi John,

Please see inline

sending

Correct.

they

Thanks,
Ram

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 15 Jul 2011 10:24:39 +0530

Hello Michael,

Please see inline

> From: Michael Baj [mailto:[email-masked]]
> Sent: Friday, July 15, 2011 2:36 AM
> To: Ram Mohan R (rmohanr); Elwell, John; [email-masked]
> "For all basic metadata information such as communication session,
> participants, call identifiers and direction, they can be included in
> the initial INVITE request sent by the SRC.  Metadata can be included
> as content in the INVITE or UPDATE request."
> 
> Have you considered sending the final metadata update in the BYE
> terminating the recording dialog, or is the SRS to presume that all
> metadata items stop when the recording session stops?  Otherwise an
> UPDATE with stop times for all metadata items would be required to be
> sent prior to the BYE.

Yes BYE also will carry Metadata. We need to update the protocol draft
to reflect this .

Thanks,
Ram

> Behalf Of Ram Mohan R (rmohanr)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jul 2011 09:53:30 -0400

> [JRE] This concerns me. It seems to say that if both/all participants temporarily stop their involvement in a media stream (e.g., because of hold), that MS implicitly ceases and a new MS has to be…

Why is this concerning?
What would it mean to have an MS with no participants?

Note that hold doesn't necessarily mean participants leave the media 
stream. (Typically the receiver is still there as a participant, and 
there is *some* sender.) But if they all do leave it, what else makes sense?

Also note that there could still be an actual RS media stream in place, 
but not associated with any MS metadata.

	Thanks,
	Paul

---

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 15 July 2011 14:53
> To: [email-masked]
> > [JRE] This concerns me. It seems to say that if both/all 
> participants temporarily stop their involvement in a media 
> stream (e.g., because of hold), that MS implicitly ceases and 
> a new MS has to be created it they rejoin the stream? I had 
> not appreciated that - is it what people really want?
> 
> Why is this concerning?
[JRE] It was not so much a concern, more a surprise. I can see it doesn't do any harm, although in the meantime Ram has acknowledged tht the same MS object might be retained.

John