Subject: [siprec] start/stop times & the metamodel

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Apr 2011 17:27:57 -0400

In Prague, one of the open issues was around start/stop times. The 
format draft floated the possibility of having explicit start/stop times 
signaled for each of the metatdata elements. But then we asked for 
feedback on which make sense.

IMO explicit start/stop times make more sense for some things than others.

One place where we potentially have explicit times to report with the 
dialogs that constitute a CS. Each such dialog presumably has a start 
and stop time observable by the SRC, which might differ, at least a bit, 
from the corresponding signaling on the RS.

We might want to report those times. Or, since we abstract the CS away 
from the dialog, we might want to report the start time of the first 
dialog in the CS as the CS start time, and the stop time of the last 
dialog in the CS as the CS stop time.

Similarly, we have abstracted media streams away from the media streams 
in the sip dialogs that make up the CS. We might want to report the 
start time of a media stream as the time (according to the CS) of the 
first participant to a new media stream, and the stop time as the time 
that the last participant leaves the media stream.

There are several things that complicate this:

- Do we consider the case of a stream that starts with recvonly
   or inactive participants, and only later gets a sender? If so,
   is the start time of the stream when the first participant arrived,
   or when the first sender arrived?

- How do we get the clock times for the media streams?
   IIUC the correct ones are in the RTP/RTCP, but the reporting of
   these events is driven by the signaling, and we don't have good
   sync between those. (E.g. media could start flowing before the
   corresponding signaling, and we would like to include that if we
   can figure it out.) So, even if the clocks used for media and
   signaling are in sync, we might see media packets arrive with
   a timestamp prior to the timestamp for the signaling that
   indicates the send state of the participant. This could cause
   trouble in playback.

- There isn't any guarantee that the clock used for signaling
   messages is synchronized with the clock used in RTP/RTCP.

- There isn't any guarantee that there will be any RTCP at all,
   to provide correlation of the RTP to clocktime.

The best I can see to deal with all of this is:

- All the metadata messages should be timestamped by the SRC
   using its local clock. This is easily achieved by the Date
   header in the sip message.

- Changes to a CS, including changes of participants, should
   be explicitly tagged with the time they occurred in the
   CS signaling, according to the SRC's clock. (If that is
   unavailable for some reason, then use the time the SRC
   became aware of it.)

- We could provide a metadata update element to indicate end
   of a CS, but I suggest this just be shorthand for indicating
   removal of all participants from it. (While its possible to
   mark that the CS is truly ended, that simply introduces an
   error case if added metadata about it is subsequently sent.)
   The actual start/stop time would be determined by the SRS
   based on the timestamps of first and last data about it.

- Changes to media streams should similarly be tagged with
   the time they occurred in the CS signaling. Each participant
   relationship change (send, receive, inactive,) will be there.
   The actual start/stop time of the media stream again would be
   derived by the SRS.

- CS-Groups can simply be tagged by the timestamps of the
   updates that put CSs into them. Explicit start/stop times don't
   seem useful. If desired, the SRS can derive start/stop times
   from the start/stop times of the contained stuff.

- I now think that CS-Groups should not be "contained" within
   a recording. This just seems to introduce unnecessary error
   conditions, and limitations on future enhancements. The
   lifetime of CS-Groups will probably be naturally limited by
   the ability of the SRC to remember the IDs of old ones.
   For instance, if a CS-G is created during one Recording,
   and then another CS is added to it from a different recording
   session, would we prefer to fail that, or just allow it?
   (I think allow.)

- Rather, I think every update transmitted during a recording
   session can be tagged with a link to the metadata of the
   recording session it came from. This need not be explicit - the
   SRS can do it automatically. The recording session entity
   itself will also have a start/stop time which is the start/
   stop of the RS dialog as observed by the SRS.

(Note the above doesn't solve the problem of getting correct clock times 
for RTP media. If anyone has a suggestion for this I'm all ears.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Apr 2011 17:53:38 +0200

Paul,

I think much of what you say makes sense. I was concerned that we probably need to record when a participant stops or starts sending or receiving a stream, which seems to be covered by your statement: "Changes to media streams should similarly be tagged with the time they occurred in the CS signaling. Each participant relationship change (send, receive, inactive,) will be there." That doesn't seem to be in the model at present.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 06 April 2011 22:28
> To: [email-masked]
> Subject: [siprec] start/stop times & the metamodel
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Apr 2011 09:03:19 -0400

> I think much of what you say makes sense. I was concerned that we probably need to record when a participant stops or starts sending or receiving a stream, which seems to be covered by your stateme…

John,

I agree the current model doesn't reflect this - it was a private 
thought by me, provoked by the work and discussion to date. It is a bit 
of a change of direction, so I'm interested in what others think about it.

	Thanks,
	Paul

>> Subject: [siprec] start/stop times&  the metamodel
>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 11 Apr 2011 16:36:42 +0300

Paul Hi

I agree with proposed method of time stamping metadata elements with SRC clock (it is like a wall clock from the requirement document).
About RTP time synchronization to metadata events, we either should have some low latency event from SRC to SRS with SRC time that will allow SRS to maintain time difference between its clock and SRC clock and then apply it also to receive time of RTP packet (assuming no buffering)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, April 11, 2011 4:03 PM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] start/stop times & the metamodel

John,

I agree the current model doesn't reflect this - it was a private thought by me, provoked by the work and discussion to date. It is a bit of a change of direction, so I'm interested in what others think about it.

	Thanks,
	Paul

>> format draft floated the possibility of having explicit start/stop 
>> times signaled for each of the metatdata elements. But then we asked 
>> for feedback on which make sense.
>>
>> and stop time observable by the SRC, which might differ, at least a 
>> bit, from the corresponding signaling on the RS.
>>
>> We might want to report those times. Or, since we abstract the CS 
>> away from the dialog, we might want to report the start time of the 
>> first dialog in the CS as the CS start time, and the stop time of the 
>> last dialog in the CS as the CS stop time.
>>
>> Similarly, we have abstracted media streams away from the media 
>> streams in the sip dialogs that make up the CS. We might want to 
>> report the start time of a media stream as the time (according to the 
>> CS) of the first participant to a new media stream, and the stop time 
>> as the time that the last participant leaves the media stream.
>>
>> (Note the above doesn't solve the problem of getting correct clock 
>> times for RTP media. If anyone has a suggestion for this I'm all 
>> ears.)
>>
>> 	Thanks,
>> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Apr 2011 13:05:52 -0400

> About RTP time synchronization to metadata events, we either should have some low latency event from SRC to SRS with SRC time that will allow SRS to maintain time difference between its clock and S…

ISTM the issue isn't the latency of the event - it is what it is - but 
rather how to correlate a sip message containing metadata with a 
particular RTP packet. I suspect that needs to be tied into the 
discussion of the various models for how the SRC might handle RDP.

	Thanks,
	Paul

> Subject: Re: [siprec] start/stop times&  the metamodel
>
>
>

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 11 Apr 2011 14:26:19 -0700

A related question on the RTP model is that if the SRC as an RTP
translator chooses to relay the RTP timestamps, then how would the SRC
synchronize the timestamps between the SIP messages the multiple RTP
streams?

Henry 

> Sent: Monday, April 11, 2011 1:06 PM
> To: Leon Portman
> Cc: [email-masked]
> > I agree with proposed method of time stamping metadata elements with
> SRC clock (it is like a wall clock from the requirement document).
> > About RTP time synchronization to metadata events, we either should
> have some low latency event from SRC to SRS with SRC time that will
> allow SRS to maintain time difference between its clock and SRC clock
> and then apply it also to receive time of RTP packet (assuming no
> buffering)
> 
> >> I think much of what you say makes sense. I was concerned that we
> probably need to record when a participant stops or starts sending or
> receiving a stream, which seems to be covered by your statement:
> "Changes to media streams should similarly be tagged with the time
they
> occurred in the CS signaling. Each participant relationship change
> (send, receive, inactive,) will be there." That doesn't seem to be in
> the model at present.
> >
> > John,
> >

-------------------------------------------------------------------------------------------------------------------
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: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 12 Apr 2011 08:14:30 +0530

While I see it may be useful for the SRS to know when certain things
happened in CS signaling (participant joining, leaving, going mute etc)
I don't see how useful it would be for it know how those things are
related to when the participant actually sent/received (or stopped
sending/receiving) RTP.

If we see any use, one way to do it is using the NTP timestamp carried
in RTCP SR reports, provided the SRC, SRS and the participants have
access to the same reference wallclock.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Henry Lum
|Sent: Tuesday, April 12, 2011 2:56 AM
|To: Paul Kyzivat (pkyzivat); Leon Portman
|Cc: [email-masked]
|Subject: Re: [siprec] start/stop times & the metamodel
|
|A related question on the RTP model is that if the SRC as an RTP
|translator chooses to relay the RTP timestamps, then how would the SRC
|synchronize the timestamps between the SIP messages the multiple RTP
|streams?
|
|Henry
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Paul Kyzivat
|> Sent: Monday, April 11, 2011 1:06 PM
|> To: Leon Portman
|> Cc: [email-masked]
|> Subject: Re: [siprec] start/stop times & the metamodel
|>
|>
|>
|> On 4/11/2011 9:36 AM, Leon Portman wrote:
|> > Paul Hi
|> >
|> > I agree with proposed method of time stamping metadata elements
with
|> SRC clock (it is like a wall clock from the requirement document).
|> > About RTP time synchronization to metadata events, we either should
|> have some low latency event from SRC to SRS with SRC time that will
|> allow SRS to maintain time difference between its clock and SRC clock
|> and then apply it also to receive time of RTP packet (assuming no
|> buffering)
|>
|> ISTM the issue isn't the latency of the event - it is what it is -
but
|> rather how to correlate a sip message containing metadata with a
|> particular RTP packet. I suspect that needs to be tied into the
|> discussion of the various models for how the SRC might handle RDP.
|>
|> 	Thanks,
|> 	Paul
|>
|> > Leon
|> >
|> > -----Original Message-----
|> > From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Paul Kyzivat
|> > Sent: Monday, April 11, 2011 4:03 PM
|> > To: Elwell, John
|> > Cc: [email-masked]
|> > Subject: Re: [siprec] start/stop times&  the metamodel
|> >
|> >
|> >
|> > On 4/8/2011 11:53 AM, Elwell, John wrote:
|> >> Paul,
|> >>
|> >> I think much of what you say makes sense. I was concerned that we
|> probably need to record when a participant stops or starts sending or
|> receiving a stream, which seems to be covered by your statement:
|> "Changes to media streams should similarly be tagged with the time
|they
|> occurred in the CS signaling. Each participant relationship change
|> (send, receive, inactive,) will be there." That doesn't seem to be in
|> the model at present.
|> >
|> > John,
|> >
|> > I agree the current model doesn't reflect this - it was a private
|> thought by me, provoked by the work and discussion to date. It is a
|bit
|> of a change of direction, so I'm interested in what others think
about
|> it.
|> >
|> > 	Thanks,
|> > 	Paul
|> >
|> >> John (as individual)
|> >>
|> >>
|> >>> -----Original Message-----
|> >>> From: [email-masked]
|> >>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> >>> Sent: 06 April 2011 22:28
|> >>> To: [email-masked]
|> >>> Subject: [siprec] start/stop times&   the metamodel
|> >>>
|> >>> In Prague, one of the open issues was around start/stop times.
The
|> >>> format draft floated the possibility of having explicit
start/stop
|> >>> times signaled for each of the metatdata elements. But then we
|> asked
|> >>> for feedback on which make sense.
|> >>>
|> >>> IMO explicit start/stop times make more sense for some things
than
|> >>> others.
|> >>>
|> >>> One place where we potentially have explicit times to report with
|> the
|> >>> dialogs that constitute a CS. Each such dialog presumably has a
|> start
|> >>> and stop time observable by the SRC, which might differ, at least
|a
|> >>> bit, from the corresponding signaling on the RS.
|> >>>
|> >>> We might want to report those times. Or, since we abstract the CS
|> >>> away from the dialog, we might want to report the start time of
|the
|> >>> first dialog in the CS as the CS start time, and the stop time of
|> the
|> >>> last dialog in the CS as the CS stop time.
|> >>>
|> >>> Similarly, we have abstracted media streams away from the media
|> >>> streams in the sip dialogs that make up the CS. We might want to
|> >>> report the start time of a media stream as the time (according to
|> the
|> >>> CS) of the first participant to a new media stream, and the stop
|> time
|> >>> as the time that the last participant leaves the media stream.
|> >>>
|> >>> There are several things that complicate this:
|> >>>
|> >>> - Do we consider the case of a stream that starts with recvonly
|> >>>      or inactive participants, and only later gets a sender? If
|so,
|> >>>      is the start time of the stream when the first participant
|> arrived,
|> >>>      or when the first sender arrived?
|> >>>
|> >>> - How do we get the clock times for the media streams?
|> >>>      IIUC the correct ones are in the RTP/RTCP, but the reporting
|> of
|> >>>      these events is driven by the signaling, and we don't have
|> good
|> >>>      sync between those. (E.g. media could start flowing before
|the
|> >>>      corresponding signaling, and we would like to include that
if
|> we
|> >>>      can figure it out.) So, even if the clocks used for media
and
|> >>>      signaling are in sync, we might see media packets arrive
with
|> >>>      a timestamp prior to the timestamp for the signaling that
|> >>>      indicates the send state of the participant. This could
cause
|> >>>      trouble in playback.
|> >>>
|> >>> - There isn't any guarantee that the clock used for signaling
|> >>>      messages is synchronized with the clock used in RTP/RTCP.
|> >>>
|> >>> - There isn't any guarantee that there will be any RTCP at all,
|> >>>      to provide correlation of the RTP to clocktime.
|> >>>
|> >>> The best I can see to deal with all of this is:
|> >>>
|> >>> - All the metadata messages should be timestamped by the SRC
|> >>>      using its local clock. This is easily achieved by the Date
|> >>>      header in the sip message.
|> >>>
|> >>> - Changes to a CS, including changes of participants, should
|> >>>      be explicitly tagged with the time they occurred in the
|> >>>      CS signaling, according to the SRC's clock. (If that is
|> >>>      unavailable for some reason, then use the time the SRC
|> >>>      became aware of it.)
|> >>>
|> >>> - We could provide a metadata update element to indicate end
|> >>>      of a CS, but I suggest this just be shorthand for indicating
|> >>>      removal of all participants from it. (While its possible to
|> >>>      mark that the CS is truly ended, that simply introduces an
|> >>>      error case if added metadata about it is subsequently sent.)
|> >>>      The actual start/stop time would be determined by the SRS
|> >>>      based on the timestamps of first and last data about it.
|> >>>
|> >>> - Changes to media streams should similarly be tagged with
|> >>>      the time they occurred in the CS signaling. Each participant
|> >>>      relationship change (send, receive, inactive,) will be
there.
|> >>>      The actual start/stop time of the media stream again would
be
|> >>>      derived by the SRS.
|> >>>
|> >>> - CS-Groups can simply be tagged by the timestamps of the
|> >>>      updates that put CSs into them. Explicit start/stop times
|> don't
|> >>>      seem useful. If desired, the SRS can derive start/stop times
|> >>>      from the start/stop times of the contained stuff.
|> >>>
|> >>> - I now think that CS-Groups should not be "contained" within
|> >>>      a recording. This just seems to introduce unnecessary error
|> >>>      conditions, and limitations on future enhancements. The
|> >>>      lifetime of CS-Groups will probably be naturally limited by
|> >>>      the ability of the SRC to remember the IDs of old ones.
|> >>>      For instance, if a CS-G is created during one Recording,
|> >>>      and then another CS is added to it from a different
recording
|> >>>      session, would we prefer to fail that, or just allow it?
|> >>>      (I think allow.)
|> >>>
|> >>> - Rather, I think every update transmitted during a recording
|> >>>      session can be tagged with a link to the metadata of the
|> >>>      recording session it came from. This need not be explicit -
|> the
|> >>>      SRS can do it automatically. The recording session entity
|> >>>      itself will also have a start/stop time which is the start/
|> >>>      stop of the RS dialog as observed by the SRS.
|> >>>
|> >>> (Note the above doesn't solve the problem of getting correct
clock
|> >>> times for RTP media. If anyone has a suggestion for this I'm all
|> >>> ears.)
|> >>>
|> >>> 	Thanks,
|> >>> 	Paul
|> >>> _______________________________________________
|> >>> siprec mailing list
|> >>> [email-masked]
|> >>> https://www.ietf.org/mailman/listinfo/siprec
|> >>>
|> > _______________________________________________
|> > siprec mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/siprec
|> >
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|
|
|-----------------------------------------------------------------------
-------------------------------
|-------------
|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.
|
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 12 Apr 2011 12:10:39 +0530

This is one of the usecase wherein I'm interested in SRC architecture
with Application server (AS) & Media server (MS) as a different logical
entity. In case AS & MS are two different physical devices, it is highly
tough to sync CS RTP timestamp with RS metadata timestamp because the
delay between AS & MS communication for RTP timestamp has to be
considered. IMO, AS has to aware of the change in the signaling plane
and inform in RS metadata with timestamp rather than depend upon media
(RTP).   

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Muthu ArulMozhi Perumal (mperumal)
Sent: Tuesday, April 12, 2011 8:15 AM
To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] start/stop times & the metamodel

Muthu

|> the model at present.
|> >
|> > John,
|> >

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 12 Apr 2011 13:16:53 +0530

|In case AS & MS are two different physical devices,
|it is highly tough to sync CS RTP timestamp with RS 
|metadata timestamp because the delay between AS &
|MS communication for RTP timestamp has to be considered.

As Paul mentioned before, the delay/latency b/w call signaling and media
is what it is -- I don't see it as a problem as well. The question is
whether there is need to correlate the time of occurrence of events
conveyed through call signaling with the transmission/reception time of
media packets when those events occurred -- I don't see why the SRC/SRS
would find that useful, yet.

Muthu

