Subject: [siprec] SIPREC and draft-romano-dcon-recording

From: "Elwell, John" <[email-masked]>
Date: Tue, 7 Sep 2010 17:25:01 +0200

We had some discussion in the past on this draft and its relationship to SIPREC:
https://datatracker.ietf.org/doc/draft-romano-dcon-recording/

We didn't really reach consensus as to the extent it addresses the SIPREC charter:
"The Session Recording Protocol (SIPREC) working group is chartered to
define a SIP-based protocol for controlling a session (media) recorder".

Some observations:

1. Figure 1 assumes a centralized conference. SIPREC has to work for two-party calls too. But one could say that is a special case, where the conference focus (XCON AS) and Mixer are collocated with one of the UAs. Of course, that would also apply for a "local" conference, where one of the UAs provides the bridge for a 3- or more party conference.

2. The main issue identified during the earlier thread was that the interface to the recorder is only RTP. There is no control interface to tell it when to start receiving media, tell it when to stop receiving media, and supply the metadata. So this could be the SIPREC protocol: the XCON AS + Mixer (in combination) act as the SRC, and the recorder acts as the SRS. But this is not shown in the dcon draft.

3. One clue is that the dcon draft mentions the option of the recorder acting as a passive participant in a conference, and although only RTP is shown, perhaps SIP would be involved in setting up the call to the passive participant. This still does not cover how metadata reaches the recorder, for example.

4. However, perhaps another way of viewing it is that the XCON AS and recorder are somehow intimately connected (e.g., collocated, or connected by proprietary protocols). In other words, SIPREC's SRS covers both the XCON AS and the recorder in the figure. So somebody accessing the AS (e.g., by a web interface) could get the SMIL file, plus information where to find the media recordings on the recorder. The playback section (6) fails to show a recorder - this is certainly an area that would merit clarification by the dcon authors.