|-----Original Message-----
|From: Parthasarathi R (partr)
|Sent: Tuesday, April 12, 2011 12:11 PM
|To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat
(pkyzivat); Leon Portman
|Cc: [email-masked]
|Subject: RE: [siprec] start/stop times & the metamodel
|
|This is one of the usecase wherein I'm interested in SRC architecture
with Application server (AS) &
|Media server (MS) as a different logical entity. In case AS & MS are
two different physical devices,
|it is highly tough to sync CS RTP timestamp with RS metadata timestamp
because the delay between AS &
|MS communication for RTP timestamp has to be considered. IMO, AS has to
aware of the change in the
|signaling plane and inform in RS metadata with timestamp rather than
depend upon media (RTP).
|
|Thanks
|Partha
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Muthu ArulMozhi Perumal
|(mperumal)
|Sent: Tuesday, April 12, 2011 8:15 AM
|To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
|Cc: [email-masked]
|Subject: Re: [siprec] start/stop times & the metamodel
|
|While I see it may be useful for the SRS to know when certain things
happened in CS signaling
|(participant joining, leaving, going mute etc) I don't see how useful
it would be for it know how
|those things are related to when the participant actually sent/received
(or stopped
|sending/receiving) RTP.
|
|If we see any use, one way to do it is using the NTP timestamp carried
in RTCP SR reports, provided
|the SRC, SRS and the participants have access to the same reference
wallclock.
|
|Muthu
|
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] On
|Behalf Of Henry Lum
||Sent: Tuesday, April 12, 2011 2:56 AM
||To: Paul Kyzivat (pkyzivat); Leon Portman
||Cc: [email-masked]
||Subject: Re: [siprec] start/stop times & the metamodel
||
||A related question on the RTP model is that if the SRC as an RTP
||translator chooses to relay the RTP timestamps, then how would the SRC
||synchronize the timestamps between the SIP messages the multiple RTP
||streams?
||
||Henry
||
||> -----Original Message-----
||> From: [email-masked] [mailto:[email-masked]] On
||> Behalf Of Paul Kyzivat
||> Sent: Monday, April 11, 2011 1:06 PM
||> To: Leon Portman
||> Cc: [email-masked]
||> Subject: Re: [siprec] start/stop times & the metamodel
||>
||>
||>
||> On 4/11/2011 9:36 AM, Leon Portman wrote:
||> > Paul Hi
||> >
||> > I agree with proposed method of time stamping metadata elements
|with
||> SRC clock (it is like a wall clock from the requirement document).
||> > About RTP time synchronization to metadata events, we either
should
||> have some low latency event from SRC to SRS with SRC time that will
||> allow SRS to maintain time difference between its clock and SRC
clock
||> and then apply it also to receive time of RTP packet (assuming no
||> buffering)
||>
||> ISTM the issue isn't the latency of the event - it is what it is -
|but
||> rather how to correlate a sip message containing metadata with a
||> particular RTP packet. I suspect that needs to be tied into the
||> discussion of the various models for how the SRC might handle RDP.
||>
||> 	Thanks,
||> 	Paul
||>
||> > Leon
||> >
||> > -----Original Message-----
||> > From: [email-masked] [mailto:[email-masked]] On
||> Behalf Of Paul Kyzivat
||> > Sent: Monday, April 11, 2011 4:03 PM
||> > To: Elwell, John
||> > Cc: [email-masked]
||> > Subject: Re: [siprec] start/stop times&  the metamodel
||> >
||> >
||> >
||> > On 4/8/2011 11:53 AM, Elwell, John wrote:
||> >> Paul,
||> >>
||> >> I think much of what you say makes sense. I was concerned that we
||> probably need to record when a participant stops or starts sending
or
||> receiving a stream, which seems to be covered by your statement:
||> "Changes to media streams should similarly be tagged with the time
||they
||> occurred in the CS signaling. Each participant relationship change
||> (send, receive, inactive,) will be there." That doesn't seem to be
in
||> the model at present.
||> >
||> > John,
||> >
||> > I agree the current model doesn't reflect this - it was a private
||> thought by me, provoked by the work and discussion to date. It is a
||bit
||> of a change of direction, so I'm interested in what others think
|about
||> it.
||> >
||> > 	Thanks,
||> > 	Paul
||> >
||> >> John (as individual)
||> >>
||> >>
||> >>> -----Original Message-----
||> >>> From: [email-masked]
||> >>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
||> >>> Sent: 06 April 2011 22:28
||> >>> To: [email-masked]
||> >>> Subject: [siprec] start/stop times&   the metamodel
||> >>>
||> >>> In Prague, one of the open issues was around start/stop times.
|The
||> >>> format draft floated the possibility of having explicit
|start/stop
||> >>> times signaled for each of the metatdata elements. But then we
||> asked
||> >>> for feedback on which make sense.
||> >>>
||> >>> IMO explicit start/stop times make more sense for some things
|than
||> >>> others.
||> >>>
||> >>> One place where we potentially have explicit times to report
with
||> the
||> >>> dialogs that constitute a CS. Each such dialog presumably has a
||> start
||> >>> and stop time observable by the SRC, which might differ, at
least
||a
||> >>> bit, from the corresponding signaling on the RS.
||> >>>
||> >>> We might want to report those times. Or, since we abstract the
CS
||> >>> away from the dialog, we might want to report the start time of
||the
||> >>> first dialog in the CS as the CS start time, and the stop time
of
||> the
||> >>> last dialog in the CS as the CS stop time.
||> >>>
||> >>> Similarly, we have abstracted media streams away from the media
||> >>> streams in the sip dialogs that make up the CS. We might want to
||> >>> report the start time of a media stream as the time (according
to
||> the
||> >>> CS) of the first participant to a new media stream, and the stop
||> time
||> >>> as the time that the last participant leaves the media stream.
||> >>>
||> >>> There are several things that complicate this:
||> >>>
||> >>> - Do we consider the case of a stream that starts with recvonly
||> >>>      or inactive participants, and only later gets a sender? If
||so,
||> >>>      is the start time of the stream when the first participant
||> arrived,
||> >>>      or when the first sender arrived?
||> >>>
||> >>> - How do we get the clock times for the media streams?
||> >>>      IIUC the correct ones are in the RTP/RTCP, but the
reporting
||> of
||> >>>      these events is driven by the signaling, and we don't have
||> good
||> >>>      sync between those. (E.g. media could start flowing before
||the
||> >>>      corresponding signaling, and we would like to include that
|if
||> we
||> >>>      can figure it out.) So, even if the clocks used for media
|and
||> >>>      signaling are in sync, we might see media packets arrive
|with
||> >>>      a timestamp prior to the timestamp for the signaling that
||> >>>      indicates the send state of the participant. This could
|cause
||> >>>      trouble in playback.
||> >>>
||> >>> - There isn't any guarantee that the clock used for signaling
||> >>>      messages is synchronized with the clock used in RTP/RTCP.
||> >>>
||> >>> - There isn't any guarantee that there will be any RTCP at all,
||> >>>      to provide correlation of the RTP to clocktime.
||> >>>
||> >>> The best I can see to deal with all of this is:
||> >>>
||> >>> - All the metadata messages should be timestamped by the SRC
||> >>>      using its local clock. This is easily achieved by the Date
||> >>>      header in the sip message.
||> >>>
||> >>> - Changes to a CS, including changes of participants, should
||> >>>      be explicitly tagged with the time they occurred in the
||> >>>      CS signaling, according to the SRC's clock. (If that is
||> >>>      unavailable for some reason, then use the time the SRC
||> >>>      became aware of it.)
||> >>>
||> >>> - We could provide a metadata update element to indicate end
||> >>>      of a CS, but I suggest this just be shorthand for
indicating
||> >>>      removal of all participants from it. (While its possible to
||> >>>      mark that the CS is truly ended, that simply introduces an
||> >>>      error case if added metadata about it is subsequently
sent.)
||> >>>      The actual start/stop time would be determined by the SRS
||> >>>      based on the timestamps of first and last data about it.
||> >>>
||> >>> - Changes to media streams should similarly be tagged with
||> >>>      the time they occurred in the CS signaling. Each
participant
||> >>>      relationship change (send, receive, inactive,) will be
|there.
||> >>>      The actual start/stop time of the media stream again would
|be
||> >>>      derived by the SRS.
||> >>>
||> >>> - CS-Groups can simply be tagged by the timestamps of the
||> >>>      updates that put CSs into them. Explicit start/stop times
||> don't
||> >>>      seem useful. If desired, the SRS can derive start/stop
times
||> >>>      from the start/stop times of the contained stuff.
||> >>>
||> >>> - I now think that CS-Groups should not be "contained" within
||> >>>      a recording. This just seems to introduce unnecessary error
||> >>>      conditions, and limitations on future enhancements. The
||> >>>      lifetime of CS-Groups will probably be naturally limited by
||> >>>      the ability of the SRC to remember the IDs of old ones.
||> >>>      For instance, if a CS-G is created during one Recording,
||> >>>      and then another CS is added to it from a different
|recording
||> >>>      session, would we prefer to fail that, or just allow it?
||> >>>      (I think allow.)
||> >>>
||> >>> - Rather, I think every update transmitted during a recording
||> >>>      session can be tagged with a link to the metadata of the
||> >>>      recording session it came from. This need not be explicit -
||> the
||> >>>      SRS can do it automatically. The recording session entity
||> >>>      itself will also have a start/stop time which is the start/
||> >>>      stop of the RS dialog as observed by the SRS.
||> >>>
||> >>> (Note the above doesn't solve the problem of getting correct
|clock
||> >>> times for RTP media. If anyone has a suggestion for this I'm all
||> >>> ears.)
||> >>>
||> >>> 	Thanks,
||> >>> 	Paul
||> >>> _______________________________________________
||> >>> siprec mailing list
||> >>> [email-masked]
||> >>> https://www.ietf.org/mailman/listinfo/siprec
||> >>>
||> > _______________________________________________
||> > siprec mailing list
||> > [email-masked]
||> > https://www.ietf.org/mailman/listinfo/siprec
||> >
||> _______________________________________________
||> siprec mailing list
||> [email-masked]
||> https://www.ietf.org/mailman/listinfo/siprec
||
||
||----------------------------------------------------------------------
-
|-------------------------------
||-------------
||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.
||
||_______________________________________________
||siprec mailing list
[email-masked]
||https://www.ietf.org/mailman/listinfo/siprec
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 12 Apr 2011 13:17:02 +0530

Inline 
A comment on this mail

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Monday, April 11, 2011 6:33 PM
> To: Elwell, John
> Cc: [email-masked]
they
> (send, receive, inactive,) will be there." That doesn't seem to be in

I agree on sending information of when a participant start/stop sending
media [ from SRC perspective - what SRC sees] in the metadata. Do we
really need reporting Changes to the media streams of CS like send,
receive, inactive ? This would again go back to sending portions of CS
SDP [ in this case direction attribute] in metadata.

Ram

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 12 Apr 2011 13:51:29 +0530

|I agree on sending information of when a participant start/stop 
|sending media [ from SRC perspective - what SRC sees] in the 
|metadata. Do we  really need reporting Changes to the media 
|streams of CS like send, receive, inactive ?

Aren't they related? If a participant goes recvonly or inactive it is an
indication that he isn't going to send anything, so SRS might want to
know this in order to pause recording the media stream coming from that
participant and save some disk space -- might be useful in environment
where occasional small clips in the recorded stream isn't a problem. An
alternative is for the SRC to run media activity/inactivity detection
and report it to the SRS (which can also suffer from media clipping).
However, not every SRC might be capable of doing this.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ram Mohan R (rmohanr)
|Sent: Tuesday, April 12, 2011 1:17 PM
|To: Paul Kyzivat (pkyzivat); Elwell, John
|Cc: [email-masked]
|Subject: Re: [siprec] start/stop times & the metamodel
|
|Inline
|A comment on this mail
|
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Paul Kyzivat (pkyzivat)
|> Sent: Monday, April 11, 2011 6:33 PM
|> To: Elwell, John
|> Cc: [email-masked]
|> Subject: Re: [siprec] start/stop times & the metamodel
|>
|>
|>
|> On 4/8/2011 11:53 AM, Elwell, John wrote:
|> > Paul,
|> >
|> > I think much of what you say makes sense. I was concerned that we
|> probably need to record when a participant stops or starts sending or
|> receiving a stream, which seems to be covered by your statement:
|> "Changes to media streams should similarly be tagged with the time
|they
|> occurred in the CS signaling. Each participant relationship change
|> (send, receive, inactive,) will be there." That doesn't seem to be in
|> the model at present.
|
|I agree on sending information of when a participant start/stop sending
|media [ from SRC perspective - what SRC sees] in the metadata. Do we
|really need reporting Changes to the media streams of CS like send,
|receive, inactive ? This would again go back to sending portions of CS
|SDP [ in this case direction attribute] in metadata.
|
|Ram
|
|>
|> John,
|>
|> I agree the current model doesn't reflect this - it was a private
|> thought by me, provoked by the work and discussion to date. It is a
|bit
|> of a change of direction, so I'm interested in what others think
about
|> it.
|>
|> 	Thanks,
|> 	Paul
|>
|> > John (as individual)
|> >
|> >
|> >> -----Original Message-----
|> >> From: [email-masked]
|> >> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> >> Sent: 06 April 2011 22:28
|> >> To: [email-masked]
|> >> Subject: [siprec] start/stop times&  the metamodel
|> >>
|> >> In Prague, one of the open issues was around start/stop times. The
|> >> format draft floated the possibility of having explicit
|> >> start/stop times
|> >> signaled for each of the metatdata elements. But then we asked for
|> >> feedback on which make sense.
|> >>
|> >> IMO explicit start/stop times make more sense for some things
|> >> than others.
|> >>
|> >> One place where we potentially have explicit times to report with
|> the
|> >> dialogs that constitute a CS. Each such dialog presumably has a
|> start
|> >> and stop time observable by the SRC, which might differ, at
|> >> least a bit,
|> >> from the corresponding signaling on the RS.
|> >>
|> >> We might want to report those times. Or, since we abstract
|> >> the CS away
|> >> from the dialog, we might want to report the start time of the
|first
|> >> dialog in the CS as the CS start time, and the stop time of the
|last
|> >> dialog in the CS as the CS stop time.
|> >>
|> >> Similarly, we have abstracted media streams away from the
|> >> media streams
|> >> in the sip dialogs that make up the CS. We might want to report
the
|> >> start time of a media stream as the time (according to the CS) of
|> the
|> >> first participant to a new media stream, and the stop time as
|> >> the time
|> >> that the last participant leaves the media stream.
|> >>
|> >> There are several things that complicate this:
|> >>
|> >> - Do we consider the case of a stream that starts with recvonly
|> >>     or inactive participants, and only later gets a sender? If so,
|> >>     is the start time of the stream when the first participant
|> arrived,
|> >>     or when the first sender arrived?
|> >>
|> >> - How do we get the clock times for the media streams?
|> >>     IIUC the correct ones are in the RTP/RTCP, but the reporting
of
|> >>     these events is driven by the signaling, and we don't have
good
|> >>     sync between those. (E.g. media could start flowing before the
|> >>     corresponding signaling, and we would like to include that if
|we
|> >>     can figure it out.) So, even if the clocks used for media and
|> >>     signaling are in sync, we might see media packets arrive with
|> >>     a timestamp prior to the timestamp for the signaling that
|> >>     indicates the send state of the participant. This could cause
|> >>     trouble in playback.
|> >>
|> >> - There isn't any guarantee that the clock used for signaling
|> >>     messages is synchronized with the clock used in RTP/RTCP.
|> >>
|> >> - There isn't any guarantee that there will be any RTCP at all,
|> >>     to provide correlation of the RTP to clocktime.
|> >>
|> >> The best I can see to deal with all of this is:
|> >>
|> >> - All the metadata messages should be timestamped by the SRC
|> >>     using its local clock. This is easily achieved by the Date
|> >>     header in the sip message.
|> >>
|> >> - Changes to a CS, including changes of participants, should
|> >>     be explicitly tagged with the time they occurred in the
|> >>     CS signaling, according to the SRC's clock. (If that is
|> >>     unavailable for some reason, then use the time the SRC
|> >>     became aware of it.)
|> >>
|> >> - We could provide a metadata update element to indicate end
|> >>     of a CS, but I suggest this just be shorthand for indicating
|> >>     removal of all participants from it. (While its possible to
|> >>     mark that the CS is truly ended, that simply introduces an
|> >>     error case if added metadata about it is subsequently sent.)
|> >>     The actual start/stop time would be determined by the SRS
|> >>     based on the timestamps of first and last data about it.
|> >>
|> >> - Changes to media streams should similarly be tagged with
|> >>     the time they occurred in the CS signaling. Each participant
|> >>     relationship change (send, receive, inactive,) will be there.
|> >>     The actual start/stop time of the media stream again would be
|> >>     derived by the SRS.
|> >>
|> >> - CS-Groups can simply be tagged by the timestamps of the
|> >>     updates that put CSs into them. Explicit start/stop times
don't
|> >>     seem useful. If desired, the SRS can derive start/stop times
|> >>     from the start/stop times of the contained stuff.
|> >>
|> >> - I now think that CS-Groups should not be "contained" within
|> >>     a recording. This just seems to introduce unnecessary error
|> >>     conditions, and limitations on future enhancements. The
|> >>     lifetime of CS-Groups will probably be naturally limited by
|> >>     the ability of the SRC to remember the IDs of old ones.
|> >>     For instance, if a CS-G is created during one Recording,
|> >>     and then another CS is added to it from a different recording
|> >>     session, would we prefer to fail that, or just allow it?
|> >>     (I think allow.)
|> >>
|> >> - Rather, I think every update transmitted during a recording
|> >>     session can be tagged with a link to the metadata of the
|> >>     recording session it came from. This need not be explicit -
the
|> >>     SRS can do it automatically. The recording session entity
|> >>     itself will also have a start/stop time which is the start/
|> >>     stop of the RS dialog as observed by the SRS.
|> >>
|> >> (Note the above doesn't solve the problem of getting correct
|> >> clock times
|> >> for RTP media. If anyone has a suggestion for this I'm all ears.)
|> >>
|> >> 	Thanks,
|> >> 	Paul
|> >> _______________________________________________
|> >> siprec mailing list
|> >> [email-masked]
|> >> https://www.ietf.org/mailman/listinfo/siprec
|> >>
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 12 Apr 2011 14:17:05 +0530

Inline

> From: Muthu ArulMozhi Perumal (mperumal)
> Sent: Tuesday, April 12, 2011 1:51 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] start/stop times & the metamodel
> 
> Aren't they related? If a participant goes recvonly or inactive it is
> an indication that he isn't going to send anything, so SRS might want
> to know this in order to pause recording the media stream coming from
> that participant and save some disk space -- might be useful in
> environment where occasional small clips in the recorded stream isn't
a
> problem. An alternative is for the SRC to run media
activity/inactivity
> detection and report it to the SRS (which can also suffer from media
> clipping). However, not every SRC might be capable of doing this.

SRC to SRS indication of participant hold/resume can happen through
updates in RS SIP dialog. What I am asking here is if there is a need to
report the original CS SDP media params (say direction attribute)
explicitly in the metadata to RS.

Ram

> sending

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 12 Apr 2011 14:50:16 +0530

|SRC to SRS indication of participant hold/resume can 
|happen through updates in RS SIP dialog. What I am 
|asking here is if there is a need to report the original 
|CS SDP media params (say direction attribute) explicitly 
|in the metadata to RS.

The SRC might have its own policy of when (and when not) to pause the
recording, which it can achieve through the RS dialog. The SRS on the
other hand might also have policies on when (and when not) to record
based on the participants media state. So, I see it might be useful to
convey this information in metadata if the SRS wants to take decisions
independent of the SRC. Also, since only metadata is persistent, making
it available in metadata might be handy for the SRS, for future
interpretation.

Muthu

|-----Original Message-----
|From: Ram Mohan R (rmohanr)
|Sent: Tuesday, April 12, 2011 2:17 PM
|To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat);
'Elwell, John'
|Cc: [email-masked]'
|Subject: RE: [siprec] start/stop times & the metamodel
|
|Inline
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal)
|> Sent: Tuesday, April 12, 2011 1:51 PM
|> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
|> Cc: [email-masked]
|> Subject: RE: [siprec] start/stop times & the metamodel
|>
|> |I agree on sending information of when a participant start/stop
|> |sending media [ from SRC perspective - what SRC sees] in the
|> |metadata. Do we  really need reporting Changes to the media
|> |streams of CS like send, receive, inactive ?
|>
|> Aren't they related? If a participant goes recvonly or inactive it is
|> an indication that he isn't going to send anything, so SRS might want
|> to know this in order to pause recording the media stream coming from
|> that participant and save some disk space -- might be useful in
|> environment where occasional small clips in the recorded stream isn't
a
|> problem. An alternative is for the SRC to run media
activity/inactivity
|> detection and report it to the SRS (which can also suffer from media
|> clipping). However, not every SRC might be capable of doing this.
|
|SRC to SRS indication of participant hold/resume can happen through
updates in RS SIP dialog. What I
|am asking here is if there is a need to report the original CS SDP
media params (say direction
|attribute) explicitly in the metadata to RS.
|
|Ram
|
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Ram Mohan R (rmohanr)
|> |Sent: Tuesday, April 12, 2011 1:17 PM
|> |To: Paul Kyzivat (pkyzivat); Elwell, John
|> |Cc: [email-masked]
|> |Subject: Re: [siprec] start/stop times & the metamodel
|> |
|> |Inline
|> |A comment on this mail
|> |
|> |
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|> |> Behalf Of Paul Kyzivat (pkyzivat)
|> |> Sent: Monday, April 11, 2011 6:33 PM
|> |> To: Elwell, John
|> |> Cc: [email-masked]
|> |> Subject: Re: [siprec] start/stop times & the metamodel
|> |>
|> |>
|> |>
|> |> On 4/8/2011 11:53 AM, Elwell, John wrote:
|> |> > Paul,
|> |> >
|> |> > I think much of what you say makes sense. I was concerned that
we
|> |> probably need to record when a participant stops or starts sending
|> or
|> |> receiving a stream, which seems to be covered by your statement:
|> |> "Changes to media streams should similarly be tagged with the time
|> |they
|> |> occurred in the CS signaling. Each participant relationship change
|> |> (send, receive, inactive,) will be there." That doesn't seem to be
|> in
|> |> the model at present.
|> |
|> |I agree on sending information of when a participant start/stop
|> sending
|> |media [ from SRC perspective - what SRC sees] in the metadata. Do we
|> |really need reporting Changes to the media streams of CS like send,
|> |receive, inactive ? This would again go back to sending portions of
CS
|> |SDP [ in this case direction attribute] in metadata.
|> |
|> |Ram
|> |
|> |>
|> |> John,
|> |>
|> |> I agree the current model doesn't reflect this - it was a private
|> |> thought by me, provoked by the work and discussion to date. It is
a
|> |bit
|> |> of a change of direction, so I'm interested in what others think
|> about
|> |> it.
|> |>
|> |> 	Thanks,
|> |> 	Paul
|> |>
|> |> > John (as individual)
|> |> >
|> |> >
|> |> >> -----Original Message-----
|> |> >> From: [email-masked]
|> |> >> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> |> >> Sent: 06 April 2011 22:28
|> |> >> To: [email-masked]
|> |> >> Subject: [siprec] start/stop times&  the metamodel
|> |> >>
|> |> >> In Prague, one of the open issues was around start/stop times.
|> The
|> |> >> format draft floated the possibility of having explicit
|> |> >> start/stop times
|> |> >> signaled for each of the metatdata elements. But then we asked
|> for
|> |> >> feedback on which make sense.
|> |> >>
|> |> >> IMO explicit start/stop times make more sense for some things
|> |> >> than others.
|> |> >>
|> |> >> One place where we potentially have explicit times to report
with
|> |> the
|> |> >> dialogs that constitute a CS. Each such dialog presumably has a
|> |> start
|> |> >> and stop time observable by the SRC, which might differ, at
|> |> >> least a bit,
|> |> >> from the corresponding signaling on the RS.
|> |> >>
|> |> >> We might want to report those times. Or, since we abstract
|> |> >> the CS away
|> |> >> from the dialog, we might want to report the start time of the
|> |first
|> |> >> dialog in the CS as the CS start time, and the stop time of the
|> |last
|> |> >> dialog in the CS as the CS stop time.
|> |> >>
|> |> >> Similarly, we have abstracted media streams away from the
|> |> >> media streams
|> |> >> in the sip dialogs that make up the CS. We might want to report
|> the
|> |> >> start time of a media stream as the time (according to the CS)
of
|> |> the
|> |> >> first participant to a new media stream, and the stop time as
|> |> >> the time
|> |> >> that the last participant leaves the media stream.
|> |> >>
|> |> >> There are several things that complicate this:
|> |> >>
|> |> >> - Do we consider the case of a stream that starts with recvonly
|> |> >>     or inactive participants, and only later gets a sender? If
|> so,
|> |> >>     is the start time of the stream when the first participant
|> |> arrived,
|> |> >>     or when the first sender arrived?
|> |> >>
|> |> >> - How do we get the clock times for the media streams?
|> |> >>     IIUC the correct ones are in the RTP/RTCP, but the
reporting
|> of
|> |> >>     these events is driven by the signaling, and we don't have
|> good
|> |> >>     sync between those. (E.g. media could start flowing before
|> the
|> |> >>     corresponding signaling, and we would like to include that
if
|> |we
|> |> >>     can figure it out.) So, even if the clocks used for media
and
|> |> >>     signaling are in sync, we might see media packets arrive
with
|> |> >>     a timestamp prior to the timestamp for the signaling that
|> |> >>     indicates the send state of the participant. This could
cause
|> |> >>     trouble in playback.
|> |> >>
|> |> >> - There isn't any guarantee that the clock used for signaling
|> |> >>     messages is synchronized with the clock used in RTP/RTCP.
|> |> >>
|> |> >> - There isn't any guarantee that there will be any RTCP at all,
|> |> >>     to provide correlation of the RTP to clocktime.
|> |> >>
|> |> >> The best I can see to deal with all of this is:
|> |> >>
|> |> >> - All the metadata messages should be timestamped by the SRC
|> |> >>     using its local clock. This is easily achieved by the Date
|> |> >>     header in the sip message.
|> |> >>
|> |> >> - Changes to a CS, including changes of participants, should
|> |> >>     be explicitly tagged with the time they occurred in the
|> |> >>     CS signaling, according to the SRC's clock. (If that is
|> |> >>     unavailable for some reason, then use the time the SRC
|> |> >>     became aware of it.)
|> |> >>
|> |> >> - We could provide a metadata update element to indicate end
|> |> >>     of a CS, but I suggest this just be shorthand for
indicating
|> |> >>     removal of all participants from it. (While its possible to
|> |> >>     mark that the CS is truly ended, that simply introduces an
|> |> >>     error case if added metadata about it is subsequently
sent.)
|> |> >>     The actual start/stop time would be determined by the SRS
|> |> >>     based on the timestamps of first and last data about it.
|> |> >>
|> |> >> - Changes to media streams should similarly be tagged with
|> |> >>     the time they occurred in the CS signaling. Each
participant
|> |> >>     relationship change (send, receive, inactive,) will be
there.
|> |> >>     The actual start/stop time of the media stream again would
be
|> |> >>     derived by the SRS.
|> |> >>
|> |> >> - CS-Groups can simply be tagged by the timestamps of the
|> |> >>     updates that put CSs into them. Explicit start/stop times
|> don't
|> |> >>     seem useful. If desired, the SRS can derive start/stop
times
|> |> >>     from the start/stop times of the contained stuff.
|> |> >>
|> |> >> - I now think that CS-Groups should not be "contained" within
|> |> >>     a recording. This just seems to introduce unnecessary error
|> |> >>     conditions, and limitations on future enhancements. The
|> |> >>     lifetime of CS-Groups will probably be naturally limited by
|> |> >>     the ability of the SRC to remember the IDs of old ones.
|> |> >>     For instance, if a CS-G is created during one Recording,
|> |> >>     and then another CS is added to it from a different
recording
|> |> >>     session, would we prefer to fail that, or just allow it?
|> |> >>     (I think allow.)
|> |> >>
|> |> >> - Rather, I think every update transmitted during a recording
|> |> >>     session can be tagged with a link to the metadata of the
|> |> >>     recording session it came from. This need not be explicit -
|> the
|> |> >>     SRS can do it automatically. The recording session entity
|> |> >>     itself will also have a start/stop time which is the start/
|> |> >>     stop of the RS dialog as observed by the SRS.
|> |> >>
|> |> >> (Note the above doesn't solve the problem of getting correct
|> |> >> clock times
|> |> >> for RTP media. If anyone has a suggestion for this I'm all
ears.)
|> |> >>
|> |> >> 	Thanks,
|> |> >> 	Paul
|> |> >> _______________________________________________
|> |> >> siprec mailing list
|> |> >> [email-masked]
|> |> >> https://www.ietf.org/mailman/listinfo/siprec
|> |> >>
|> |> _______________________________________________
|> |> siprec mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/siprec
|> |_______________________________________________
|> |siprec mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 12 Apr 2011 15:08:00 +0530

Muthu,

I agree with you that till now there is no strong usecase for SRS to
have the timestamp information about media (RTP/RTCP) packets. 

I added further and mentioned even if somebody looks for it, the
timestamp information about media packet is not possible to be achieved
in all architecture without delay/latency.

Thanks
Partha 

-----Original Message-----
From: Muthu ArulMozhi Perumal (mperumal) 
Sent: Tuesday, April 12, 2011 1:17 PM
To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon
Portman'
Cc: [email-masked]'

|In case AS & MS are two different physical devices, it is highly tough 
|to sync CS RTP timestamp with RS metadata timestamp because the delay 
|between AS & MS communication for RTP timestamp has to be considered.

Muthu

|-----Original Message-----
|From: Parthasarathi R (partr)
|Sent: Tuesday, April 12, 2011 12:11 PM
|To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat 
|(pkyzivat); Leon Portman
|Cc: [email-masked]
|Subject: RE: [siprec] start/stop times & the metamodel
|
|This is one of the usecase wherein I'm interested in SRC architecture 
|with Application server (AS) & Media server (MS) as a different logical

|entity. In case AS & MS are two different physical devices, it is 
|highly tough to sync CS RTP timestamp with RS metadata timestamp 
|because the delay between AS & MS communication for RTP timestamp has
to be considered. IMO, AS has to aware of the change in the signaling
plane and inform in RS metadata with timestamp rather than depend upon
media (RTP).
|
|Thanks
|Partha
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Muthu ArulMozhi Perumal
|(mperumal)
|Sent: Tuesday, April 12, 2011 8:15 AM
|To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
|Cc: [email-masked]
|Subject: Re: [siprec] start/stop times & the metamodel
|
|While I see it may be useful for the SRS to know when certain things 
|happened in CS signaling (participant joining, leaving, going mute etc)

|I don't see how useful it would be for it know how those things are 
|related to when the participant actually sent/received (or stopped
|sending/receiving) RTP.
|
|If we see any use, one way to do it is using the NTP timestamp carried 
|in RTCP SR reports, provided the SRC, SRS and the participants have
access to the same reference wallclock.
|
|Muthu
|
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] On
|Behalf Of Henry Lum
||Sent: Tuesday, April 12, 2011 2:56 AM
||To: Paul Kyzivat (pkyzivat); Leon Portman
||Cc: [email-masked]
||Subject: Re: [siprec] start/stop times & the metamodel
||
||A related question on the RTP model is that if the SRC as an RTP 
||translator chooses to relay the RTP timestamps, then how would the SRC

||> > should
||> clock and then apply it also to receive time of RTP packet (assuming

||> no
||> buffering)
||>
||> or receiving a stream, which seems to be covered by your statement:
||> in the model at present.
||> >>> with
||> >>> least
||> >>> CS away from the dialog, we might want to report the start time 
||> >>> of
||> >>> of

||> >>> to
||> >>> reporting
||-
||by

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 12 Apr 2011 11:42:29 +0200

I think the indication in the metadata can be constructed by the SRC based on information it sends or receives in CS SDP, but this does not necessarily mean that it should be conveyed in RS SDP - it should be conveyed in XML. So I agree with Muthu.

Note that starting to send a particular Media Stream can be a result of various changes in CS SDP, e.g:
- addition of an m-line;
- changing m-line port from zero to non-zero;
- changing from inactive to sendrecv;
- changing from recvonly to sendrecv;
- changing from inactive to sendonly.

Similarly starting to receive, ceasing to send and ceasing to receive can all arise from a number of different changes to CS SDP.

The SRS should not need to understand all the details of CS SDP changes, but should just be given an abstraction, i.e., it should be told that a given participant is starting/stopping sending/receiving a media stream, in line with the metadata model.

John (as individual)

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]] 
> Sent: 12 April 2011 10:20

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 12 Apr 2011 15:22:43 +0530

Hi John,

Inline 

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2011 3:12 PM
> To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul
> Kyzivat (pkyzivat)
> Cc: [email-masked]
> I think the indication in the metadata can be constructed by the SRC
> based on information it sends or receives in CS SDP, but this does not
> necessarily mean that it should be conveyed in RS SDP - it should be
> conveyed in XML. So I agree with Muthu.
> 
> Note that starting to send a particular Media Stream can be a result
of
> various changes in CS SDP, e.g:
> - addition of an m-line;
> Similarly starting to receive, ceasing to send and ceasing to receive
> can all arise from a number of different changes to CS SDP.
> 
> The SRS should not need to understand all the details of CS SDP
> changes, but should just be given an abstraction, i.e., it should be
> told that a given participant is starting/stopping sending/receiving a
> media stream, in line with the metadata model.

If we are ok to abstract the details and indicate starting/stopping
sending/receiving a media stream, the current model already does it. Do
you see a need to have anything else in the model to accommodate this ?

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Apr 2011 08:40:35 -0400

The problem I see (which is out of scope for now of our work) is how one 
queries/plays back the data and metadata captured by the SRS. Presumably 
one wants to look for a particular CS and then play it back, and have 
the events unfold in the same sequence they did in realtime. That means 
correlating events in the metadata with recorded media.

And its not just clocks for the signaling vs media. Its also 
synchronizing the different media streams. If you have one media stream 
from A to B, and another from B to A, then it can be very important to 
synchronize those for playback. But they may have been generated with 
very different clocks. And there is also the possibility that they 
didn't have RTCP at all, and so have no mapping to clock time.

In some cases there will be insufficient data to precisely synchronize 
the clocks, but even an imprecise sync done "at the time" is likely to 
be better than trying to figure it out after the fact with insufficient 
data.

The alternative seems to be to partition the recorded media independent 
of its clocking, and then associate the start time of the partition with 
some metadata that is assumed to have happened at about the same time. 
But that doesn't necessarily work very well, especially for persistent 
recording.

	Thanks,
	Paul

On 4/12/2011 5:38 AM, Parthasarathi R (partr) wrote:
> Subject: RE: [siprec] start/stop times&  the metamodel
>
> |In case AS&  MS are two different physical devices, it is highly tough
> |between AS&  MS communication for RTP timestamp has to be considered.
>
> |Subject: RE: [siprec] start/stop times&  the metamodel
> |
> |with Application server (AS)&  Media server (MS) as a different logical
>
> |entity. In case AS&  MS are two different physical devices, it is
> |because the delay between AS&  MS communication for RTP timestamp has
> |Subject: Re: [siprec] start/stop times&  the metamodel
> |
> ||Subject: Re: [siprec] start/stop times&  the metamodel
> ||
> ||>  Subject: Re: [siprec] start/stop times&  the metamodel
> ||>
> ||>
> ||>

---

From: "Henry Lum" <[email-masked]>
Date: Tue, 12 Apr 2011 14:12:42 -0700

I don't think it is guaranteed that participants will send SR reports
(or any RTCP), plus we will also have to assume that the NTP timestamps
are in sync. We could mandate the SRC to generate SR reports but then we
are fixing the RTP model for the SRC. 

Regards,
Henry

> Sent: Monday, April 11, 2011 10:45 PM
|----------------------------------------------------------------------

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 13 Apr 2011 11:20:00 +0530

Henry,

I attached the follow up mail to below mail thread. Till now, We don't
have strong requirement to solve in SIPREC. Let us identify the
requirement before going to the solution.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Wednesday, April 13, 2011 2:43 AM
To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon
Portman
Cc: [email-masked]
Subject: Re: [siprec] start/stop times & the metamodel

Regards,
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.

Subject: Re: [siprec] start/stop times & the metamodel
From: "Parthasarathi R (partr)" <[email-masked]>
To: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>, "Henry Lum" <[email-masked]>, "Paul Kyzivat (pkyzivat)" <[email-masked]>, "Leon Portman" <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 12 Apr 2011 15:08:00 +0530

Muthu,

Thanks
Partha 

-----Original Message-----
From: Muthu ArulMozhi Perumal (mperumal) 
Sent: Tuesday, April 12, 2011 1:17 PM
To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon
Portman'
Cc: [email-masked]'