5. If the above model is correct (i.e., the recorder is not stand-alone and the XCON AS needs to be involved in playback, this is problematic for the UA-centric case (since the UA might not be available to a person wanting to play back).

6. So the dcon draft apparently assumes that one would always use the centralized XCON model even, for two-party calls. Thus a call is always established via an XCON AS (acting as a B2BUA), and if it needs to be recorded, that can be accomplished (the B2BUA becoming the SRS). Alternatively, when it is known that a call needs to be recorded, it could be re-arranged to go via an XCON AS (i.e., re-arranged to go via the SRS). I think this was not the intention when SIPREC was formed. For example, calls in a branch office would not want to be routed via a main office where the recorder is located - it should be sufficient just to send the recording material to the main office.

7. SMIL sounds like a promising basis for metadata, but I think that is independent of the architectural issue and should be discussed on a separate thread.

John (as individual)

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 10 Sep 2010 15:16:56 +0200

Hi John,

if you think that SMIL is a feasible way of using session recording 
metadata, we might work on that and perhaps write a document dedicated 
to such topic. Would you be willing to devote some cycles to this?

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 10 Sep 2010 15:36:51 +0200

Simon,

I am not an expert in that area, although at first glance it looks promising and, as chair, I would welcome a document somehow linking it in with draft-ram-siprec-metadata. There may be others on the list more in a position to help you with a document.

John

> -----Original Message-----
> From: Simon Pietro Romano [mailto:[email-masked]] 
> Sent: 10 September 2010 14:17
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: SIPREC and draft-romano-dcon-recording
> 
> Hi John,
> 
> > 1. Figure 1 assumes a centralized conference. SIPREC has to 
> work for two-party calls too. But one could say that is a 
> special case, where the conference focus (XCON AS) and Mixer 
> are collocated with one of the UAs. Of course, that would 
> also apply for a "local" conference, where one of the UAs 
> provides the bridge for a 3- or more party conference.
> >
> > 2. The main issue identified during the earlier thread was 
> that the interface to the recorder is only RTP. There is no 
> control interface to tell it when to start receiving media, 
> tell it when to stop receiving media, and supply the 
> metadata. So this could be the SIPREC protocol: the XCON AS + 
> Mixer (in combination) act as the SRC, and the recorder acts 
> as the SRS. But this is not shown in the dcon draft.
> >
> > 3. One clue is that the dcon draft mentions the option of 
> the recorder acting as a passive participant in a conference, 
> and although only RTP is shown, perhaps SIP would be involved 
> in setting up the call to the passive participant. This still 
> does not cover how metadata reaches the recorder, for example.
> >
> > 4. However, perhaps another way of viewing it is that the 
> XCON AS and recorder are somehow intimately connected (e.g., 
> collocated, or connected by proprietary protocols). In other 
> words, SIPREC's SRS covers both the XCON AS and the recorder 
> in the figure. So somebody accessing the AS (e.g., by a web 
> interface) could get the SMIL file, plus information where to 
> find the media recordings on the recorder. The playback 
> section (6) fails to show a recorder - this is certainly an 
> area that would merit clarification by the dcon authors.
> >
> > 5. If the above model is correct (i.e., the recorder is not 
> stand-alone and the XCON AS needs to be involved in playback, 
> this is problematic for the UA-centric case (since the UA 
> might not be available to a person wanting to play back).
> >
> > 6. So the dcon draft apparently assumes that one would 
> always use the centralized XCON model even, for two-party 
> calls. Thus a call is always established via an XCON AS 
> (acting as a B2BUA), and if it needs to be recorded, that can 
> be accomplished (the B2BUA becoming the SRS). Alternatively, 
> when it is known that a call needs to be recorded, it could 
> be re-arranged to go via an XCON AS (i.e., re-arranged to go 
> via the SRS). I think this was not the intention when SIPREC 
> was formed. For example, calls in a branch office would not 
> want to be routed via a main office where the recorder is 
> located - it should be sufficient just to send the recording 
> material to the main office.
> >
> > 7. SMIL sounds like a promising basis for metadata, but I 
> think that is independent of the architectural issue and 
> should be discussed on a separate thread.
> >
> > John (as individual)
> >
> >
> >
> >    
> 
> -- 
>                              _\\|//_
>                              ( O-O )

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 14 Sep 2010 22:15:18 +0530

Simon,

Even before rushing for the solution (SMIL or other XML package or SDP format or combination of SDP & XML), Let us consolidate the recording metadata model. The consolidated recording metadata model will facilitate for the better suitable format for recording.

Please let us know your opinion about the current proposed recording model in draft-ram-siprec-metadata.

Thanks

Partha

________________________________

From: [email-masked] on behalf of Elwell, John
Sent: Fri 9/10/2010 7:06 PM
To: Simon Pietro Romano
Cc: [email-masked]
Subject: Re: [siprec] SIPREC and draft-romano-dcon-recording

Simon,

John

> should be discussed on a separate thread.
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 24 Sep 2010 09:23:57 +0200

Hi,

I don't see any strict relationship between the metadata model you're 
working upon and our proposal for using SMIL as a way to represent the 
recorded session, in case you want to somehow "replay" it. Do you have a 
different impression?

Simon

Il 14/09/2010 18.45, Parthasarathi R (partr) ha scritto:
>
> Simon,
>
> Even before rushing for the solution (SMIL or other XML package or SDP 
> format or combination of SDP & XML), Let us consolidate the 
> recording metadata model. The consolidated recording metadata model 
> will facilitate for the better suitable format for recording.
>
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Elwell, John
> *Sent:* Fri 9/10/2010 7:06 PM
> *To:* Simon Pietro Romano
> *Cc:* [email-masked]
> *Subject:* Re: [siprec] SIPREC and draft-romano-dcon-recording
>
> Simon,
>
> I am not an expert in that area, although at first glance it looks 
> promising and, as chair, I would welcome a document somehow linking it 
> in with draft-ram-siprec-metadata. There may be others on the list 
> more in a position to help you with a document.
>
> John
>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 24 Sep 2010 17:24:40 +0530

HI Simon,

Our goal here is  to freeze on the minimum information needed in the Recording metadata model   as seen by SRS before we jump on to the solution.

The solution shall involve mechanisms for representing the metadata and the mechanisms for transporting metadata from SRC to SRS.

Is the metadata that you  have in mind different from what is put in draft-ram-siprec-metadata ?

Regards,

Ram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
Sent: Friday, September 24, 2010 12:54 PM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [siprec] SIPREC and draft-romano-dcon-recording

Hi,

I don't see any strict relationship between the metadata model you're working upon and our proposal for using SMIL as a way to represent the recorded session, in case you want to somehow "replay" it. Do you have a different impression?

Simon

Simon,

Thanks

Partha

Simon,

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2010 09:32:52 -0400

To add to what Ram said,

Currently there are no requirements to define a way to access the 
metadata (or the actual recorded data) after it is collected by the SRS. 
In principle the SRS could throw away everything as it receives it, 
though nobody would buy a product that did so.

But by defining what we imagine the SRS will retain, we then will have 
the basis to define how that information is transported to the SRS. My 
assumption is that it will *not* be transmitted in one big block. Rather 
it will be transmitted incrementally. And it might not all be 
transmitted using the same mechanism.
- Some may be carried in SIP signaling using existing sip headers
- Some may be carried in SIP signaling using existing SDP lines
- Some may be carried using newly defined SIP headers and/or
   new SDP extensions
- Some may be carried in sip signaling using special body parts
   defined for the purpose, in the common sip signaling messages for
   call setup, or in INFO Packages, or in NOTIFY, PUBLISH, etc.
- (something else?)

That is all TBD. But in the end, there must be *some* mechanism for 
every bit of information in the metamodel.

I haven't investigates SMIL. It sounds like it is pertinent to accessing 
the recorded data after the fact. If so its out of scope *for now*. (I 
fully expect that means for accessing the recorded data will be in scope 
for the WG or some other once we have all the mechanisms in place for 
doing the recording.

	Thanks,
	Paul

On 9/24/2010 7:54 AM, Ram Mohan R (rmohanr) wrote:
> HI Simon,
>
> Our goal here is  to freeze on the minimum information needed in the
> Recording metadata model   as seen by SRS before we jump on to the solution.
>
> The solution shall involve mechanisms for representing the metadata and
> the mechanisms for transporting metadata from SRC to SRS.
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Simon Pietro Romano
> *Sent:* Friday, September 24, 2010 12:54 PM
> *To:* Parthasarathi R (partr)
> *Cc:* [email-masked]
> format or combination of SDP & XML), Let us consolidate the recording
> metadata model. The consolidated recording metadata model will
> facilitate for the better suitable format for recording.
>
> *From:* [email-masked] <mailto:[email-masked]> on
> behalf of Elwell, John
> *Cc:* [email-masked] <mailto:[email-masked]>
> in with draft-ram-siprec-metadata. There may be others on the list more
> in a position to help you with a document.
>
> John
>
>
>>  Cc: [email-masked] <mailto:[email-masked]>
>>  e-mail: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
>                  e-mail:[email-masked]  <mailto:[email-masked]>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 24 Sep 2010 15:49:07 +0200

That's exactly what I was saying. And, as usual, I am afraid our work is 
"out of scope *for now*" (as you say).  In our draft we simply defined a 
solution for playing back, in a synchronized way, the many media which 
were involved in a recording session. For the benefit of those who have 
no time to read the draft, I'm copying in the following a typical 
".smil" representation of one of our recorded sessions (involving a 
real-time chat, a whiteboard, a shared presentation, mixed audio and 
video streams, and a remote desktop session). Hope this helps clarify 
the focus of our contribution.

Cheers,

Simon

<?xml version="1.0" encoding="UTF-8"?>
<smil xmlns:xml="http://www.w3.org/XML/1998/namespace">
<head>
<switch systemScreenSize="800X600">
<layout>
<root-layout width="800" height="600" background-color="black" />
<region id="image0" regionName="image" fit="fill" top="155" left="370" 
width="400" height="350" />
<region id="video0" regionName="video" top="0" left="370" width="176" 
height="155" fit="fill" />
<region id="chat0" regionName="chat" fit="fill" alt="chat" top="505" 
left="0" width="370" height="80" />
<region id="wb0" regionName="wb" top="0" left="0" width="370" 
height="505" />

</layout>
</switch>
<switch systemScreenSize="1024X768">
<layout>
<root-layout width="1024" height="768" background-color="black" />
<region id="image1" regionName="image" fit="fill" top="155" left="594" 
width="400" height="350" />
<region id="video1" regionName="video" top="0" left="594" width="176" 
height="155" fit="fill" />
<region id="chat1" regionName="chat" fit="fill" alt="chat" top="473" 
left="594" width="400" height="183" />
<region id="wb1" regionName="wb" top="0" left="0" width="594" 
height="688" />

</layout>
</switch>
<switch systemScreenSize="1280X800">
<layout>
<root-layout width="1280" height="800" background-color="black" />
<region id="image2" regionName="image" fit="fill" top="155" left="850" 
width="400" height="350" />
<region id="video2" regionName="video" top="0" left="850" width="176" 
height="155" fit="fill" />
<region id="chat2" regionName="chat" fit="fill" alt="chat" top="505" 
left="850" width="400" height="215" />
<region id="wb2" regionName="wb" top="0" left="0" width="850" 
height="720" />

</layout>
</switch>
</head>
<body>
<par>
<textstream 
src="http://143.225.229.136:8180/7772775/23_set_2010at15_25_47sec/chat.rt" 
region="chat" />
<ref 
src="http://143.225.229.136:8180//7772775/23_set_2010at15_25_47sec/wb_7772775-23set2010-15.25.47.txt" 
region="wb" />
<img 
src="http://143.225.229.136:8180/7772775/1285248893648/7772775-1285248893648-0000-400.jpg" 
region="image" begin="563s" end="604s" />
<img 
src="http://143.225.229.136:8180/7772775/1285248893648/7772775-1285248893648-0001-400.jpg" 
region="image" begin="604s" end="612s" />

<img 
src="http://143.225.229.136:8180/7772775/1285248893648/7772775-1285248893648-0002-400.jpg" 
region="image" begin="612s" end="616s" />
<video 
src="http://143.225.229.136:8180/7772775/23_set_2010at15_25_47sec/jrDesktop/1285249427228.mov" 
region="jrdesktop" begin="1079s" />
<img 
src="http://143.225.229.136:8180/7772775/1285248893648/7772775-1285248893648-0003-400.jpg" 
region="image" begin="616s" end="2051s" />
<video 
src="http://143.225.229.136:8180/7772775/23_set_2010at15_25_47sec/video.mov" 
region="video" />
<img src="http://143.225.229.136:8180/stop.jpg" region="image" 
begin="2051s" end="2083s" />
</par>
</body>
</smil>

Il 24/09/2010 15.32, Paul Kyzivat ha scritto:
> metadata (or the actual recorded data) after it is collected by the 
> SRS. In principle the SRS could throw away everything as it receives 
> it, though nobody would buy a product that did so.
>
> assumption is that it will *not* be transmitted in one big block. 
> Rather it will be transmitted incrementally. And it might not all be 
> I haven't investigates SMIL. It sounds like it is pertinent to 
> accessing the recorded data after the fact. If so its out of scope 
> *for now*. (I fully expect that means for accessing the recorded data 
> will be in scope for the WG or some other once we have all the 
> mechanisms in place for doing the recording.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2010 10:16:33 -0400

Simon,

> the focus of our contribution.

OK. That helps position things.

Then my assumption is that there should be a substantial overlap in 
semantic content between SMIL and the siprec metamodel, but that they 
probably won't be identical.

Its my impression that there will need to be things in our model that 
aren't part of SMIL, because they aren't related to playback. Rather 
they may be things for searching, archiving, and to meet legal 
requirements, etc.

Conversely there may be things that SMIL can represent that aren't 
considered requirements for siprec. However, such things ought to be 
carefully considered, because they might just be accidental omissions 
from our model.

I'm not a subject matter expert here regarding what ought to be in the 
model, so I'll let those that are make proposals for whatever alignment 
might be needed.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 27 Sep 2010 18:26:15 +0200

Hi,

Assuming I understand all this I think I agree with the way it is going.

It seems  that SMIL is potentially important to the recording server and it could be that the RS generates a SMIL document which it stores with the recording to enable it to be played back.

I think it is within scope of SIPREC to identify any metadata that the SRC needs to supply the SRS with therefore if there is something that the SRS needs from the SRC to generate a SMIL document then we probably need this in the SIPREC metadata.

What is clearly not within scope of our charter is the mechanism for providing playback of the recorded media.

Regards
Andy

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 24 September 2010 15:17
> To: Simon Pietro Romano
> Cc: [email-masked]
> >  >> Is the metadata that you have in mind different from
> what is put in
> >  >> draft-ram-siprec-metadata ?
> >  >>
> >  >> Regards,
> >  >>
> >  >> Ram
> >  >>
> >  >> Please let us know your opinion about the current
> proposed recording
> >  >> model in draft-ram-siprec-metadata.
> >  >>
> >  >> Thanks
> >  >>
> >  >> Partha
> >  >>
> >  >>

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 27 Sep 2010 19:45:38 +0200

Hi,

> I think it is within scope of SIPREC to identify any metadata that the SRC needs to supply the SRS with therefore if there is something that the SRS needs from the SRC to generate a SMIL document t…

If we keep on restricting SIPREC scope to just audio and video, then I 
would guess there is no extra information (other than what it can infer 
at session setup time) needed at the SRS side in order to correctly 
build the SMIL document to be used for session replay. Things would 
change in case you were to include other media in the recording, though.

Cheers,
Simon

>>> That's exactly what I was saying. And, as usual, I am
>>>        
>> afraid our work is
>>      
>>> "out of scope *for now*" (as you say). In our draft we
>>>        
>> simply defined a
>>      
>>> solution for playing back, in a synchronized way, the many
>>>        
>> media which
>>      
>>> were involved in a recording session. For the benefit of
>>>        
>> those who have
>>      
>>> video streams, and a remote desktop session). Hope this
>>>        
>> helps clarify
>>      
>>> <region id="image0" regionName="image" fit="fill" top="155"
>>>        
>> left="370"
>>      
>>> <region id="video0" regionName="video" top="0" left="370"
>>>        
>> width="176"
>>      
>>> <region id="image1" regionName="image" fit="fill" top="155"
>>>        
>> left="594"
>>      
>>> <region id="video1" regionName="video" top="0" left="594"
>>>        
>> width="176"
>>      
>>> <region id="image2" regionName="image" fit="fill" top="155"
>>>        
>> left="850"
>>      
>>> <region id="video2" regionName="video" top="0" left="850"
>>>        
>> width="176"
>>      
>>>   >  metadata (or the actual recorded data) after it is
>>>        
>> collected by the
>>      
>>>   >  SRS. In principle the SRS could throw away everything as
>>>        
>> it receives
>>      
>>>   >  But by defining what we imagine the SRS will retain, we
>>>        
>> then will have
>>      
>>>   >  the basis to define how that information is transported
>>>        
>> to the SRS. My
>>      
>>>   >  Rather it will be transmitted incrementally. And it
>>>        
>> might not all be
>>      
>>>   >  That is all TBD. But in the end, there must be *some*
>>>        
>> mechanism for
>>      
>>>   >  accessing the recorded data after the fact. If so its
>>>        
>> out of scope
>>      
>>>   >  *for now*. (I fully expect that means for accessing the
>>>        
>> recorded data
>>      
>>>   >>  Our goal here is to freeze on the minimum information
>>>        
>> needed in the
>>      
>>>   >>  The solution shall involve mechanisms for representing
>>>        
>> the metadata and
>>      
>>>   >>  *From:* [email-masked]
>>>        
>> [mailto:[email-masked]] *On
>>      
>>>   >>  I don't see any strict relationship between the
>>>        
>> metadata model you're
>>      
>>>   >>  working upon and our proposal for using SMIL as a way
>>>        
>> to represent the
>>      
>>>   >>  recorded session, in case you want to somehow "replay"
>>>        
>> it. Do you have a
>>      
>>>   >>  different impression?
>>>   >>
>>>   >>  Simon
>>>   >>
>>>   >>  Even before rushing for the solution (SMIL or other XML
>>>        
>> package or SDP
>>      
>>>   >>  format or combination of SDP&  XML), Let us consolidate
>>>        
>> the recording
>>      
>>>   >>  *From:* [email-masked]
>>>        
>> <mailto:[email-masked]>  on
>>      
>>>   >>  behalf of Elwell, John
>>>   >>  *Cc:* [email-masked]<mailto:[email-masked]>
>>>   >>  I am not an expert in that area, although at first
>>>        
>> glance it looks
>>      
>>>   >>  promising and, as chair, I would welcome a document
>>>        
>> somehow linking it
>>      
>>>   >>  in with draft-ram-siprec-metadata. There may be others
>>>        
>> on the list more
>>      
>>>   >>>  Cc: [email-masked]<mailto:[email-masked]>
>>>   >>>  if you think that SMIL is a feasible way of using
>>>        
>> session recording
>>      
>>>   >>>  to such topic. Would you be willing to devote some
>>>        
>> cycles to this?
>>      
>>>   >>>
>>>   >>>  Simon
>>>   >>>
>>>   >>>
>>>   >>>
>>>   >>>  e-mail: [email-masked]<mailto:[email-masked]>
>>>   >>  [email-masked]<mailto:[email-masked]>
>>>   >>  e-mail:[email-masked]<mailto:[email-masked]>
>>>   >>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 27 Sep 2010 14:16:50 -0400

Just FYI, I need text (both real time text and IM text) recorded along with audio and video.

Brian

On Sep 27, 2010, at 1:45 PM, Simon Pietro Romano wrote:

> If we keep on restricting SIPREC scope to just audio and video, then I would guess there is no extra information (other than what it can infer at session setup time) needed at the SRS side in order to correctly build the SMIL document to be used for session replay. Things would change in case you were to include other media in the recording, though.
> 
> Cheers,
> Simon
>

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 29 Sep 2010 13:02:45 -0700

Hi,
 
> I think it is within scope of SIPREC to identify any metadata that the
> SRC needs to supply the SRS with therefore if there is something that
> the SRS needs from the SRC to generate a SMIL document then we probably
> need this in the SIPREC metadata.

[[hlum]] I agree with Andy here that if we find anything that an SRS needs from the SRC to generate such playback format, then we should consider putting into the SIPREC metadata. Looks like we are looking for text/IM and DTMF as the main missing media types for now. Section 4.4 in the metadata draft has a brief description on recorded media streams; should we expand this section to mention all types of media that we can record?

Regards,
Henry

> > >  >> Recording metadata model as seen by SRS before we jump on to
> the
> > >  >> solution.
> > >  >>

-------------------------------------------------------------------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2010 16:57:32 -0400

On 9/29/2010 4:02 PM, Henry Lum wrote:
> [[hlum]] I agree with Andy here that if we find anything that an SRS needs from the SRC to generate such playback format, then we should consider putting into the SIPREC metadata.

Yes.

> Looks like we are looking for text/IM and DTMF as the main missing media types for now.

DTMF isn't a problem as long as its in the RTP stream.
If we allow DTMF in the signaling, then we may need to treat it specially.

text/IM is not really *meta*data - its real data. The same is true of DTMF.

> Section 4.4 in the metadata draft has a brief description on recorded media streams; should we expand this section to mention all types of media that we can record?

But I've already got the *actual* recorded data mentioned in there 
anyway, so expanding it to include other forms is no big deal.

	Thanks,
	Paul