Muthu

||> no
||> buffering)
||>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Apr 2011 12:09:32 +0530

That's a good use-case and I think we need to still consider those
aspects of SRC that would enable meaningful interpretation of the
recorded data for queries/playback, within the scope of our work. 

A few possibilities I can think of in the decreasing order of accuracy
for synchronization:
1. The SRC is a mixer and does the synchronization b/w the media
streams, generating a single (mixed) stream towards the SRS with its own
timestamps. It generates metadata with the wallclock time in sync with
the recorded media. If needed, it indicates the correlation b/w the
wallcalock time and the RTP timestamps by generating RTCP.

2. The SRC is neither a mixer nor a translator, but is capable of
rewriting the RTP/RTCP timestamps in the media streams it sends towards
the SRS. It generates metadata with the wallclock time in sync with the
recorded media.

3. The SRC is a translator capable of indicating only the start/end time
of each CS to the SRS. It generates metadata placing the start/stop
wallclock time at which it notices the corresponding events in the CS,
in the metadata.

Muthu 

|-----Original Message-----
|From: Paul Kyzivat (pkyzivat)
|Sent: Tuesday, April 12, 2011 6:11 PM
|To: Parthasarathi R (partr)
|Cc: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Leon Portman;
[email-masked]
|Subject: Re: [siprec] start/stop times & the metamodel
|
|The problem I see (which is out of scope for now of our work) is how
one
|queries/plays back the data and metadata captured by the SRS.
Presumably
|one wants to look for a particular CS and then play it back, and have
|the events unfold in the same sequence they did in realtime. That means
|correlating events in the metadata with recorded media.
|
|And its not just clocks for the signaling vs media. Its also
|synchronizing the different media streams. If you have one media stream
|from A to B, and another from B to A, then it can be very important to
|synchronize those for playback. But they may have been generated with
|very different clocks. And there is also the possibility that they
|didn't have RTCP at all, and so have no mapping to clock time.
|
|In some cases there will be insufficient data to precisely synchronize
|the clocks, but even an imprecise sync done "at the time" is likely to
|be better than trying to figure it out after the fact with insufficient
|data.
|
|The alternative seems to be to partition the recorded media independent
|of its clocking, and then associate the start time of the partition
with
|some metadata that is assumed to have happened at about the same time.
|But that doesn't necessarily work very well, especially for persistent
|recording.
|
|	Thanks,
|	Paul
|
|On 4/12/2011 5:38 AM, Parthasarathi R (partr) wrote:
|> Muthu,
|>
|> I agree with you that till now there is no strong usecase for SRS to
|> have the timestamp information about media (RTP/RTCP) packets.
|>
|> I added further and mentioned even if somebody looks for it, the
|> timestamp information about media packet is not possible to be
achieved
|> in all architecture without delay/latency.
|>
|> Thanks
|> Partha
|>
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal)
|> Sent: Tuesday, April 12, 2011 1:17 PM
|> To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat);
'Leon
|> Portman'
|> Cc: [email-masked]'
|> Subject: RE: [siprec] start/stop times&  the metamodel
|>
|> |In case AS&  MS are two different physical devices, it is highly
tough
|> |to sync CS RTP timestamp with RS metadata timestamp because the
delay
|> |between AS&  MS communication for RTP timestamp has to be
considered.
|>
|> As Paul mentioned before, the delay/latency b/w call signaling and
media
|> is what it is -- I don't see it as a problem as well. The question is
|> whether there is need to correlate the time of occurrence of events
|> conveyed through call signaling with the transmission/reception time
of
|> media packets when those events occurred -- I don't see why the
SRC/SRS
|> would find that useful, yet.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: Parthasarathi R (partr)
|> |Sent: Tuesday, April 12, 2011 12:11 PM
|> |To: Muthu ArulMozhi Perumal (mperumal); Henry Lum; Paul Kyzivat
|> |(pkyzivat); Leon Portman
|> |Cc: [email-masked]
|> |Subject: RE: [siprec] start/stop times&  the metamodel
|> |
|> |This is one of the usecase wherein I'm interested in SRC
architecture
|> |with Application server (AS)&  Media server (MS) as a different
logical
|>
|> |entity. In case AS&  MS are two different physical devices, it is
|> |highly tough to sync CS RTP timestamp with RS metadata timestamp
|> |because the delay between AS&  MS communication for RTP timestamp
has
|> to be considered. IMO, AS has to aware of the change in the signaling
|> plane and inform in RS metadata with timestamp rather than depend
upon
|> media (RTP).
|> |
|> |Thanks
|> |Partha
|> |
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> |Behalf Of Muthu ArulMozhi Perumal
|> |(mperumal)
|> |Sent: Tuesday, April 12, 2011 8:15 AM
|> |To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
|> |Cc: [email-masked]
|> |Subject: Re: [siprec] start/stop times&  the metamodel
|> |
|> |While I see it may be useful for the SRS to know when certain things
|> |happened in CS signaling (participant joining, leaving, going mute
etc)
|>
|> |I don't see how useful it would be for it know how those things are
|> |related to when the participant actually sent/received (or stopped
|> |sending/receiving) RTP.
|> |
|> |If we see any use, one way to do it is using the NTP timestamp
carried
|> |in RTCP SR reports, provided the SRC, SRS and the participants have
|> access to the same reference wallclock.
|> |
|> |Muthu
|> |
|> ||-----Original Message-----
|> ||From: [email-masked] [mailto:[email-masked]] On
|> |Behalf Of Henry Lum
|> ||Sent: Tuesday, April 12, 2011 2:56 AM
|> ||To: Paul Kyzivat (pkyzivat); Leon Portman
|> ||Cc: [email-masked]
|> ||Subject: Re: [siprec] start/stop times&  the metamodel
|> ||
|> ||A related question on the RTP model is that if the SRC as an RTP
|> ||translator chooses to relay the RTP timestamps, then how would the
SRC
|>
|> ||synchronize the timestamps between the SIP messages the multiple
RTP
|> ||streams?
|> ||
|> ||Henry
|> ||
|> ||>  -----Original Message-----
|> ||>  From: [email-masked] [mailto:[email-masked]]
On
|> ||>  Behalf Of Paul Kyzivat
|> ||>  Sent: Monday, April 11, 2011 1:06 PM
|> ||>  To: Leon Portman
|> ||>  Cc: [email-masked]
|> ||>  Subject: Re: [siprec] start/stop times&  the metamodel
|> ||>
|> ||>
|> ||>
|> ||>  On 4/11/2011 9:36 AM, Leon Portman wrote:
|> ||>  >  Paul Hi
|> ||>  >
|> ||>  >  I agree with proposed method of time stamping metadata
elements
|> |with
|> ||>  SRC clock (it is like a wall clock from the requirement
document).
|> ||>  >  About RTP time synchronization to metadata events, we either
|> ||>  >  should
|> ||>  have some low latency event from SRC to SRS with SRC time that
will
|> ||>  allow SRS to maintain time difference between its clock and SRC
|> ||>  clock and then apply it also to receive time of RTP packet
(assuming
|>
|> ||>  no
|> ||>  buffering)
|> ||>
|> ||>  ISTM the issue isn't the latency of the event - it is what it is
-
|> |but
|> ||>  rather how to correlate a sip message containing metadata with a
|> ||>  particular RTP packet. I suspect that needs to be tied into the
|> ||>  discussion of the various models for how the SRC might handle
RDP.
|> ||>
|> ||>  	Thanks,
|> ||>  	Paul
|> ||>
|> ||>  >  Leon
|> ||>  >
|> ||>  >  -----Original Message-----
|> ||>  >  From: [email-masked]
[mailto:[email-masked]] On
|> ||>  Behalf Of Paul Kyzivat
|> ||>  >  Sent: Monday, April 11, 2011 4:03 PM
|> ||>  >  To: Elwell, John
|> ||>  >  Cc: [email-masked]
|> ||>  >  Subject: Re: [siprec] start/stop times&   the metamodel
|> ||>  >
|> ||>  >
|> ||>  >
|> ||>  >  On 4/8/2011 11:53 AM, Elwell, John wrote:
|> ||>  >>  Paul,
|> ||>  >>
|> ||>  >>  I think much of what you say makes sense. I was concerned
that we
|> ||>  probably need to record when a participant stops or starts
sending
|> ||>  or receiving a stream, which seems to be covered by your
statement:
|> ||>  "Changes to media streams should similarly be tagged with the
time
|> ||they
|> ||>  occurred in the CS signaling. Each participant relationship
change
|> ||>  (send, receive, inactive,) will be there." That doesn't seem to
be
|> ||>  in the model at present.
|> ||>  >
|> ||>  >  John,
|> ||>  >
|> ||>  >  I agree the current model doesn't reflect this - it was a
private
|> ||>  thought by me, provoked by the work and discussion to date. It
is a
|> ||bit
|> ||>  of a change of direction, so I'm interested in what others think
|> |about
|> ||>  it.
|> ||>  >
|> ||>  >  	Thanks,
|> ||>  >  	Paul
|> ||>  >
|> ||>  >>  John (as individual)
|> ||>  >>
|> ||>  >>
|> ||>  >>>  -----Original Message-----
|> ||>  >>>  From: [email-masked]
|> ||>  >>>  [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> ||>  >>>  Sent: 06 April 2011 22:28
|> ||>  >>>  To: [email-masked]
|> ||>  >>>  Subject: [siprec] start/stop times&    the metamodel
|> ||>  >>>
|> ||>  >>>  In Prague, one of the open issues was around start/stop
times.
|> |The
|> ||>  >>>  format draft floated the possibility of having explicit
|> |start/stop
|> ||>  >>>  times signaled for each of the metatdata elements. But then
we
|> ||>  asked
|> ||>  >>>  for feedback on which make sense.
|> ||>  >>>
|> ||>  >>>  IMO explicit start/stop times make more sense for some
things
|> |than
|> ||>  >>>  others.
|> ||>  >>>
|> ||>  >>>  One place where we potentially have explicit times to
report
|> ||>  >>>  with
|> ||>  the
|> ||>  >>>  dialogs that constitute a CS. Each such dialog presumably
has a
|> ||>  start
|> ||>  >>>  and stop time observable by the SRC, which might differ, at
|> ||>  >>>  least
|> ||a
|> ||>  >>>  bit, from the corresponding signaling on the RS.
|> ||>  >>>
|> ||>  >>>  We might want to report those times. Or, since we abstract
the
|> ||>  >>>  CS away from the dialog, we might want to report the start
time
|> ||>  >>>  of
|> ||the
|> ||>  >>>  first dialog in the CS as the CS start time, and the stop
time
|> ||>  >>>  of
|> ||>  the
|> ||>  >>>  last dialog in the CS as the CS stop time.
|> ||>  >>>
|> ||>  >>>  Similarly, we have abstracted media streams away from the
media
|> ||>  >>>  streams in the sip dialogs that make up the CS. We might
want to
|>
|> ||>  >>>  report the start time of a media stream as the time
(according
|> ||>  >>>  to
|> ||>  the
|> ||>  >>>  CS) of the first participant to a new media stream, and the
stop
|> ||>  time
|> ||>  >>>  as the time that the last participant leaves the media
stream.
|> ||>  >>>
|> ||>  >>>  There are several things that complicate this:
|> ||>  >>>
|> ||>  >>>  - Do we consider the case of a stream that starts with
recvonly
|> ||>  >>>       or inactive participants, and only later gets a
sender? If
|> ||so,
|> ||>  >>>       is the start time of the stream when the first
participant
|> ||>  arrived,
|> ||>  >>>       or when the first sender arrived?
|> ||>  >>>
|> ||>  >>>  - How do we get the clock times for the media streams?
|> ||>  >>>       IIUC the correct ones are in the RTP/RTCP, but the
|> ||>  >>>  reporting
|> ||>  of
|> ||>  >>>       these events is driven by the signaling, and we don't
have
|> ||>  good
|> ||>  >>>       sync between those. (E.g. media could start flowing
before
|> ||the
|> ||>  >>>       corresponding signaling, and we would like to include
that
|> |if
|> ||>  we
|> ||>  >>>       can figure it out.) So, even if the clocks used for
media
|> |and
|> ||>  >>>       signaling are in sync, we might see media packets
arrive
|> |with
|> ||>  >>>       a timestamp prior to the timestamp for the signaling
that
|> ||>  >>>       indicates the send state of the participant. This
could
|> |cause
|> ||>  >>>       trouble in playback.
|> ||>  >>>
|> ||>  >>>  - There isn't any guarantee that the clock used for
signaling
|> ||>  >>>       messages is synchronized with the clock used in
RTP/RTCP.
|> ||>  >>>
|> ||>  >>>  - There isn't any guarantee that there will be any RTCP at
all,
|> ||>  >>>       to provide correlation of the RTP to clocktime.
|> ||>  >>>
|> ||>  >>>  The best I can see to deal with all of this is:
|> ||>  >>>
|> ||>  >>>  - All the metadata messages should be timestamped by the
SRC
|> ||>  >>>       using its local clock. This is easily achieved by the
Date
|> ||>  >>>       header in the sip message.
|> ||>  >>>
|> ||>  >>>  - Changes to a CS, including changes of participants,
should
|> ||>  >>>       be explicitly tagged with the time they occurred in
the
|> ||>  >>>       CS signaling, according to the SRC's clock. (If that
is
|> ||>  >>>       unavailable for some reason, then use the time the SRC
|> ||>  >>>       became aware of it.)
|> ||>  >>>
|> ||>  >>>  - We could provide a metadata update element to indicate
end
|> ||>  >>>       of a CS, but I suggest this just be shorthand for
|> indicating
|> ||>  >>>       removal of all participants from it. (While its
possible to
|> ||>  >>>       mark that the CS is truly ended, that simply
introduces an
|> ||>  >>>       error case if added metadata about it is subsequently
|> sent.)
|> ||>  >>>       The actual start/stop time would be determined by the
SRS
|> ||>  >>>       based on the timestamps of first and last data about
it.
|> ||>  >>>
|> ||>  >>>  - Changes to media streams should similarly be tagged with
|> ||>  >>>       the time they occurred in the CS signaling. Each
|> participant
|> ||>  >>>       relationship change (send, receive, inactive,) will be
|> |there.
|> ||>  >>>       The actual start/stop time of the media stream again
would
|> |be
|> ||>  >>>       derived by the SRS.
|> ||>  >>>
|> ||>  >>>  - CS-Groups can simply be tagged by the timestamps of the
|> ||>  >>>       updates that put CSs into them. Explicit start/stop
times
|> ||>  don't
|> ||>  >>>       seem useful. If desired, the SRS can derive start/stop
|> times
|> ||>  >>>       from the start/stop times of the contained stuff.
|> ||>  >>>
|> ||>  >>>  - I now think that CS-Groups should not be "contained"
within
|> ||>  >>>       a recording. This just seems to introduce unnecessary
error
|> ||>  >>>       conditions, and limitations on future enhancements.
The
|> ||>  >>>       lifetime of CS-Groups will probably be naturally
limited by
|> ||>  >>>       the ability of the SRC to remember the IDs of old
ones.
|> ||>  >>>       For instance, if a CS-G is created during one
Recording,
|> ||>  >>>       and then another CS is added to it from a different
|> |recording
|> ||>  >>>       session, would we prefer to fail that, or just allow
it?
|> ||>  >>>       (I think allow.)
|> ||>  >>>
|> ||>  >>>  - Rather, I think every update transmitted during a
recording
|> ||>  >>>       session can be tagged with a link to the metadata of
the
|> ||>  >>>       recording session it came from. This need not be
explicit -
|> ||>  the
|> ||>  >>>       SRS can do it automatically. The recording session
entity
|> ||>  >>>       itself will also have a start/stop time which is the
start/
|> ||>  >>>       stop of the RS dialog as observed by the SRS.
|> ||>  >>>
|> ||>  >>>  (Note the above doesn't solve the problem of getting
correct
|> |clock
|> ||>  >>>  times for RTP media. If anyone has a suggestion for this
I'm all
|> ||>  >>>  ears.)
|> ||>  >>>
|> ||>  >>>  	Thanks,
|> ||>  >>>  	Paul
|> ||>  >>>  _______________________________________________
|> ||>  >>>  siprec mailing list
|> ||>  >>>  [email-masked]
|> ||>  >>>  https://www.ietf.org/mailman/listinfo/siprec
|> ||>  >>>
|> ||>  >  _______________________________________________
|> ||>  >  siprec mailing list
|> ||>  >  [email-masked]
|> ||>  >  https://www.ietf.org/mailman/listinfo/siprec
|> ||>  >
|> ||>  _______________________________________________
|> ||>  siprec mailing list
|> ||>  [email-masked]
|> ||>  https://www.ietf.org/mailman/listinfo/siprec
|> ||
|> ||
|>
||----------------------------------------------------------------------
|> ||-
|> |-------------------------------
|> ||-------------
|> ||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.
|> ||
|> ||_______________________________________________
|> ||siprec mailing list
|> [email-masked]
|> ||https://www.ietf.org/mailman/listinfo/siprec
|> |_______________________________________________
|> |siprec mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/siprec
|>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Apr 2011 12:14:35 +0530

Agree, instead of banking on just one model, we need to consider various
aspects of the common ones we anticipate, to enable useful
interpretation of the recorded data.

Muthu

|-----Original Message-----
|From: Henry Lum [mailto:[email-masked]]
|Sent: Wednesday, April 13, 2011 2:43 AM
|To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon
Portman
|Cc: [email-masked]
|Subject: RE: [siprec] start/stop times & the metamodel
|
|I don't think it is guaranteed that participants will send SR reports
|(or any RTCP), plus we will also have to assume that the NTP timestamps
|are in sync. We could mandate the SRC to generate SR reports but then
we
|are fixing the RTP model for the SRC.
|
|Regards,
|Henry
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Monday, April 11, 2011 10:45 PM
|> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
|> Cc: [email-masked]
|> Subject: RE: [siprec] start/stop times & the metamodel
|>
|> While I see it may be useful for the SRS to know when certain things
|> happened in CS signaling (participant joining, leaving, going mute
|etc)
|> I don't see how useful it would be for it know how those things are
|> related to when the participant actually sent/received (or stopped
|> sending/receiving) RTP.
|>
|> If we see any use, one way to do it is using the NTP timestamp
carried
|> in RTCP SR reports, provided the SRC, SRS and the participants have
|> access to the same reference wallclock.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Henry Lum
|> |Sent: Tuesday, April 12, 2011 2:56 AM
|> |To: Paul Kyzivat (pkyzivat); Leon Portman
|> |Cc: [email-masked]
|> |Subject: Re: [siprec] start/stop times & the metamodel
|> |
|> |A related question on the RTP model is that if the SRC as an RTP
|> |translator chooses to relay the RTP timestamps, then how would the
|SRC
|> |synchronize the timestamps between the SIP messages the multiple RTP
|> |streams?
|> |
|> |Henry
|> |
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]] On
|> |> Behalf Of Paul Kyzivat
|> |> Sent: Monday, April 11, 2011 1:06 PM
|> |> To: Leon Portman
|> |> Cc: [email-masked]
|> |> Subject: Re: [siprec] start/stop times & the metamodel
|> |>
|> |>
|> |>
|> |> On 4/11/2011 9:36 AM, Leon Portman wrote:
|> |> > Paul Hi
|> |> >
|> |> > I agree with proposed method of time stamping metadata elements
|> with
|> |> SRC clock (it is like a wall clock from the requirement document).
|> |> > About RTP time synchronization to metadata events, we either
|> should
|> |> have some low latency event from SRC to SRS with SRC time that
will
|> |> allow SRS to maintain time difference between its clock and SRC
|> clock
|> |> and then apply it also to receive time of RTP packet (assuming no
|> |> buffering)
|> |>
|> |> ISTM the issue isn't the latency of the event - it is what it is -
|> but
|> |> rather how to correlate a sip message containing metadata with a
|> |> particular RTP packet. I suspect that needs to be tied into the
|> |> discussion of the various models for how the SRC might handle RDP.
|> |>
|> |> 	Thanks,
|> |> 	Paul
|> |>
|> |> > Leon
|> |> >
|> |> > -----Original Message-----
|> |> > From: [email-masked] [mailto:[email-masked]]
On
|> |> Behalf Of Paul Kyzivat
|> |> > Sent: Monday, April 11, 2011 4:03 PM
|> |> > To: Elwell, John
|> |> > Cc: [email-masked]
|> |> > Subject: Re: [siprec] start/stop times&  the metamodel
|> |> >
|> |> >
|> |> >
|> |> > On 4/8/2011 11:53 AM, Elwell, John wrote:
|> |> >> Paul,
|> |> >>
|> |> >> I think much of what you say makes sense. I was concerned that
|we
|> |> probably need to record when a participant stops or starts sending
|> or
|> |> receiving a stream, which seems to be covered by your statement:
|> |> "Changes to media streams should similarly be tagged with the time
|> |they
|> |> occurred in the CS signaling. Each participant relationship change
|> |> (send, receive, inactive,) will be there." That doesn't seem to be
|> in
|> |> the model at present.
|> |> >
|> |> > John,
|> |> >
|> |> > I agree the current model doesn't reflect this - it was a
private
|> |> thought by me, provoked by the work and discussion to date. It is
a
|> |bit
|> |> of a change of direction, so I'm interested in what others think
|> about
|> |> it.
|> |> >
|> |> > 	Thanks,
|> |> > 	Paul
|> |> >
|> |> >> John (as individual)
|> |> >>
|> |> >>
|> |> >>> -----Original Message-----
|> |> >>> From: [email-masked]
|> |> >>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> |> >>> Sent: 06 April 2011 22:28
|> |> >>> To: [email-masked]
|> |> >>> Subject: [siprec] start/stop times&   the metamodel
|> |> >>>
|> |> >>> In Prague, one of the open issues was around start/stop times.
|> The
|> |> >>> format draft floated the possibility of having explicit
|> start/stop
|> |> >>> times signaled for each of the metatdata elements. But then we
|> |> asked
|> |> >>> for feedback on which make sense.
|> |> >>>
|> |> >>> IMO explicit start/stop times make more sense for some things
|> than
|> |> >>> others.
|> |> >>>
|> |> >>> One place where we potentially have explicit times to report
|> with
|> |> the
|> |> >>> dialogs that constitute a CS. Each such dialog presumably has
a
|> |> start
|> |> >>> and stop time observable by the SRC, which might differ, at
|> least
|> |a
|> |> >>> bit, from the corresponding signaling on the RS.
|> |> >>>
|> |> >>> We might want to report those times. Or, since we abstract the
|> CS
|> |> >>> away from the dialog, we might want to report the start time
of
|> |the
|> |> >>> first dialog in the CS as the CS start time, and the stop time
|> of
|> |> the
|> |> >>> last dialog in the CS as the CS stop time.
|> |> >>>
|> |> >>> Similarly, we have abstracted media streams away from the
media
|> |> >>> streams in the sip dialogs that make up the CS. We might want
|to
|> |> >>> report the start time of a media stream as the time (according
|> to
|> |> the
|> |> >>> CS) of the first participant to a new media stream, and the
|stop
|> |> time
|> |> >>> as the time that the last participant leaves the media stream.
|> |> >>>
|> |> >>> There are several things that complicate this:
|> |> >>>
|> |> >>> - Do we consider the case of a stream that starts with
recvonly
|> |> >>>      or inactive participants, and only later gets a sender?
If
|> |so,
|> |> >>>      is the start time of the stream when the first
participant
|> |> arrived,
|> |> >>>      or when the first sender arrived?
|> |> >>>
|> |> >>> - How do we get the clock times for the media streams?
|> |> >>>      IIUC the correct ones are in the RTP/RTCP, but the
|> reporting
|> |> of
|> |> >>>      these events is driven by the signaling, and we don't
have
|> |> good
|> |> >>>      sync between those. (E.g. media could start flowing
before
|> |the
|> |> >>>      corresponding signaling, and we would like to include
that
|> if
|> |> we
|> |> >>>      can figure it out.) So, even if the clocks used for media
|> and
|> |> >>>      signaling are in sync, we might see media packets arrive
|> with
|> |> >>>      a timestamp prior to the timestamp for the signaling that
|> |> >>>      indicates the send state of the participant. This could
|> cause
|> |> >>>      trouble in playback.
|> |> >>>
|> |> >>> - There isn't any guarantee that the clock used for signaling
|> |> >>>      messages is synchronized with the clock used in RTP/RTCP.
|> |> >>>
|> |> >>> - There isn't any guarantee that there will be any RTCP at
all,
|> |> >>>      to provide correlation of the RTP to clocktime.
|> |> >>>
|> |> >>> The best I can see to deal with all of this is:
|> |> >>>
|> |> >>> - All the metadata messages should be timestamped by the SRC
|> |> >>>      using its local clock. This is easily achieved by the
Date
|> |> >>>      header in the sip message.
|> |> >>>
|> |> >>> - Changes to a CS, including changes of participants, should
|> |> >>>      be explicitly tagged with the time they occurred in the
|> |> >>>      CS signaling, according to the SRC's clock. (If that is
|> |> >>>      unavailable for some reason, then use the time the SRC
|> |> >>>      became aware of it.)
|> |> >>>
|> |> >>> - We could provide a metadata update element to indicate end
|> |> >>>      of a CS, but I suggest this just be shorthand for
|> indicating
|> |> >>>      removal of all participants from it. (While its possible
|to
|> |> >>>      mark that the CS is truly ended, that simply introduces
an
|> |> >>>      error case if added metadata about it is subsequently
|> sent.)
|> |> >>>      The actual start/stop time would be determined by the SRS
|> |> >>>      based on the timestamps of first and last data about it.
|> |> >>>
|> |> >>> - Changes to media streams should similarly be tagged with
|> |> >>>      the time they occurred in the CS signaling. Each
|> participant
|> |> >>>      relationship change (send, receive, inactive,) will be
|> there.
|> |> >>>      The actual start/stop time of the media stream again
would
|> be
|> |> >>>      derived by the SRS.
|> |> >>>
|> |> >>> - CS-Groups can simply be tagged by the timestamps of the
|> |> >>>      updates that put CSs into them. Explicit start/stop times
|> |> don't
|> |> >>>      seem useful. If desired, the SRS can derive start/stop
|> times
|> |> >>>      from the start/stop times of the contained stuff.
|> |> >>>
|> |> >>> - I now think that CS-Groups should not be "contained" within
|> |> >>>      a recording. This just seems to introduce unnecessary
|error
|> |> >>>      conditions, and limitations on future enhancements. The
|> |> >>>      lifetime of CS-Groups will probably be naturally limited
|by
|> |> >>>      the ability of the SRC to remember the IDs of old ones.
|> |> >>>      For instance, if a CS-G is created during one Recording,
|> |> >>>      and then another CS is added to it from a different
|> recording
|> |> >>>      session, would we prefer to fail that, or just allow it?
|> |> >>>      (I think allow.)
|> |> >>>
|> |> >>> - Rather, I think every update transmitted during a recording
|> |> >>>      session can be tagged with a link to the metadata of the
|> |> >>>      recording session it came from. This need not be explicit
|-
|> |> the
|> |> >>>      SRS can do it automatically. The recording session entity
|> |> >>>      itself will also have a start/stop time which is the
|start/
|> |> >>>      stop of the RS dialog as observed by the SRS.
|> |> >>>
|> |> >>> (Note the above doesn't solve the problem of getting correct
|> clock
|> |> >>> times for RTP media. If anyone has a suggestion for this I'm
|all
|> |> >>> ears.)
|> |> >>>
|> |> >>> 	Thanks,
|> |> >>> 	Paul
|> |> >>> _______________________________________________
|> |> >>> siprec mailing list
|> |> >>> [email-masked]
|> |> >>> https://www.ietf.org/mailman/listinfo/siprec
|> |> >>>
|> |> > _______________________________________________
|> |> > siprec mailing list
|> |> > [email-masked]
|> |> > https://www.ietf.org/mailman/listinfo/siprec
|> |> >
|> |> _______________________________________________
|> |> siprec mailing list
|> |> [email-masked]
|> |> https://www.ietf.org/mailman/listinfo/siprec
|> |
|> |
|>
||----------------------------------------------------------------------
|> -
|> -------------------------------
|> |-------------
|> |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.
|> |
|> |_______________________________________________
|> |siprec mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/siprec
|
|
|-----------------------------------------------------------------------
-------------------------------
|-------------
|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: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Apr 2011 12:35:31 +0530

After the use-case Paul described, it seem to me that if we keep out of
scope it will put a lot of burden on the SRS to support synchronized
querying/playback which looks an important aspect for media recording.
So, we may want to consider the ways in which the SRC can facilitate it.

Muthu

|Sent: Wednesday, April 13, 2011 11:20 AM
|To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat
|Henry,
|I attached the follow up mail to below mail thread. Till now, We don't
have strong requirement to
|solve in SIPREC. Let us identify the requirement before going to the
solution.
(or any RTCP), plus we will also
|have to assume that the NTP timestamps are in sync. We could mandate
the SRC to generate SR reports
|but then we are fixing the RTP model for the SRC.

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Apr 2011 12:55:28 +0530

|If we are ok to abstract the details and indicate 
|starting/stopping sending/receiving a media stream,
|the current model already does it. Do you see a need 
|to have anything else in the model to accommodate this ?

What is supported currently looks good to me. However, I am thinking if
we could carry both the wallclock time and the RTP timestamp in the
metadata's media stream object if the later is available to the SRC when
this object is generated. This can avoid having to generate RTCP for
this purpose alone.

Muthu

|-----Original Message-----
|From: Ram Mohan R (rmohanr)
|Sent: Tuesday, April 12, 2011 3:23 PM
|To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat
(pkyzivat)
|Cc: [email-masked]
|Subject: RE: [siprec] start/stop times & the metamodel
|
|Hi John,
|
|Inline
|
|> -----Original Message-----
|> From: Elwell, John [mailto:[email-masked]]
|> Sent: Tuesday, April 12, 2011 3:12 PM
|> To: Muthu ArulMozhi Perumal (mperumal); Ram Mohan R (rmohanr); Paul
|> Kyzivat (pkyzivat)
|> Cc: [email-masked]
|> Subject: RE: [siprec] start/stop times & the metamodel
|>
|> I think the indication in the metadata can be constructed by the SRC
|> based on information it sends or receives in CS SDP, but this does
not
|> necessarily mean that it should be conveyed in RS SDP - it should be
|> conveyed in XML. So I agree with Muthu.
|>
|> Note that starting to send a particular Media Stream can be a result
of
|> various changes in CS SDP, e.g:
|> - addition of an m-line;
|> - changing m-line port from zero to non-zero;
|> - changing from inactive to sendrecv;
|> - changing from recvonly to sendrecv;
|> - changing from inactive to sendonly.
|>
|> Similarly starting to receive, ceasing to send and ceasing to receive
|> can all arise from a number of different changes to CS SDP.
|>
|> The SRS should not need to understand all the details of CS SDP
|> changes, but should just be given an abstraction, i.e., it should be
|> told that a given participant is starting/stopping sending/receiving
a
|> media stream, in line with the metadata model.
|
|If we are ok to abstract the details and indicate starting/stopping
sending/receiving a media stream,
|the current model already does it. Do you see a need to have anything
else in the model to accommodate
|this ?
|
|Ram
|
|>
|> John (as individual)
|>
|> > -----Original Message-----
|> > From: Muthu ArulMozhi Perumal (mperumal)
[mailto:[email-masked]]
|> > Sent: 12 April 2011 10:20
|> > To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
|> > Cc: [email-masked]
|> > Subject: RE: [siprec] start/stop times & the metamodel
|> >
|> > |SRC to SRS indication of participant hold/resume can
|> > |happen through updates in RS SIP dialog. What I am
|> > |asking here is if there is a need to report the original
|> > |CS SDP media params (say direction attribute) explicitly
|> > |in the metadata to RS.
|> >
|> > The SRC might have its own policy of when (and when not) to pause
the
|> > recording, which it can achieve through the RS dialog. The SRS on
the
|> > other hand might also have policies on when (and when not) to
record
|> > based on the participants media state. So, I see it might be useful
|> to
|> > convey this information in metadata if the SRS wants to take
|> decisions
|> > independent of the SRC. Also, since only metadata is
|> > persistent, making
|> > it available in metadata might be handy for the SRS, for future
|> > interpretation.
|> >
|> > Muthu
|> >
|> > |-----Original Message-----
|> > |From: Ram Mohan R (rmohanr)
|> > |Sent: Tuesday, April 12, 2011 2:17 PM
|> > |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat);
|> > 'Elwell, John'
|> > |Cc: [email-masked]'
|> > |Subject: RE: [siprec] start/stop times & the metamodel
|> > |
|> > |Inline
|> > |
|> > |> -----Original Message-----
|> > |> From: Muthu ArulMozhi Perumal (mperumal)
|> > |> Sent: Tuesday, April 12, 2011 1:51 PM
|> > |> To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat); Elwell, John
|> > |> Cc: [email-masked]
|> > |> Subject: RE: [siprec] start/stop times & the metamodel
|> > |>
|> > |> |I agree on sending information of when a participant start/stop
|> > |> |sending media [ from SRC perspective - what SRC sees] in the
|> > |> |metadata. Do we  really need reporting Changes to the media
|> > |> |streams of CS like send, receive, inactive ?
|> > |>
|> > |> Aren't they related? If a participant goes recvonly or
|> > inactive it is
|> > |> an indication that he isn't going to send anything, so SRS
|> > might want
|> > |> to know this in order to pause recording the media stream
|> > coming from
|> > |> that participant and save some disk space -- might be useful in
|> > |> environment where occasional small clips in the recorded
|> > stream isn't
|> > a
|> > |> problem. An alternative is for the SRC to run media
|> > activity/inactivity
|> > |> detection and report it to the SRS (which can also suffer
|> > from media
|> > |> clipping). However, not every SRC might be capable of doing
this.
|> > |
|> > |SRC to SRS indication of participant hold/resume can happen
through
|> > updates in RS SIP dialog. What I
|> > |am asking here is if there is a need to report the original CS SDP
|> > media params (say direction
|> > |attribute) explicitly in the metadata to RS.
|> > |
|> > |Ram
|> > |
|> > |>
|> > |> Muthu
|> > |>
|> > |> |-----Original Message-----
|> > |> |From: [email-masked] [mailto:[email-masked]]
On
|> > |> Behalf Of Ram Mohan R (rmohanr)
|> > |> |Sent: Tuesday, April 12, 2011 1:17 PM
|> > |> |To: Paul Kyzivat (pkyzivat); Elwell, John
|> > |> |Cc: [email-masked]
|> > |> |Subject: Re: [siprec] start/stop times & the metamodel
|> > |> |
|> > |> |Inline
|> > |> |A comment on this mail
|> > |> |
|> > |> |
|> > |> |> -----Original Message-----
|> > |> |> From: [email-masked]
|> > [mailto:[email-masked]] On
|> > |> |> Behalf Of Paul Kyzivat (pkyzivat)
|> > |> |> Sent: Monday, April 11, 2011 6:33 PM
|> > |> |> To: Elwell, John
|> > |> |> Cc: [email-masked]
|> > |> |> Subject: Re: [siprec] start/stop times & the metamodel
|> > |> |>
|> > |> |>
|> > |> |>
|> > |> |> On 4/8/2011 11:53 AM, Elwell, John wrote:
|> > |> |> > Paul,
|> > |> |> >
|> > |> |> > I think much of what you say makes sense. I was concerned
|> that
|> > we
|> > |> |> probably need to record when a participant stops or
|> > starts sending
|> > |> or
|> > |> |> receiving a stream, which seems to be covered by your
|> statement:
|> > |> |> "Changes to media streams should similarly be tagged
|> > with the time
|> > |> |they
|> > |> |> occurred in the CS signaling. Each participant
|> > relationship change
|> > |> |> (send, receive, inactive,) will be there." That doesn't
|> > seem to be
|> > |> in
|> > |> |> the model at present.
|> > |> |
|> > |> |I agree on sending information of when a participant start/stop
|> > |> sending
|> > |> |media [ from SRC perspective - what SRC sees] in the
|> > metadata. Do we
|> > |> |really need reporting Changes to the media streams of CS
|> > like send,
|> > |> |receive, inactive ? This would again go back to sending
|> > portions of
|> > CS
|> > |> |SDP [ in this case direction attribute] in metadata.
|> > |> |
|> > |> |Ram
|> > |> |
|> > |> |>
|> > |> |> John,
|> > |> |>
|> > |> |> I agree the current model doesn't reflect this - it was
|> > a private
|> > |> |> thought by me, provoked by the work and discussion to
|> > date. It is
|> > a
|> > |> |bit
|> > |> |> of a change of direction, so I'm interested in what others
|> think
|> > |> about
|> > |> |> it.
|> > |> |>
|> > |> |> 	Thanks,
|> > |> |> 	Paul
|> > |> |>
|> > |> |> > John (as individual)
|> > |> |> >
|> > |> |> >
|> > |> |> >> -----Original Message-----
|> > |> |> >> From: [email-masked]
|> > |> |> >> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> > |> |> >> Sent: 06 April 2011 22:28
|> > |> |> >> To: [email-masked]
|> > |> |> >> Subject: [siprec] start/stop times&  the metamodel
|> > |> |> >>
|> > |> |> >> In Prague, one of the open issues was around
|> > start/stop times.
|> > |> The
|> > |> |> >> format draft floated the possibility of having explicit
|> > |> |> >> start/stop times
|> > |> |> >> signaled for each of the metatdata elements. But
|> > then we asked
|> > |> for
|> > |> |> >> feedback on which make sense.
|> > |> |> >>
|> > |> |> >> IMO explicit start/stop times make more sense for some
|> things
|> > |> |> >> than others.
|> > |> |> >>
|> > |> |> >> One place where we potentially have explicit times to
report
|> > with
|> > |> |> the
|> > |> |> >> dialogs that constitute a CS. Each such dialog
|> > presumably has a
|> > |> |> start
|> > |> |> >> and stop time observable by the SRC, which might differ,
at
|> > |> |> >> least a bit,
|> > |> |> >> from the corresponding signaling on the RS.
|> > |> |> >>
|> > |> |> >> We might want to report those times. Or, since we abstract
|> > |> |> >> the CS away
|> > |> |> >> from the dialog, we might want to report the start
|> > time of the
|> > |> |first
|> > |> |> >> dialog in the CS as the CS start time, and the stop
|> > time of the
|> > |> |last
|> > |> |> >> dialog in the CS as the CS stop time.
|> > |> |> >>
|> > |> |> >> Similarly, we have abstracted media streams away from the
|> > |> |> >> media streams
|> > |> |> >> in the sip dialogs that make up the CS. We might
|> > want to report
|> > |> the
|> > |> |> >> start time of a media stream as the time (according
|> > to the CS)
|> > of
|> > |> |> the
|> > |> |> >> first participant to a new media stream, and the stop time
|> as
|> > |> |> >> the time
|> > |> |> >> that the last participant leaves the media stream.
|> > |> |> >>
|> > |> |> >> There are several things that complicate this:
|> > |> |> >>
|> > |> |> >> - Do we consider the case of a stream that starts
|> > with recvonly
|> > |> |> >>     or inactive participants, and only later gets a
|> > sender? If
|> > |> so,
|> > |> |> >>     is the start time of the stream when the first
|> > participant
|> > |> |> arrived,
|> > |> |> >>     or when the first sender arrived?
|> > |> |> >>
|> > |> |> >> - How do we get the clock times for the media streams?
|> > |> |> >>     IIUC the correct ones are in the RTP/RTCP, but the
|> > reporting
|> > |> of
|> > |> |> >>     these events is driven by the signaling, and we
|> > don't have
|> > |> good
|> > |> |> >>     sync between those. (E.g. media could start
|> > flowing before
|> > |> the
|> > |> |> >>     corresponding signaling, and we would like to
|> > include that
|> > if
|> > |> |we
|> > |> |> >>     can figure it out.) So, even if the clocks used for
|> media
|> > and
|> > |> |> >>     signaling are in sync, we might see media packets
arrive
|> > with
|> > |> |> >>     a timestamp prior to the timestamp for the signaling
|> that
|> > |> |> >>     indicates the send state of the participant. This
could
|> > cause
|> > |> |> >>     trouble in playback.
|> > |> |> >>
|> > |> |> >> - There isn't any guarantee that the clock used for
|> signaling
|> > |> |> >>     messages is synchronized with the clock used in
|> RTP/RTCP.
|> > |> |> >>
|> > |> |> >> - There isn't any guarantee that there will be any
|> > RTCP at all,
|> > |> |> >>     to provide correlation of the RTP to clocktime.
|> > |> |> >>
|> > |> |> >> The best I can see to deal with all of this is:
|> > |> |> >>
|> > |> |> >> - All the metadata messages should be timestamped by the
SRC
|> > |> |> >>     using its local clock. This is easily achieved
|> > by the Date
|> > |> |> >>     header in the sip message.
|> > |> |> >>
|> > |> |> >> - Changes to a CS, including changes of participants,
should
|> > |> |> >>     be explicitly tagged with the time they occurred in
the
|> > |> |> >>     CS signaling, according to the SRC's clock. (If that
is
|> > |> |> >>     unavailable for some reason, then use the time the SRC
|> > |> |> >>     became aware of it.)
|> > |> |> >>
|> > |> |> >> - We could provide a metadata update element to indicate
end
|> > |> |> >>     of a CS, but I suggest this just be shorthand for
|> > indicating
|> > |> |> >>     removal of all participants from it. (While its
|> > possible to
|> > |> |> >>     mark that the CS is truly ended, that simply
|> > introduces an
|> > |> |> >>     error case if added metadata about it is subsequently
|> > sent.)
|> > |> |> >>     The actual start/stop time would be determined by the
|> SRS
|> > |> |> >>     based on the timestamps of first and last data about
it.
|> > |> |> >>
|> > |> |> >> - Changes to media streams should similarly be tagged with
|> > |> |> >>     the time they occurred in the CS signaling. Each
|> > participant
|> > |> |> >>     relationship change (send, receive, inactive,) will be
|> > there.
|> > |> |> >>     The actual start/stop time of the media stream
|> > again would
|> > be
|> > |> |> >>     derived by the SRS.
|> > |> |> >>
|> > |> |> >> - CS-Groups can simply be tagged by the timestamps of the
|> > |> |> >>     updates that put CSs into them. Explicit start/stop
|> times
|> > |> don't
|> > |> |> >>     seem useful. If desired, the SRS can derive start/stop
|> > times
|> > |> |> >>     from the start/stop times of the contained stuff.
|> > |> |> >>
|> > |> |> >> - I now think that CS-Groups should not be "contained"
|> within
|> > |> |> >>     a recording. This just seems to introduce
|> > unnecessary error
|> > |> |> >>     conditions, and limitations on future enhancements.
The
|> > |> |> >>     lifetime of CS-Groups will probably be naturally
|> > limited by
|> > |> |> >>     the ability of the SRC to remember the IDs of old
ones.
|> > |> |> >>     For instance, if a CS-G is created during one
Recording,
|> > |> |> >>     and then another CS is added to it from a different
|> > recording
|> > |> |> >>     session, would we prefer to fail that, or just allow
it?
|> > |> |> >>     (I think allow.)
|> > |> |> >>
|> > |> |> >> - Rather, I think every update transmitted during a
|> recording
|> > |> |> >>     session can be tagged with a link to the metadata of
the
|> > |> |> >>     recording session it came from. This need not be
|> > explicit -
|> > |> the
|> > |> |> >>     SRS can do it automatically. The recording session
|> entity
|> > |> |> >>     itself will also have a start/stop time which is
|> > the start/
|> > |> |> >>     stop of the RS dialog as observed by the SRS.
|> > |> |> >>
|> > |> |> >> (Note the above doesn't solve the problem of getting
correct
|> > |> |> >> clock times
|> > |> |> >> for RTP media. If anyone has a suggestion for this I'm all
|> > ears.)
|> > |> |> >>
|> > |> |> >> 	Thanks,
|> > |> |> >> 	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 13 Apr 2011 14:46:05 +0530

ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP
translator) in case these requirement has to be considered within
SIPREC. IMO, these requirement has to be mentioned in SIPREC requirement
document to define the exact role what SRC does with media timestamp and
what SRS does with media timestamp?

Thanks
Partha 

-----Original Message-----
From: Muthu ArulMozhi Perumal (mperumal) 
Sent: Wednesday, April 13, 2011 12:36 PM
To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon
Portman'
Cc: [email-masked]'

Muthu

|have strong requirement to solve in SIPREC. Let us identify the
|Portman

we are fixing the RTP model for the SRC.
|> carried in RTCP SR reports, provided the SRC, SRS and the 
|> participants have access to the same reference wallclock.

|> |streams?
|> |
|> |Henry
|> |
|> |> will allow SRS to maintain time difference between its clock and 
|> |> SRC
|> |> > On

|> |> > private
|> |> a
|> |> >>> a
|> |> >>> of
|> |> >>> media streams in the sip dialogs that make up the CS. We might

|> |> >>> want
|to
|> |> >>> If
|> |> >>> participant
|> |> >>> have
|> |> >>> before
|> |> >>> that
|> |> >>> would
|confidential and proprietary information of Alcatel-Lucent and/or its 
|affiliated entities. Access by the intended recipient only is 
|from acting, on any information contained in this e-mail is hereby 
|excluded. If you are not the intended recipient, please notify the

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Apr 2011 16:06:41 +0530

I don't think the requirements need to go to the level of RTP timestamp.
But it may be useful to add a requirement that the SRC needs to
facilitate synchronized querying/playback of the recorded media streams
and metadata. I couldn't derive that directly from the requirements we
already have, but would like to hear from others if this is already
implied.

Muthu

|-----Original Message-----
|From: Parthasarathi R (partr)
|Sent: Wednesday, April 13, 2011 2:46 PM
|To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat
(pkyzivat); 'Leon Portman'
|Cc: [email-masked]'
|Subject: RE: [siprec] start/stop times & the metamodel
|
|ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP
translator) in case these requirement
|has to be considered within SIPREC. IMO, these requirement has to be
mentioned in SIPREC requirement
|document to define the exact role what SRC does with media timestamp
and what SRS does with media
|timestamp?
|
|Thanks
|Partha
|
|-----Original Message-----
|From: Muthu ArulMozhi Perumal (mperumal)
|Sent: Wednesday, April 13, 2011 12:36 PM
|To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat);
'Leon Portman'
|Cc: [email-masked]'
|Subject: RE: [siprec] start/stop times & the metamodel
|
|After the use-case Paul described, it seem to me that if we keep out of
scope it will put a lot of
|burden on the SRS to support synchronized querying/playback which looks
an important aspect for media
|recording. So, we may want to consider the ways in which the SRC can
facilitate it.
|
|Muthu
|
||-----Original Message-----
||From: Parthasarathi R (partr)
||Sent: Wednesday, April 13, 2011 11:20 AM
||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat
||(pkyzivat); Leon Portman
||Cc: [email-masked]
||Subject: RE: [siprec] start/stop times & the metamodel
||
||Henry,
||
||I attached the follow up mail to below mail thread. Till now, We don't
||have strong requirement to solve in SIPREC. Let us identify the
requirement before going to the
|solution.
||
||Thanks
||Partha
||
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] On
||Behalf Of Henry Lum
||Sent: Wednesday, April 13, 2011 2:43 AM
||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); Leon
||Portman
||Cc: [email-masked]
||Subject: Re: [siprec] start/stop times & the metamodel
||
||I don't think it is guaranteed that participants will send SR reports
||(or any RTCP), plus we will also have to assume that the NTP
timestamps
||are in sync. We could mandate the SRC to generate SR reports but then
we are fixing the RTP model for
|the SRC.
||
||Regards,
||Henry
||
||> -----Original Message-----
||> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
||> Sent: Monday, April 11, 2011 10:45 PM
||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
||> Cc: [email-masked]
||> Subject: RE: [siprec] start/stop times & the metamodel
||>
||> While I see it may be useful for the SRS to know when certain things
||> happened in CS signaling (participant joining, leaving, going mute
||etc)
||> I don't see how useful it would be for it know how those things are
||> related to when the participant actually sent/received (or stopped
||> sending/receiving) RTP.
||>
||> If we see any use, one way to do it is using the NTP timestamp
||> carried in RTCP SR reports, provided the SRC, SRS and the
||> participants have access to the same reference wallclock.
||>
||> Muthu
||>
||> |-----Original Message-----
||> |From: [email-masked] [mailto:[email-masked]] On
||> Behalf Of Henry Lum
||> |Sent: Tuesday, April 12, 2011 2:56 AM
||> |To: Paul Kyzivat (pkyzivat); Leon Portman
||> |Cc: [email-masked]
||> |Subject: Re: [siprec] start/stop times & the metamodel
||> |
||> |A related question on the RTP model is that if the SRC as an RTP
||> |translator chooses to relay the RTP timestamps, then how would the
||SRC
||> |synchronize the timestamps between the SIP messages the multiple
RTP
||> |streams?
||> |
||> |Henry
||> |
||> |> -----Original Message-----
||> |> From: [email-masked] [mailto:[email-masked]] On
||> |> Behalf Of Paul Kyzivat
||> |> Sent: Monday, April 11, 2011 1:06 PM
||> |> To: Leon Portman
||> |> Cc: [email-masked]
||> |> Subject: Re: [siprec] start/stop times & the metamodel
||> |>
||> |>
||> |>
||> |> On 4/11/2011 9:36 AM, Leon Portman wrote:
||> |> > Paul Hi
||> |> >
||> |> > I agree with proposed method of time stamping metadata elements
||> with
||> |> SRC clock (it is like a wall clock from the requirement
document).
||> |> > About RTP time synchronization to metadata events, we either
||> should
||> |> have some low latency event from SRC to SRS with SRC time that
||> |> will allow SRS to maintain time difference between its clock and
||> |> SRC
||> clock
||> |> and then apply it also to receive time of RTP packet (assuming no
||> |> buffering)
||> |>
||> |> ISTM the issue isn't the latency of the event - it is what it is
-
||> but
||> |> rather how to correlate a sip message containing metadata with a
||> |> particular RTP packet. I suspect that needs to be tied into the
||> |> discussion of the various models for how the SRC might handle
RDP.
||> |>
||> |> 	Thanks,
||> |> 	Paul
||> |>
||> |> > Leon
||> |> >
||> |> > -----Original Message-----
||> |> > From: [email-masked] [mailto:[email-masked]]
||> |> > On
||> |> Behalf Of Paul Kyzivat
||> |> > Sent: Monday, April 11, 2011 4:03 PM
||> |> > To: Elwell, John
||> |> > Cc: [email-masked]
||> |> > Subject: Re: [siprec] start/stop times&  the metamodel
||> |> >
||> |> >
||> |> >
||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote:
||> |> >> Paul,
||> |> >>
||> |> >> I think much of what you say makes sense. I was concerned that
||we
||> |> probably need to record when a participant stops or starts
sending
||> or
||> |> receiving a stream, which seems to be covered by your statement:
||> |> "Changes to media streams should similarly be tagged with the
time
||> |they
||> |> occurred in the CS signaling. Each participant relationship
change
||> |> (send, receive, inactive,) will be there." That doesn't seem to
be
||> in
||> |> the model at present.
||> |> >
||> |> > John,
||> |> >
||> |> > I agree the current model doesn't reflect this - it was a
||> |> > private
||> |> thought by me, provoked by the work and discussion to date. It is
||> |> a
||> |bit
||> |> of a change of direction, so I'm interested in what others think
||> about
||> |> it.
||> |> >
||> |> > 	Thanks,
||> |> > 	Paul
||> |> >
||> |> >> John (as individual)
||> |> >>
||> |> >>
||> |> >>> -----Original Message-----
||> |> >>> From: [email-masked]
||> |> >>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
||> |> >>> Sent: 06 April 2011 22:28
||> |> >>> To: [email-masked]
||> |> >>> Subject: [siprec] start/stop times&   the metamodel
||> |> >>>
||> |> >>> In Prague, one of the open issues was around start/stop
times.
||> The
||> |> >>> format draft floated the possibility of having explicit
||> start/stop
||> |> >>> times signaled for each of the metatdata elements. But then
we
||> |> asked
||> |> >>> for feedback on which make sense.
||> |> >>>
||> |> >>> IMO explicit start/stop times make more sense for some things
||> than
||> |> >>> others.
||> |> >>>
||> |> >>> One place where we potentially have explicit times to report
||> with
||> |> the
||> |> >>> dialogs that constitute a CS. Each such dialog presumably has
||> |> >>> a
||> |> start
||> |> >>> and stop time observable by the SRC, which might differ, at
||> least
||> |a
||> |> >>> bit, from the corresponding signaling on the RS.
||> |> >>>
||> |> >>> We might want to report those times. Or, since we abstract
the
||> CS
||> |> >>> away from the dialog, we might want to report the start time
||> |> >>> of
||> |the
||> |> >>> first dialog in the CS as the CS start time, and the stop
time
||> of
||> |> the
||> |> >>> last dialog in the CS as the CS stop time.
||> |> >>>
||> |> >>> Similarly, we have abstracted media streams away from the
||> |> >>> media streams in the sip dialogs that make up the CS. We
might
||> |> >>> want
||to
||> |> >>> report the start time of a media stream as the time
(according
||> to
||> |> the
||> |> >>> CS) of the first participant to a new media stream, and the
||stop
||> |> time
||> |> >>> as the time that the last participant leaves the media
stream.
||> |> >>>
||> |> >>> There are several things that complicate this:
||> |> >>>
||> |> >>> - Do we consider the case of a stream that starts with
recvonly
||> |> >>>      or inactive participants, and only later gets a sender?
||> |> >>> If
||> |so,
||> |> >>>      is the start time of the stream when the first
||> |> >>> participant
||> |> arrived,
||> |> >>>      or when the first sender arrived?
||> |> >>>
||> |> >>> - How do we get the clock times for the media streams?
||> |> >>>      IIUC the correct ones are in the RTP/RTCP, but the
||> reporting
||> |> of
||> |> >>>      these events is driven by the signaling, and we don't
||> |> >>> have
||> |> good
||> |> >>>      sync between those. (E.g. media could start flowing
||> |> >>> before
||> |the
||> |> >>>      corresponding signaling, and we would like to include
||> |> >>> that
||> if
||> |> we
||> |> >>>      can figure it out.) So, even if the clocks used for
media
||> and
||> |> >>>      signaling are in sync, we might see media packets arrive
||> with
||> |> >>>      a timestamp prior to the timestamp for the signaling
that
||> |> >>>      indicates the send state of the participant. This could
||> cause
||> |> >>>      trouble in playback.
||> |> >>>
||> |> >>> - There isn't any guarantee that the clock used for signaling
||> |> >>>      messages is synchronized with the clock used in
RTP/RTCP.
||> |> >>>
||> |> >>> - There isn't any guarantee that there will be any RTCP at
all,
||> |> >>>      to provide correlation of the RTP to clocktime.
||> |> >>>
||> |> >>> The best I can see to deal with all of this is:
||> |> >>>
||> |> >>> - All the metadata messages should be timestamped by the SRC
||> |> >>>      using its local clock. This is easily achieved by the
Date
||> |> >>>      header in the sip message.
||> |> >>>
||> |> >>> - Changes to a CS, including changes of participants, should
||> |> >>>      be explicitly tagged with the time they occurred in the
||> |> >>>      CS signaling, according to the SRC's clock. (If that is
||> |> >>>      unavailable for some reason, then use the time the SRC
||> |> >>>      became aware of it.)
||> |> >>>
||> |> >>> - We could provide a metadata update element to indicate end
||> |> >>>      of a CS, but I suggest this just be shorthand for
||> indicating
||> |> >>>      removal of all participants from it. (While its possible
||to
||> |> >>>      mark that the CS is truly ended, that simply introduces
an
||> |> >>>      error case if added metadata about it is subsequently
||> sent.)
||> |> >>>      The actual start/stop time would be determined by the
SRS
||> |> >>>      based on the timestamps of first and last data about it.
||> |> >>>
||> |> >>> - Changes to media streams should similarly be tagged with
||> |> >>>      the time they occurred in the CS signaling. Each
||> participant
||> |> >>>      relationship change (send, receive, inactive,) will be
||> there.
||> |> >>>      The actual start/stop time of the media stream again
||> |> >>> would
||> be
||> |> >>>      derived by the SRS.
||> |> >>>
||> |> >>> - CS-Groups can simply be tagged by the timestamps of the
||> |> >>>      updates that put CSs into them. Explicit start/stop
times
||> |> don't
||> |> >>>      seem useful. If desired, the SRS can derive start/stop
||> times
||> |> >>>      from the start/stop times of the contained stuff.
||> |> >>>
||> |> >>> - I now think that CS-Groups should not be "contained" within
||> |> >>>      a recording. This just seems to introduce unnecessary
||error
||> |> >>>      conditions, and limitations on future enhancements. The
||> |> >>>      lifetime of CS-Groups will probably be naturally limited
||by
||> |> >>>      the ability of the SRC to remember the IDs of old ones.
||> |> >>>      For instance, if a CS-G is created during one Recording,
||> |> >>>      and then another CS is added to it from a different
||> recording
||> |> >>>      session, would we prefer to fail that, or just allow it?
||> |> >>>      (I think allow.)
||> |> >>>
||> |> >>> - Rather, I think every update transmitted during a recording
||> |> >>>      session can be tagged with a link to the metadata of the
||> |> >>>      recording session it came from. This need not be
explicit
||-
||> |> the
||> |> >>>      SRS can do it automatically. The recording session
entity
||> |> >>>      itself will also have a start/stop time which is the
||start/
||> |> >>>      stop of the RS dialog as observed by the SRS.
||> |> >>>
||> |> >>> (Note the above doesn't solve the problem of getting correct
||> clock
||> |> >>> times for RTP media. If anyone has a suggestion for this I'm
||all
||> |> >>> ears.)
||> |> >>>
||> |> >>> 	Thanks,
||> |> >>> 	Paul
||> |> >>> _______________________________________________
||> |> >>> siprec mailing list
||> |> >>> [email-masked]
||> |> >>> https://www.ietf.org/mailman/listinfo/siprec
||> |> >>>
||> |> > _______________________________________________
||> |> > siprec mailing list
||> |> > [email-masked]
||> |> > https://www.ietf.org/mailman/listinfo/siprec
||> |> >
||> |> _______________________________________________
||> |> siprec mailing list
||> |> [email-masked]
||> |> https://www.ietf.org/mailman/listinfo/siprec
||> |
||> |
||>
|||---------------------------------------------------------------------
-
||> -
||> -------------------------------
||> |-------------
||> |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.
||> |
||> |_______________________________________________
||> |siprec mailing list
||> [email-masked]
||> |https://www.ietf.org/mailman/listinfo/siprec
||
||
||----------------------------------------------------------------------
-
||-------------------------------
||-------------
||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.
||
||_______________________________________________
||siprec mailing list
[email-masked]
||https://www.ietf.org/mailman/listinfo/siprec

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 13 Apr 2011 17:20:19 +0530

Muthu,

Even now, Media stream block attributes like start-time, end-time in
metadata from SRC facilitates SRS to have synchronized playback media in
case SRS maps metadata from SRC with the received raw media. Proposed
requirement is going one level deeper wherein the timestamp from SRC has
to be based on RTP layer timestamp or SRC SIP signaling? 

IMO, SIP signaling serves the purpose and there is no need of explicitly
mention how SRC find start timestamp. In case you have strong usecase
for RTP timestamp based requirement, it requires changes in SIPREC
requirement because it is specific mechanism insisted on SRC.

Thanks
Partha

-----Original Message-----
From: Muthu ArulMozhi Perumal (mperumal) 
Sent: Wednesday, April 13, 2011 4:07 PM
To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat); 'Leon
Portman'
Cc: [email-masked]'

Muthu

|-----Original Message-----
|From: Parthasarathi R (partr)
|Sent: Wednesday, April 13, 2011 2:46 PM
|To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat
(pkyzivat); 'Leon Portman'
|Cc: [email-masked]'
|Subject: RE: [siprec] start/stop times & the metamodel
|
|ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP 
|translator) in case these requirement has to be considered within 
|SIPREC. IMO, these requirement has to be mentioned in SIPREC 
|requirement document to define the exact role what SRC does with media
timestamp and what SRS does with media timestamp?
|
|Thanks
|Partha
|
|-----Original Message-----
|From: Muthu ArulMozhi Perumal (mperumal)
|Sent: Wednesday, April 13, 2011 12:36 PM
|To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat);
'Leon Portman'
|Cc: [email-masked]'
|Subject: RE: [siprec] start/stop times & the metamodel
|
|After the use-case Paul described, it seem to me that if we keep out of

|scope it will put a lot of burden on the SRS to support synchronized 
|querying/playback which looks an important aspect for media recording.

||requirement before going to the
||timestamps are in sync. We could mandate the SRC to generate SR 
||reports but then we are fixing the RTP model for

||> |RTP streams?

||> |> -
||> |> sending
||> |> change (send, receive, inactive,) will be there." That doesn't 
||> |> seem to be

||> |> a
||> |bit
||> |> >>> we

||> |> >>> a
||> |> start
||> |> >>> the
||> |> >>> time
||> |> >>> might want
||> |> >>> (according
||> |> >>> media
||> |> >>> times
||> |> >>> explicit
|||-
||> |Access

||sender immediately, destroy the

||and/or its affiliated
|entities.
||

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 Apr 2011 14:52:33 +0200

Muthu,

Please note that IETF last call on draft-ietf-siprec-req-09 ends 2011-04-20. If you don't think the requirements relating to time (e.g.,  REQ-022 and REQ-023) are sufficient, please respond to the last call.

John (as chair)

> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi
> Perumal (mperumal)
> Sent: 13 April 2011 11:37
> To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat
> (pkyzivat); Leon Portman
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Apr 2011 08:58:27 -0400

> requirement because it is specific mechanism insisted on SRC.

Let me start out by saying that I don't know what the answer(s) are here 
- I have a very limited knowledge of RTP.

The timestamps in the metadata (or in the sip messages that carry the 
metadata) are a *piece* of the solution. How *sufficient* they are 
remains to be seen - perhaps by demonstrating some procedures for using 
them to achieve a useful playback result in various scenarios.

The problem seems to be that even if a timestamp from the CS signaling 
is passed in the metadata, its not clear how that can be synchronized 
with RTP data arriving at the SRS. *Perhaps* its enough if you assume 
that RTP packets will begin to arrive at the SRS concurrently with the 
signaling that describes the corresponding stream. I'm certain that is 
*not* true, but I don't know how *far* from true it is, or how much that 
will vary based on scenario.

It does seem to me that it is a mistake to standardize a mechanism that 
*depends* on such a shaky mechanism. (But a mechanism that uses this as 
a fallback mechanism might make sense.)

	Thanks,
	Paul

> ||Subject: RE: [siprec] start/stop times&  the metamodel
> ||
> ||Henry,
> ||
> ||>  Subject: RE: [siprec] start/stop times&  the metamodel
> ||>
> ||>  |Subject: Re: [siprec] start/stop times&  the metamodel
> ||>  |
> ||>  |>  Subject: Re: [siprec] start/stop times&  the metamodel
> ||>  |>
> ||>  |>
> ||>  |>

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 14 Apr 2011 11:41:21 +0530

John,

The requirements drafts discusses synchronization between the recorded
media streams and synchronized playback:

<snip>
Some applications require the recording of more than one media stream,
possibly of different types. Media are synchronized, either at storage
or at playback.
</snip>

However, it doesn't seem REQ-022 and REQ-023 are all that are need and
sufficient to achieve this with the needed precision. So, I am thinking
we could add another requirement as follows:

The mechanism MUST provide means for facilitating synchronization of the
recorded media streams and metadata either at storage or at playback.
This includes, but not limited to, the information needed as per REQ-022
and REQ-023.

Let me respond to the last call.

Muthu

|-----Original Message-----
|From: Elwell, John [mailto:[email-masked]]
|Sent: Wednesday, April 13, 2011 6:23 PM
|To: Muthu ArulMozhi Perumal (mperumal); Parthasarathi R (partr); Henry
Lum; Paul Kyzivat (pkyzivat);
|Leon Portman
|Cc: [email-masked]
|Subject: RE: [siprec] start/stop times & the metamodel
|
|Muthu,
|
|Please note that IETF last call on draft-ietf-siprec-req-09 ends
2011-04-20. If you don't think the
|requirements relating to time (e.g.,  REQ-022 and REQ-023) are
sufficient, please respond to the last
|call.
|
|John (as chair)
|
|> -----Original Message-----
|> From: [email-masked]
|> [mailto:[email-masked]] On Behalf Of Muthu ArulMozhi
|> Perumal (mperumal)
|> Sent: 13 April 2011 11:37
|> To: Parthasarathi R (partr); Henry Lum; Paul Kyzivat
|> (pkyzivat); Leon Portman
|> Cc: [email-masked]
|> Subject: Re: [siprec] start/stop times & the metamodel
|>
|> I don't think the requirements need to go to the level of RTP
|> timestamp.
|> But it may be useful to add a requirement that the SRC needs to
|> facilitate synchronized querying/playback of the recorded
|> media streams
|> and metadata. I couldn't derive that directly from the requirements
we
|> already have, but would like to hear from others if this is already
|> implied.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: Parthasarathi R (partr)
|> |Sent: Wednesday, April 13, 2011 2:46 PM
|> |To: Muthu ArulMozhi Perumal (mperumal); 'Henry Lum'; Paul Kyzivat
|> (pkyzivat); 'Leon Portman'
|> |Cc: [email-masked]'
|> |Subject: RE: [siprec] start/stop times & the metamodel
|> |
|> |ISTM, SRC has to act only as RTP Endpoint or RTP Mixer (not RTP
|> translator) in case these requirement
|> |has to be considered within SIPREC. IMO, these requirement has to be
|> mentioned in SIPREC requirement
|> |document to define the exact role what SRC does with media timestamp
|> and what SRS does with media
|> |timestamp?
|> |
|> |Thanks
|> |Partha
|> |
|> |-----Original Message-----
|> |From: Muthu ArulMozhi Perumal (mperumal)
|> |Sent: Wednesday, April 13, 2011 12:36 PM
|> |To: Parthasarathi R (partr); 'Henry Lum'; Paul Kyzivat (pkyzivat);
|> 'Leon Portman'
|> |Cc: [email-masked]'
|> |Subject: RE: [siprec] start/stop times & the metamodel
|> |
|> |After the use-case Paul described, it seem to me that if we
|> keep out of
|> scope it will put a lot of
|> |burden on the SRS to support synchronized querying/playback
|> which looks
|> an important aspect for media
|> |recording. So, we may want to consider the ways in which the SRC can
|> facilitate it.
|> |
|> |Muthu
|> |
|> ||-----Original Message-----
|> ||From: Parthasarathi R (partr)
|> ||Sent: Wednesday, April 13, 2011 11:20 AM
|> ||To: Henry Lum; Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat
|> ||(pkyzivat); Leon Portman
|> ||Cc: [email-masked]
|> ||Subject: RE: [siprec] start/stop times & the metamodel
|> ||
|> ||Henry,
|> ||
|> ||I attached the follow up mail to below mail thread. Till
|> now, We don't
|> ||have strong requirement to solve in SIPREC. Let us identify the
|> requirement before going to the
|> |solution.
|> ||
|> ||Thanks
|> ||Partha
|> ||
|> ||-----Original Message-----
|> ||From: [email-masked] [mailto:[email-masked]] On
|> ||Behalf Of Henry Lum
|> ||Sent: Wednesday, April 13, 2011 2:43 AM
|> ||To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat
|> (pkyzivat); Leon
|> ||Portman
|> ||Cc: [email-masked]
|> ||Subject: Re: [siprec] start/stop times & the metamodel
|> ||
|> ||I don't think it is guaranteed that participants will send
|> SR reports
|> ||(or any RTCP), plus we will also have to assume that the NTP
|> timestamps
|> ||are in sync. We could mandate the SRC to generate SR
|> reports but then
|> we are fixing the RTP model for
|> |the SRC.
|> ||
|> ||Regards,
|> ||Henry
|> ||
|> ||> -----Original Message-----
|> ||> From: Muthu ArulMozhi Perumal (mperumal)
|> [mailto:[email-masked]]
|> ||> Sent: Monday, April 11, 2011 10:45 PM
|> ||> To: Henry Lum; Paul Kyzivat (pkyzivat); Leon Portman
|> ||> Cc: [email-masked]
|> ||> Subject: RE: [siprec] start/stop times & the metamodel
|> ||>
|> ||> While I see it may be useful for the SRS to know when
|> certain things
|> ||> happened in CS signaling (participant joining, leaving, going
mute
|> ||etc)
|> ||> I don't see how useful it would be for it know how those
|> things are
|> ||> related to when the participant actually sent/received (or
stopped
|> ||> sending/receiving) RTP.
|> ||>
|> ||> If we see any use, one way to do it is using the NTP timestamp
|> ||> carried in RTCP SR reports, provided the SRC, SRS and the
|> ||> participants have access to the same reference wallclock.
|> ||>
|> ||> Muthu
|> ||>
|> ||> |-----Original Message-----
|> ||> |From: [email-masked] [mailto:[email-masked]]
On
|> ||> Behalf Of Henry Lum
|> ||> |Sent: Tuesday, April 12, 2011 2:56 AM
|> ||> |To: Paul Kyzivat (pkyzivat); Leon Portman
|> ||> |Cc: [email-masked]
|> ||> |Subject: Re: [siprec] start/stop times & the metamodel
|> ||> |
|> ||> |A related question on the RTP model is that if the SRC as an RTP
|> ||> |translator chooses to relay the RTP timestamps, then how
|> would the
|> ||SRC
|> ||> |synchronize the timestamps between the SIP messages the multiple
|> RTP
|> ||> |streams?
|> ||> |
|> ||> |Henry
|> ||> |
|> ||> |> -----Original Message-----
|> ||> |> From: [email-masked]
|> [mailto:[email-masked]] On
|> ||> |> Behalf Of Paul Kyzivat
|> ||> |> Sent: Monday, April 11, 2011 1:06 PM
|> ||> |> To: Leon Portman
|> ||> |> Cc: [email-masked]
|> ||> |> Subject: Re: [siprec] start/stop times & the metamodel
|> ||> |>
|> ||> |>
|> ||> |>
|> ||> |> On 4/11/2011 9:36 AM, Leon Portman wrote:
|> ||> |> > Paul Hi
|> ||> |> >
|> ||> |> > I agree with proposed method of time stamping
|> metadata elements
|> ||> with
|> ||> |> SRC clock (it is like a wall clock from the requirement
|> document).
|> ||> |> > About RTP time synchronization to metadata events, we either
|> ||> should
|> ||> |> have some low latency event from SRC to SRS with SRC time that
|> ||> |> will allow SRS to maintain time difference between its
|> clock and
|> ||> |> SRC
|> ||> clock
|> ||> |> and then apply it also to receive time of RTP packet
|> (assuming no
|> ||> |> buffering)
|> ||> |>
|> ||> |> ISTM the issue isn't the latency of the event - it is
|> what it is
|> -
|> ||> but
|> ||> |> rather how to correlate a sip message containing
|> metadata with a
|> ||> |> particular RTP packet. I suspect that needs to be tied into
the
|> ||> |> discussion of the various models for how the SRC might handle
|> RDP.
|> ||> |>
|> ||> |>        Thanks,
|> ||> |>        Paul
|> ||> |>
|> ||> |> > Leon
|> ||> |> >
|> ||> |> > -----Original Message-----
|> ||> |> > From: [email-masked]
|> [mailto:[email-masked]]
|> ||> |> > On
|> ||> |> Behalf Of Paul Kyzivat
|> ||> |> > Sent: Monday, April 11, 2011 4:03 PM
|> ||> |> > To: Elwell, John
|> ||> |> > Cc: [email-masked]
|> ||> |> > Subject: Re: [siprec] start/stop times&  the metamodel
|> ||> |> >
|> ||> |> >
|> ||> |> >
|> ||> |> > On 4/8/2011 11:53 AM, Elwell, John wrote:
|> ||> |> >> Paul,
|> ||> |> >>
|> ||> |> >> I think much of what you say makes sense. I was
|> concerned that
|> ||we
|> ||> |> probably need to record when a participant stops or starts
|> sending
|> ||> or
|> ||> |> receiving a stream, which seems to be covered by your
|> statement:
|> ||> |> "Changes to media streams should similarly be tagged with the
|> time
|> ||> |they
|> ||> |> occurred in the CS signaling. Each participant relationship
|> change
|> ||> |> (send, receive, inactive,) will be there." That doesn't seem
to
|> be
|> ||> in
|> ||> |> the model at present.
|> ||> |> >
|> ||> |> > John,
|> ||> |> >
|> ||> |> > I agree the current model doesn't reflect this - it was a
|> ||> |> > private
|> ||> |> thought by me, provoked by the work and discussion to
|> date. It is
|> ||> |> a
|> ||> |bit
|> ||> |> of a change of direction, so I'm interested in what
|> others think
|> ||> about
|> ||> |> it.
|> ||> |> >
|> ||> |> >      Thanks,
|> ||> |> >      Paul
|> ||> |> >
|> ||> |> >> John (as individual)
|> ||> |> >>
|> ||> |> >>
|> ||> |> >>> -----Original Message-----
|> ||> |> >>> From: [email-masked]
|> ||> |> >>> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> ||> |> >>> Sent: 06 April 2011 22:28
|> ||> |> >>> To: [email-masked]
|> ||> |> >>> Subject: [siprec] start/stop times&   the metamodel
|> ||> |> >>>
|> ||> |> >>> In Prague, one of the open issues was around start/stop
|> times.
|> ||> The
|> ||> |> >>> format draft floated the possibility of having explicit
|> ||> start/stop
|> ||> |> >>> times signaled for each of the metatdata elements. But
then
|> we
|> ||> |> asked
|> ||> |> >>> for feedback on which make sense.
|> ||> |> >>>
|> ||> |> >>> IMO explicit start/stop times make more sense for
|> some things
|> ||> than
|> ||> |> >>> others.
|> ||> |> >>>
|> ||> |> >>> One place where we potentially have explicit times
|> to report
|> ||> with
|> ||> |> the
|> ||> |> >>> dialogs that constitute a CS. Each such dialog
|> presumably has
|> ||> |> >>> a
|> ||> |> start
|> ||> |> >>> and stop time observable by the SRC, which might differ,
at
|> ||> least
|> ||> |a
|> ||> |> >>> bit, from the corresponding signaling on the RS.
|> ||> |> >>>
|> ||> |> >>> We might want to report those times. Or, since we abstract
|> the
|> ||> CS
|> ||> |> >>> away from the dialog, we might want to report the
|> start time
|> ||> |> >>> of
|> ||> |the
|> ||> |> >>> first dialog in the CS as the CS start time, and the stop
|> time
|> ||> of
|> ||> |> the
|> ||> |> >>> last dialog in the CS as the CS stop time.
|> ||> |> >>>
|> ||> |> >>> Similarly, we have abstracted media streams away from the
|> ||> |> >>> media streams in the sip dialogs that make up the CS. We
|> might
|> ||> |> >>> want
|> ||to
|> ||> |> >>> report the start time of a media stream as the time
|> (according
|> ||> to
|> ||> |> the
|> ||> |> >>> CS) of the first participant to a new media stream, and
the
|> ||stop
|> ||> |> time
|> ||> |> >>> as the time that the last participant leaves the media
|> stream.
|> ||> |> >>>
|> ||> |> >>> There are several things that complicate this:
|> ||> |> >>>
|> ||> |> >>> - Do we consider the case of a stream that starts with
|> recvonly
|> ||> |> >>>      or inactive participants, and only later gets
|> a sender?
|> ||> |> >>> If
|> ||> |so,
|> ||> |> >>>      is the start time of the stream when the first
|> ||> |> >>> participant
|> ||> |> arrived,
|> ||> |> >>>      or when the first sender arrived?
|> ||> |> >>>
|> ||> |> >>> - How do we get the clock times for the media streams?
|> ||> |> >>>      IIUC the correct ones are in the RTP/RTCP, but the
|> ||> reporting
|> ||> |> of
|> ||> |> >>>      these events is driven by the signaling, and we don't
|> ||> |> >>> have
|> ||> |> good
|> ||> |> >>>      sync between those. (E.g. media could start flowing
|> ||> |> >>> before
|> ||> |the
|> ||> |> >>>      corresponding signaling, and we would like to include
|> ||> |> >>> that
|> ||> if
|> ||> |> we
|> ||> |> >>>      can figure it out.) So, even if the clocks used for
|> media
|> ||> and
|> ||> |> >>>      signaling are in sync, we might see media
|> packets arrive
|> ||> with
|> ||> |> >>>      a timestamp prior to the timestamp for the signaling
|> that
|> ||> |> >>>      indicates the send state of the participant.
|> This could
|> ||> cause
|> ||> |> >>>      trouble in playback.
|> ||> |> >>>
|> ||> |> >>> - There isn't any guarantee that the clock used
|> for signaling
|> ||> |> >>>      messages is synchronized with the clock used in
|> RTP/RTCP.
|> ||> |> >>>
|> ||> |> >>> - There isn't any guarantee that there will be any RTCP at
|> all,
|> ||> |> >>>      to provide correlation of the RTP to clocktime.
|> ||> |> >>>
|> ||> |> >>> The best I can see to deal with all of this is:
|> ||> |> >>>
|> ||> |> >>> - All the metadata messages should be timestamped
|> by the SRC
|> ||> |> >>>      using its local clock. This is easily achieved by the
|> Date
|> ||> |> >>>      header in the sip message.
|> ||> |> >>>
|> ||> |> >>> - Changes to a CS, including changes of
|> participants, should
|> ||> |> >>>      be explicitly tagged with the time they
|> occurred in the
|> ||> |> >>>      CS signaling, according to the SRC's clock.
|> (If that is
|> ||> |> >>>      unavailable for some reason, then use the time the
SRC
|> ||> |> >>>      became aware of it.)
|> ||> |> >>>
|> ||> |> >>> - We could provide a metadata update element to
|> indicate end
|> ||> |> >>>      of a CS, but I suggest this just be shorthand for
|> ||> indicating
|> ||> |> >>>      removal of all participants from it. (While
|> its possible
|> ||to
|> ||> |> >>>      mark that the CS is truly ended, that simply
|> introduces
|> an
|> ||> |> >>>      error case if added metadata about it is subsequently
|> ||> sent.)
|> ||> |> >>>      The actual start/stop time would be determined by the
|> SRS
|> ||> |> >>>      based on the timestamps of first and last
|> data about it.
|> ||> |> >>>
|> ||> |> >>> - Changes to media streams should similarly be tagged with
|> ||> |> >>>      the time they occurred in the CS signaling. Each
|> ||> participant
|> ||> |> >>>      relationship change (send, receive, inactive,) will
be
|> ||> there.
|> ||> |> >>>      The actual start/stop time of the media stream again
|> ||> |> >>> would
|> ||> be
|> ||> |> >>>      derived by the SRS.
|> ||> |> >>>
|> ||> |> >>> - CS-Groups can simply be tagged by the timestamps of the
|> ||> |> >>>      updates that put CSs into them. Explicit start/stop
|> times
|> ||> |> don't
|> ||> |> >>>      seem useful. If desired, the SRS can derive
start/stop
|> ||> times
|> ||> |> >>>      from the start/stop times of the contained stuff.
|> ||> |> >>>
|> ||> |> >>> - I now think that CS-Groups should not be
|> "contained" within
|> ||> |> >>>      a recording. This just seems to introduce unnecessary
|> ||error
|> ||> |> >>>      conditions, and limitations on future
|> enhancements. The
|> ||> |> >>>      lifetime of CS-Groups will probably be
|> naturally limited
|> ||by
|> ||> |> >>>      the ability of the SRC to remember the IDs of
|> old ones.
|> ||> |> >>>      For instance, if a CS-G is created during one
|> Recording,
|> ||> |> >>>      and then another CS is added to it from a different
|> ||> recording
|> ||> |> >>>      session, would we prefer to fail that, or
|> just allow it?
|> ||> |> >>>      (I think allow.)
|> ||> |> >>>
|> ||> |> >>> - Rather, I think every update transmitted during
|> a recording
|> ||> |> >>>      session can be tagged with a link to the
|> metadata of the
|> ||> |> >>>      recording session it came from. This need not be
|> explicit
|> ||-
|> ||> |> the
|> ||> |> >>>      SRS can do it automatically. The recording session
|> entity
|> ||> |> >>>      itself will also have a start/stop time which is the
|> ||start/
|> ||> |> >>>      stop of the RS dialog as observed by the SRS.
|> ||> |> >>>
|> ||> |> >>> (Note the above doesn't solve the problem of
|> getting correct
|> ||> clock
|> ||> |> >>> times for RTP media. If anyone has a suggestion
|> for this I'm
|> ||all
|> ||> |> >>> ears.)
|> ||> |> >>>
|> ||> |> >>>    Thanks,
|> ||> |> >>>    Paul
|> ||> |> >>> _______________________________________________
|> ||> |> >>> siprec mailing list
|> ||> |> >>> [email-masked]
|> ||> |> >>> https://www.ietf.org/mailman/listinfo/siprec
|> ||> |> >>>
|> ||> |> > _______________________________________________
|> ||> |> > siprec mailing list
|> ||> |> > [email-masked]
|> ||> |> > https://www.ietf.org/mailman/listinfo/siprec
|> ||> |> >
|> ||> |> _______________________________________________
|> ||> |> siprec mailing list
|> ||> |> [email-masked]
|> ||> |> https://www.ietf.org/mailman/listinfo/siprec
|> ||> |
|> ||> |
|> ||>
|> |||-----------------------------------------------------------
|> ----------
|> -
|> ||> -
|> ||> -------------------------------
|> ||> |-------------
|> ||> |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.
|> ||> |
|> ||> |_______________________________________________
|> ||> |siprec mailing list
|> ||> [email-masked]
|> ||> |https://www.ietf.org/mailman/listinfo/siprec
|> ||
|> ||
|> ||------------------------------------------------------------
|> ----------
|> -
|> ||-------------------------------
|> ||-------------
|> ||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.
|> ||
|> ||_______________________________________________
|> ||siprec mailing list
|> [email-masked]
|> ||https://www.ietf.org/mailman/listinfo/siprec
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Apr 2011 13:12:15 +0200

I guess it depends what we are trying to capture here. Consider a 2-party call between A and B.

First consider the case where the SRC is collocated with UA A. Do we wish to record the time A sends media and the time A receives media. Note that the time B receives media will be later than the time A sends it, and the time B sends media will be earlier than the time A receives it. When reconstructing audio during playback, do we want to reconstruct the audio with synchronization between the two directions in accordance with what took place at A or with what took place at B?

Second, consider the case where the SRC is at a B2BUA. Here the times that media pass through equate neither to the time that A sends and receives nor the time that B sends and receives. So do we want to reconstruct the audio as observed by the B2BUA, or what took place at A, or what took place at B?

Another point is that for calls partly over TDM (PSTN), timings for what happens beyond the gateway will not be available. So it will not be possible to reconstruct a conversation from the perspective of a user participating via PSTN.

It would be possible to simplify things and say that we record in a way that what gets reconstructed on playback is what is observed at the point where the SRC is located. Sure, this is a simplification, but trying to do anything else would be harder and still would not reflect what is observed by some or all of the participants.

If we assume this simplification, the only other point is trying to compensate for delays, or in particular differing delays, on the RS path.

John (as individual)

> Sent: 13 April 2011 13:58
> To: Parthasarathi R (partr)
> Cc: [email-masked]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 14 Apr 2011 17:41:06 +0530

John,

Good summary on how reconstructed recorded media will look like. I'm of
the same opinion that storing or playback in SRS will exactly look like
SRC way of looking the media during the session. Media packet loss/delay
in Recording session (RS) is unavoidable in the loss environment and in
case media packet loss/delay is not desired during recording than Quos
mechanism has to be used between RS which I guess it is outside the
scope of SPIRE. 

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, April 14, 2011 4:42 PM
To: Paul Kyzivat (pkyzivat); Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: [siprec] start/stop times & the metamodel

I guess it depends what we are trying to capture here. Consider a
2-party call between A and B.

First consider the case where the SRC is collocated with UA A. Do we
wish to record the time A sends media and the time A receives media.
Note that the time B receives media will be later than the time A sends
it, and the time B sends media will be earlier than the time A receives
it. When reconstructing audio during playback, do we want to reconstruct
the audio with synchronization between the two directions in accordance
with what took place at A or with what took place at B?

Second, consider the case where the SRC is at a B2BUA. Here the times
that media pass through equate neither to the time that A sends and
receives nor the time that B sends and receives. So do we want to
reconstruct the audio as observed by the B2BUA, or what took place at A,
or what took place at B?

Another point is that for calls partly over TDM (PSTN), timings for what
happens beyond the gateway will not be available. So it will not be
possible to reconstruct a conversation from the perspective of a user
participating via PSTN.

It would be possible to simplify things and say that we record in a way
that what gets reconstructed on playback is what is observed at the
point where the SRC is located. Sure, this is a simplification, but
trying to do anything else would be harder and still would not reflect
what is observed by some or all of the participants.

If we assume this simplification, the only other point is trying to
compensate for delays, or in particular differing delays, on the RS
path.

John (as individual)

> remains to be seen - perhaps by demonstrating some procedures for 
> using them to achieve a useful playback result in various scenarios.
>

> *not* true, but I don't know how *far* from true it is, or how much 
> that will vary based on scenario.
>
> *depends* on such a shaky mechanism. (But a mechanism that uses this 
> as a fallback mechanism might make sense.)
>
>       Thanks,
>       Paul
>
> > Thanks
> > Partha
> >

> > ||>  |Subject: Re: [siprec] start/stop times&  the metamodel  |  |A 
> > ||> related question on the RTP model is that if the
> SRC as an RTP
> > ||>  |>  Sent: Monday, April 11, 2011 1:06 PM  |>  To: Leon Portman

> > ||> |>  Cc: [email-masked]  |>  Subject: Re: [siprec] start/stop 
> > ||> times&  the metamodel  |>  |>  |>  |>  On 4/11/2011 9:36 AM, 
> > ||> Leon Portman wrote:
> > ||>  |>  >  Paul Hi
> > ||>  |>  >
> > ||>  |>  >  -----Original Message-----  |>  >  From: 
> > ||> [email-masked]
> [mailto:[email-masked]]
> > ||>  |>  >  On
> > ||>  |>  >  Sent: Monday, April 11, 2011 4:03 PM  |>  >  To: Elwell,

> > ||> John  |>  >  Cc: [email-masked]

> > ||> |>  sending  or  |>  receiving a stream, which seems to be 
> > ||> covered by
> your statement:

> > ||>  |>  >>>  -----Original Message-----  |>  >>>  From: 
> > ||> [email-masked]  |>  >>>  
> > ||> [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> > ||>  |>  >>>  Sent: 06 April 2011 22:28  |>  >>>  To: 
> > ||> [email-masked]
> > ||> |>  >>>  (according  to  |>  the  |>  >>>  CS) of the first 
> > ||> participant to a new media
> stream, and the
> > ||stop
> > ||>  |>  time
> > ||>  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

---

From: Leon Portman <[email-masked]>
Date: Thu, 14 Apr 2011 15:22:45 +0300

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Thursday, April 14, 2011 3:11 PM
To: Elwell, John; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] start/stop times & the metamodel

John,

Good summary on how reconstructed recorded media will look like. I'm of the same opinion that storing or playback in SRS will exactly look like SRC way of looking the media during the session. Media packet loss/delay in Recording session (RS) is unavoidable in the loss environment and in case media packet loss/delay is not desired during recording than Quos mechanism has to be used between RS which I guess it is outside the scope of SPIRE.

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, April 14, 2011 4:42 PM
To: Paul Kyzivat (pkyzivat); Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: [siprec] start/stop times & the metamodel

First consider the case where the SRC is collocated with UA A. Do we wish to record the time A sends media and the time A receives media.
Note that the time B receives media will be later than the time A sends it, and the time B sends media will be earlier than the time A receives it. When reconstructing audio during playback, do we want to reconstruct the audio with synchronization between the two directions in accordance with what took place at A or with what took place at B?

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Apr 2011 09:26:48 -0400

> If we assume this simplification, the only other point is trying to compensate for delays, or in particular differing delays, on the RS path.

I don't think we can legislate this. But maybe we can at least identify 
for the SRS what it is that it has.

This depends a lot on the RTP model that is used for directing media to 
the SRS.

For instance, in your first case:

If A mixes the audio it receives from B with that it sends to B, in 
accord with the order it receives it from its mic and sends to its 
speaker, and clocks it all consistently, then the SRS will be able to 
play back a rendition as A heard it.

If A simply clones the media stream it gets from B and the one it sends 
to A, and forwards the clones to the SRS, either as separate streams or 
as one stream with two SSRCs, then the SRS will have difficulty 
reconstructing things as heard by A, or by B. Its not so clear *what* it 
should do to play the two back in a reasonable way.

If A, instead of cloning the stream from B itself, instead asks B to 
clone the stream and send a copy to the SRS, then things are again 
different.

Similar situations apply in the second case.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 15 Apr 2011 19:56:29 +0530

Paul,

Scenario 2: In case of this RTP translator (forwarding) scenario,
Metadata media stream block start time has to act as reference timestamp
rather than RTP timestamp. Say Media stream start time as T0 and end
time as T1, the first media packet is received at T0+ t[i] wherein t[i]
is the time interval between T0 and first media packet. Here T0+t[i] is
always less than T1. Playback shall use T0 as the reference value. Here,
B's media will be played back in SRS how A sees it and A media will be
replayed as if A speaks. 

Scenario 3: This scenario needs some extra interface between A & B apart
from SIPREC. Let us assume it exists. Then also, it is not possible to
synchronize the media stream because A will not know how B receives it
and B will not know how A receives it. So, these sort of recording will
replay how A and B speaks at the given time rather than how A or B
listen to it.

Thanks
Partha

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Thursday, April 14, 2011 6:57 PM
To: Elwell, John
Cc: Parthasarathi R (partr); [email-masked]
Subject: Re: [siprec] start/stop times & the metamodel

>
> Another point is that for calls partly over TDM (PSTN), timings for
what happens beyond the gateway will not be available. So it will not be
possible to reconstruct a conversation from the perspective of a user
participating via PSTN.
>
> It would be possible to simplify things and say that we record in a
way that what gets reconstructed on playback is what is observed at the
point where the SRC is located. Sure, this is a simplification, but
trying to do anything else would be harder and still would not reflect
what is observed by some or all of the participants.

	Thanks,
	Paul

>> The problem seems to be that even if a timestamp from the CS 
>> signaling is passed in the metadata, its not clear how that can be 
>> synchronized with RTP data arriving at the SRS. *Perhaps* its enough 
>> if you assume that RTP packets will begin to arrive at the SRS 
>> concurrently with the signaling that describes the corresponding 
>> stream. I'm certain that is
>>> ||>   |CONFIDENTIALITY NOTICE: This e-mail and any files attached 
>>> ||> may
>>> ||contain